A small set of people are merging changes to various Linux components to make sure every application knows your birth date.
This is being done rapidly by people with questionable justifications and being merged with no youth and few marginalized people involved.
Sure. I also don't like the unforced error of systemd taking the patch in. Really the proposed age verification laws need stopping in each country's legislature.
Distros (which package systemd) can choose to revert the patch that went in before building and packaging, which is quite manageable.
So now every single distro is supposed to maintain its own separate fork of a very fundamental component?
Or just never update it ever again?
Really they need to start moving away from systemd, but it's kind of really bad because A. the whole attitude of complying in advance is very dangerous and B. it's going to take some time for many to move away even IF they are willing to do so. (But there are a ton of benefits in doing it. Systemd is a hot, bloated mess and really needs to go in general anyway.)
I'm more concerned about A really. If it starts getting into everything we're screwed no matter what.
@nazokiyoubinbou @k3ym0 @wwahammy
> So now every single distro is supposed to maintain its own
No... distros already maintain a per-project "packagefiles", these are sometimes quite involved scripts that work at the level of how to build a package. This is how they get a .deb or a .rpm pop out. It's a lot of painstaking work, but, eg, the packaging scripts offer features like embedding patches to be applied or reverted in the source package itself.
So reverting this change is fairly easy.
@hopeless @k3ym0 @wwahammy I'm aware they have stuff like that, but reverting this is much more complex than you think. This isn't a one line change. They're adding whole new packages that collect and report user info, systems that check, etc etc. Getting it back out is a significant enough change that, for all intents and purposes, it really is a fork, not just simply a packaged version.
It's also something they'll have to keep at. At least one person involved in this is on quite a crusade here. The stuff to remove and how to compensate will change frequently. So it's not just an automated fork...
@nazokiyoubinbou @k3ym0 @wwahammy
I haven't looked at the patch, but typically all you need to revert is the thing getting called / built / installed at all. It can still be there but it's either not built if it's C, not installed in the distribution binary, or just NOPped out.
Often these kind of things have their own build options and can just not be built at package-time.
@hopeless @k3ym0 @wwahammy They've submitted a number of PRs.
I already see a whole separate package added (systemd-userdbd) for example.
It's a lot of stuff. Again, this is not a one line change. And the adjustments will have to change with each new such PR. By definition it will become a fork and it will require as much maintenance as a real fork even if you want to call it something else.
And hey, someone may actually do that and perhaps everyone will switch. Maybe.
Of course, a much better solution is just to fix the distro to stop relying on a bloated hot mess that keeps insisting over and over on stepping way outside of its scope anyway... There are lots of alternatives. The old sysvinit worked quite well, but OpenRC looks nice and modern with actual standards.
@nazokiyoubinbou @k3ym0 @wwahammy
OK but if you don't like systemd-userdbd, you can even build it if it forces you to and then just not include it in the package.
This is not the same as a fork, with lists of patches routinely applied at package time, you have a lot of power over the package, either just by build options or by disabling and snipping stuff.
Yes you need to know the code to do it, but the package owners do know the code for the package they are responsible for.
1/2
@nazokiyoubinbou @k3ym0 @wwahammy
... the other thing to bear in mind is if Debian do this, all downstreams of Debian (Ubuntu, Mint etc) inherit these changed Debian packages. Redhat is the other main packager and it also has a lot of downstreams.
But it's unclear if, eg, Ubuntu (or IBM), which want to make money, will follow what would be a principled decision by Debian (if that happened) and not just ship the upstream package with all the contentious stuff in.
Eric Schultz
k3ym𖺀
degenerating degenerate
notsoloud
Nazo