> And Gnome 3 doesn't really have anything to do with Linux.
There's a very hard push on getting Gnome 3 aligned to systemd. Gnome is actually my preferred DE on Linux when I choose to use one. But compatibility with Unix systems is becoming harder every day.
Yes even KDE recently introduced a new display manager that is completely tied to systemd. For that reason it's not supported on FreeBSD. But sddm still works of course. But it is a worrying precedent.
From the gnome team this was to be expected because they are beholden to RedHat/IBM and the other big distros who push systemd heavily. But from the KDE team I didn't.
I've stopped my monthly KDE donations for this reason. Just to send a message that this isn't ok.
Why can't they? Upgrading and rebooting is kinda the standard response for most security issues. So I would expect something like Ansible's playbooks for this exact scenario. You might also have it setup as a staggered rollout.
The only reason I recommend this paper is because I encounter so many people that have a very myopic view of the software that they’re building. They are focused on individual features and how to quickly made them happen regardless of what happens to its cohesiveness. You start to talk about interfaces and contracts and they’re like a deer blinded by a car’s headlights.
I wouldn't start to think of someone as a real developer unless they've at least designed & written something of at least 10K LOC or so of complexity from scratch a few times. At least, you're not going to be able to understand these lessons and characterizations of programming in the large unless you do have at least that level of experience.
The larger and more varied projects that you have designed from scratch, the more you start to understand what programming/designing is really about.
I agree with this sentiment but I think LLMs are really close to the Brooks idea of a silver bullet.
I don't know if, overall, it's a 10x improvement or 6x or 14x but it's a serious contender. Part of it is the LLMs are very uneven in their performance across domains. If all I build is simple landing pages, it might be a 100x improvement. If I work on more complex, proprietary work where there aren't great examples in the training data then it might be a 10% improvement (it helps me write better comments or something)
All available evidence points to it being an incremental improvement at best. Higher claims are attributable to the psychological effect of the AI sycophancy problem which erases the Dunning-Kruger effect and makes even experts extremely overconfident.
You still have to read the output of your LLM. Learning by reading alone and not doing is not nearly as effective.
"claude, connect to a k8s pod in prod and grab a 30s cpu profile, analyze and create a performance test locally for the top outlier, verify your fix and create a PR"
The thing is you can actually write quite good C code (see OpenBSD project). The power of C is that it's pragmatic. It lets you write code with you taking the full responsibility of being a responsible person. To err is human, but we developed a set of practices to handle this (by making sure the gun is unloaded and the safety is on before storing it to avoid putting holes in feet).
I like type checking and other compile time checks, but sometimes they feel very ceremonial. And all of them are inference based, so they still relies on the axiom being right and that the chain of rules is not broken somewhere. And in the end they are annotations, not the runtime algorithm.
It may, but it still requires careful annotations. So you should hope that you have not made an error there and described the wrong structure for the code.
It seems like you have this backwards. Messing up lifetimes in safe Rust can't cause unsafety; the compiler checks if the lifetimes are valid, and if they're not, you get a compiler error. You don't need to "hope" you did it right because the entire point is that you can't compile if you didn't.
On the other hand, when you're relying on your ability to "actually write quite good C code"...you'd better hope that you have not made an error there. In practice, some of the most widely used C libraries in the world still seem to have bugs like this, so I don't really understand why you'd think that's a winning strategy.
> it's still an enormous pain to use packages as libraries even with apt and friends. And once you get outside of apt, you're in an endless hellscape
I strongly doubt that. Especially with tools like pkg-config that let you generate the set of flags for a package. If anything I've seen more horrendous build scripts from people that are trying to be clever and trying to support everything under the sun.
curl | sh is more prevalent in Linux where you can expect a stable ABI from the kernel and sometimes GNU libc. No such things in BSD land. Packages are built against a release always. They don't maintain binary compatibility.
They stole the axios's npm keys and they uploaded malicious artifacts. They did not takeover the axios's repo. The issue is with packaging and distribution, not with code.
Because the way npm works means that as soon as a developer key got stolen, a lot of people got pwned. The key is the only barrier.
Compare that with the average distro. You would have to compromise the developer infrastructure (repo or website) and publish a new version without them being aware while notifying the maintainer that’s its ok to merge the new package script in the distro repo. Hard to pull off in high profile projects.
Ruby gems and CPAN have build scripts that rebuild stuff on the user's device (and warn you if they can't find a dependency). But I believe one of the Python's tools that started the trend of downloading binaries instead of building them. Or was it NPM?
Python's pip predates npm, installs dependencies automatically, can include binaries, and the old-style packages could run arbitrary code during the install.
Ruby gems are older than that, but I have no idea what capabilities it has/had.
There's a very hard push on getting Gnome 3 aligned to systemd. Gnome is actually my preferred DE on Linux when I choose to use one. But compatibility with Unix systems is becoming harder every day.
reply