TehPers

If you’re writing a script that’s more than 269 lines long, you shouldn’t be using Bash.

Jokes aside, the point isn’t the lines of code. It’s complexity. Higher level languages can reduce complexity with tasks by having better tools for more complex logic. What could be one line of code in Python can be dozens in Bash (or a long, convoluted pipeline consisting of awk and sed, which I usually just glaze over at that point). Using other languages means better access to dev tools, like tools for testing, linting, and formatting the scripts.

While I’m not really a fan of hostility, it annoys me a lot when I see these massive Bash scripts at work. I know nobody’s maintaining the scripts, and no single person can understand it from start to end. When it inevitably starts to fail, debugging them is a nightmare, and trying to add to it ends up with constantly looking up the syntax specific commands/programs want. Using a higher level language at least makes the scripts more maintainable later on.

Moreover, you cannot say compilers are deterministic. There are situations where they are not (at least for the user).

https://krystalgamer.github.io/high-level-game-patches/

I’m not following. Which part of this is nondeterministic?

The language being complicated to write and the compiler being confusing to use isn’t an indicator of determinism. If GCC were truly nondeterministic, that’d be a pretty major bug.

Also, note that I mentioned that the output behavior is deterministic. I’m not referring to reproducible builds, just that it always produces code that does what the source specifies (in this case according to a spec).

The library is two text files (code) that are processed by an LLM (interpreter) to generate code of another type. This is not that new in terms of workflow.

I think what makes this the worst is the fact that the author admits that you can’t be sure the library will work until you generate the code and test it. Even then you cannot guarantee the security of the generated code and as you do not understand the code you also cannot give support or patch it.

I’ve tried explaining how LLMs are not equatable to compilers/interpreters in the past, and it’s usually to people who aren’t in software roles. What it usually comes down to when I try to explain it is determinism. A compiler or interpreter deterministically produces code with some kind of behavior (defined by the source code). They often are developed to a spec, and the output doing the wrong thing is a bug. LLMs producing the wrong output is a feature. It’s not something you try to fix, and something you often can’t fix.

This, of course, ignores a lot of “lower level” optimizations someone can make about specific algorithms or data structures. I use “lower level” in quotes, of course, because those are some of the most important decisions you can make while writing code, but turning off your brain and letting a LLM do it for you “abstracts” those decisions away to a random number generator.

deleted by creator

It doesn’t have to be. There are multiple sudo alternatives.

Funding or not, Miller expects sudo-rs to become the next generation of the tool in coming years.

“Ubuntu is already shipping sudo-rs as the default sudo command in their latest versions,” Miller told us. “I’ve been in contact with the people working on sudo-rs since the project started and I trust them to do right by the sudo user base.”

Projects don’t last forever, and when they inevitably end, it’s an opportunity to switch to something newer and hopefully better. Sudo coming to an end, if it does, will just force people onto alternatives.

Being open source, sudo will always exist, whether someone else wants to maintain it, fork it, use it as-is, or just reference it. It’s because it’s open source that it can serve a purpose even beyond its EOL.

Anyway, sudo’s not dead yet, so there’s still plenty of time for people to look at what’s out there. Some distros have already moved to, or are considering moving to, alternatives like sudo-rs, so I’d expect that to continue.

There’s also Chocolatey but I don’t know if that gets used anymore.

When I first installed N++, none of these were a thing yet though. It was just the MSI installer.

This puts far too much control on the LLMs. A LLM can provide suggestions for a PR, but those suggestions are not a sufficient replacement for a real review.

If the rate of PRs is too high to review, the solution isn’t to sacrifice the reviews. It’s to ensure that the PRs are of sufficiently high quality that the reviews are quick. Small PRs are faster to review, and readable code is easier to review. Tests can validate correctness to the reviewer. Make the review process as easy as possible for a proper code review.

The hybrid approach seems to me like it’d be the most successful here. Generate your PR suggestions, and let the PR owner resolve them how they like. Then, do a proper review on the PR. Where I disagree with the author here is the reviewer shouldn’t review the suggestions and resolutions, but the final diff instead.

