The fact that Gentoo, unusually among distros, actually supports (unlimited) multiple versions of a package and for users to pick and choose their versions, means there is a *lot* of latitude for isolating the dangers of slopcoding destroying a package. It's generally always possible to discover that the project fell apart and stopped working, and just tell portage to reinstall the old version. Removing slopcoded trash from the distro is "simply" a matter of removing one choice.
eschwartz@fosstodon.org
Posts
-
rsync was basically done until the maintainer discovered vibecoding -
rsync was basically done until the maintainer discovered vibecoding -
rsync was basically done until the maintainer discovered vibecodingThat doesn't mean we have to put up with horrid slop, it just means that blanket forbidding all LLM assisted software is in practice unenforceable outside our community (where we cannot analyze PRs and require assertion of non-use).
Inevitably the result of slop is that the software deteriorates and doesn't work, and Gentoo may respond by freezing updates or removing it entirely (see chardet being frozen).
We do what we can, and we make our disapproval clear regarding the rest.
-
rsync was basically done until the maintainer discovered vibecodingGiven a choice between freezing all packages before vibe coding was "discovered" and packaging upstream releases, the former is not fully practical. The Gentoo social contract requires following council mandated policies about how one interacts with the Gentoo project, but doesn't control what other projects merge.
The kernel is slopcoded too, but we can't exactly do without that, now can we? Well, okay, we recently added experimental GNU Hurd support.

-
to be absolutely clear: alpine is *not* switching to systemd or implementing a 'systemd compatibility layer'.Basically, if you're gonna support a frankensystem where packages can either be compiled against one init system / seat manager / udev impl / lots more, or another one, it really helps to have the concept of USE flags, and I don't know what Debian does to try to support "packages depend on systemd, but we also support openrc instead" without USE flags. Maybe "foo-systemd" and "foo-openrc" packages? Sounds terrifying. "Openrc derivative with overridden repos"? Pain².
-
to be absolutely clear: alpine is *not* switching to systemd or implementing a 'systemd compatibility layer'.The Gentoo gui installation ISO uses kde and openrc, and connecting to WiFi to begin installation means using the NM applet. It works quite well, except for the part where kde really wants to encrypt your wifi password with the account keyring, which as a live ISO doesn't exist. (So, routine "fail to store the password and then go back into settings and re-enter the password" on every ISO boot.) But that's not the fault of an init system.

-
to be absolutely clear: alpine is *not* switching to systemd or implementing a 'systemd compatibility layer'.I have no particular idea what Debian might have done there, but generally the preferred alternative to systemd is using elogind anyways. Which should work fine. You could also try speaking to the upstream maintainers of $PACKAGE about using libseat where possible. Gentoo should support any configurations possible upstream, and possibly relevantly, Gentoo will *rebuild* if you change your configuration, not use libsystemd.so compiled binaries on openrc.
-
to be absolutely clear: alpine is *not* switching to systemd or implementing a 'systemd compatibility layer'.I'm not really sure what you mean by that... Switching away from systemd would break KDE? Shouldn't be -- KDE Plasma is packaged by alpine (no systemd option) and supported just fine on Gentoo's openrc profiles.
-
to be absolutely clear: alpine is *not* switching to systemd or implementing a 'systemd compatibility layer'.Also relevant, Gentoo dropped eudev a year and a half ago on the grounds that it serves no purpose given systemd-utils can install standalone udev, and eudev was unmaintained and broken and did not in fact provide the library APIs which software compiled against, due to its being unmaintained:
Nonetheless, Gentoo still proudly supports non-systemd installs.

-
to be absolutely clear: alpine is *not* switching to systemd or implementing a 'systemd compatibility layer'.eudev exists, at least today, primarily because there's a vocal subset of people who get extremely angry if a package name or file on disk includes the word "systemd" in it, and will not consent to running a udev implementation if any internal filename happens to be /usr/lib/systemd
These people literally configure their package manager to silently delete any files from ANY package matching the glob `*systemd*`. Prank tip: write a program including "systemdetails.py".
-
Fellow AI haters!The 2026 MBA Layoffs is ongoing right now, for the Americans among us. Just saying... the name is right there...
-
https://safedep.io/megalodon-mass-github-repo-backdooring-ci-workflows/