It’s not just server-side: A lot of fingerprinting happens client-side, for example using a canvas to check what features your graphics card supports. You can see this in action via services like https://coveryourtracks.eff.org/ or https://amiunique.org/
A pull request is very much a proposal: It is a proposal to make specific changes to the code-base. The developers are not forced to accept it in any form, and discussions can take place in the pull request, should the developers (or third parties) not agree with (the exact form of) the proposed changes. Which is exactly what happened in the systemd pull request, to the extent that the actual developers had to lock the thread.
In the case of systemd, the “someone”, or rather the “someones”, who accepted the pull request also included the lead developer on the project, namely Lennart Poettering. Who else do you propose should decide what pull requests and other proposals to accept?
What do you mean, he “admitted” that?
It’s quite literally the first thing he wrote in his pull request to systemd:
Stores the user’s birth date for age verification, as required by recent laws in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc.
And the second paragraph of his pull request to arch:
Recent age verification laws in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc. require platforms to verify user age. Collecting birth date at install time ensures Arch Linux is compliant with these regulations.
Development stopped not because LILO didn’t need any changes, but because of its limitations (source):
NOTE: I have finished development of LILO at December 2015 because of some limitations (e.g. with BTFS, GPT, RAID). If someone want to develop this nice software further, please let me know …
Also, I dunno what your position is on this, but it is amusing to see calls for Canonical to replace GPL licensed software, with something with a more lenient license (BSD-3-clause). Normally that would cause outrage around here
I guess they have their own fork of it?
Upstream hasn’t seen a new release, nor any commits, since 2015: https://lilo.joonet.de/
ETA: It is also my understanding that LILO fundamentally does not support reading filesystems, while Canonical want to keep SquashFS, among others. Adding support for that to LILO, along with whatever other features are missing, would likely be a major undertaking
and another thing: im not mad. please dont put in the newspaper that i got mad.
It’s probably easier to strip down GRUB, than it is to resurrect and add missing features to a project that has been dead for 10+ years
It hasn’t been rolled back. You can go to the systemd repo and look at the main branch for yourself.
Here’s the commit. Just click through and see if the code was subsequently removed from any of the files. You’ll find that it wasn’t.
https://github.com/systemd/systemd/commit/7a858878a03966d2a65ef9e8f79b5caff352ac53
Did you reply to the wrong comment? I have no idea how you managed to get all that from my comment. All I’m saying is, "when you hear hoofbeats, think of horses, not zebras”
There is no verification and there is no surveillance: You can enter whatever value you want, or no value at all.
It’s exactly like the other personal information (full name, location, phone numbers) you can enter, when you create an account using standard tools on Linux
That’s a lot less likely to be the case; I am aware of just one example of what you describe, and that’s the example you give, whereas I’ve “sped up” my own code many times, by accidentally breaking stuff.
Rather than assume the presence of backdoors, the rational thing is simply to work out why you are seeing a difference in performance, and to determine if you fixed something by accident, or (the more likely scenario) if you broke something by accident
Ignoring /boot, what is the benefit of putting everything else in different subvolumes? As opposed to just one subvolume for / and one for /home, which is what I currently have. It just looks to me like it’d be extra work, but I’m probably missing something
I also saw a 4.5 second boot time speedup from installing mine. I have NO IDEA how, but it’s happened.
If I saw a speedup that I didn’t understand, then I’d worry that I had accidentally broken something. It’s easy to get speedups by not doing things correctly
They’ve already been using Claude for at least the last few months; you’ll find a CLAUDE.md file and related settings in the uv repo if you look
Typst’s biggest weakness is that the ecosystem is still young, so you may not be able to find equivalent packages to those you’ve been using in Latex. But for me, personally, it has been a joy to use
Hopefully nobody tells the corpos that they can just use BSD if they want a MIT licensed kernel and user-land
On windows if you don’t disable bitlocker, then login at least once to your outlook.com account so it can backup the key.
That’s not a bad idea, but if you are going to be using Linux then I’d recommend exporting the key and, for example, saving it in your password manager and/or on a USB stick (preferably after encrypting it). That way you can easily decrypt the partition using dislocker. Also, personally, I do not want to my encryption keys to shared with Microsoft, but that’s just me ¯\(ツ)/¯
Do yourself a favor and get a USB stick with Linux on it, regardless of whether or not you are going to use it to install Linux.
When stuff breaks, you’ll regret not having a bootable media like that. Also, if you are using windows and Bitlocker (the default these days), then be sure to store your encryption keys somewhere, where you can easily access them. Otherwise you won’t be able to access your Windows drives
“Free” and “libre”. But this has only ever referred to the software itself, not to the hardware needed to use it.
That should be obvious, since otherwise almost no OSS would be FLOSS. After all, you have to buy a PC or another device to run it
There are a billion of these frameworks. This site allows you to compare a lot of them, though it does not yet include dev.css:
https://dohliam.github.io/dropin-minimal-css/