There is some overlap (N-ish SFW) but not in the way they intended.

deleted by creator

If you already know some programming languages, look for some kind of GUI or game library for it to see if you can use it. If not, something like Blender might be easiest to make in C++, Rust, C (if you’re a masochist), or maybe Zig. This may also influence the shading language you choose. Start with this.

You will need to know some shader language. You have a few options there, but the most popular are GLSL and OpenGL (though I’d prefer GLSL). There’s also WGSL and some others, but they aren’t as popular. Prefer whatever the graphics library you’re using wants you to use.

Math is very heavy on linear algebra. Look up PBR if you want to render realistic 3d shapes. Google’s Filament is well documented and walks through implementing it yourself if you want, but it’s pretty advanced, so you might want to start simpler (fragment colors can just be base color * light color * light attenuation * (N*L) for example).

It’s one of the major supermarket chains in NL, which I guess isn’t that obvious to most people, but I miss shopping there because the chains where I am have rotten, moldy produce and AH always had fresh produce and packs of relatively cheap stroopwafel.

Also, related to the post, I’d almost rather be sweeping the floor there. I don’t want to sweep floors, but it’d mean I live there, so yeah.

The author seems to be more interested in generating outrage than anything, but I think the point about AI still stands. From a UX standpoint, key points that may be incorrect are a terrible idea. That they originally intended to force AI on the user, at least from how it seems, is problematic.

The author’s privacy and accessibility concerns seem artifical to me.

The feature was introduced as a way for users to get relevant information faster, by providing them with an image, the webpage title, and AI-generated key points.

The AI part was made optional. That doesn’t mean they didn’t try.

Zen figured out link previews without using AI and the solution is really as simple as it gets. Maybe stop trying to manufacture problems for AI to solve?

500°C would be way above the safe operating temps, but most likely yes.

Server memory is probably reusable, though likely to be either soldered and/or ECC modules. But a soldering iron and someone sufficiently smart can probably do it (if it isn’t directly usable).

My experience, having actually tried this on a huge codebase: my time was better spent looking at file names and reading source code myself to answer specific questions about the code.

Using it to read a single file or a few of them might go better. If you can find the right files first, you might get decent output.

Spouting bullshit? If so, I agree.

Codebases in the 100k+ to 1m+ sloc can be very difficult for a LLM (or human) to answer detailed questions about. A LLM might be able to point you in the right direction, but they don’t have enough context size to fit the code, let enough the capability to actually analyze it. Summarize? Sure, but it can only summarize what it has in context.

TLDR: data is something you collect over time from users, so you shouldn’t let the contracts for it mindlessly drift, or you might render old data unusable. Keeping those contracts in one place helps keep them organized.

But that explanation sucks if you’re actually five, so I asked ChatGPT to do that explanation for you since that would be hard for me to do:

Here’s a super-simple, “explain it like I’m 5” version of what that idea is trying to say:

🧠 Imagine your toys

You have a bunch of toys in your room — cars, blocks, stuffed animals.

Now imagine this:

• You put some cars in the toybox.

• You leave other cars on the floor in another place.

• You keep some blocks in a bucket… and some blocks on the shelf.

• And every time you want a toy, you have to run to a different spot to find its matching pieces.

That would be really confusing and hard to play with, right? Because things are spread out in too many places for no good reason.

🚧 What the blog is really warning about

In software (computer programs), “state” is like where toys are stored — it’s important information the program keeps track of. For example, it could be “what level I’m on in a game” or “what’s in my cart when I shop online.”

The article says the biggest mistake in software architecture is:

Moving that important stuff around too much or putting it in too many places when you don’t need to.

That makes the program really hard to understand and work with, just like your toys would be if they were scattered all over the place. (programming.dev)

🎯 Why that matters

If the important stuff is all over the place:

• People get confused.

• It’s harder to fix mistakes.

• The program gets slower and more complicated for no reason.

So the lesson is:

👉 Keep the important information in simple, predictable places, and don’t spread it around unless you really need to. (programming.dev)