It took a while to get used to zsh bailing on non-matching wildcards, but it honestly makes a lot more sense

Looks neat, but I don’t think that you can claim to be “Private and offline” when the default is to broadcast what you’re playing. That feature should be opt-in, not opt-out

Which is not much different from the disclaimer about GURU, though GURU does a much better job at explaining the risks involved in using it:

Disclaimer

Please note that the GURU project is maintained and reviewed entirely by Gentoo users. It is only subject to minimal supervision from individual Gentoo developers, and is not supported by projects such as Gentoo Security. While our Trusted Contributors do their best to keep GURU safe, it is possible for it to contain vulnerable, badly broken or even malicious software. You are using it on your own responsibility.

The AUR domain is aur.archlinux.org and it is linked from the menu-bar on archlinux.org. If AUR is not official, then the Arch sure is sending mixed signals to its users

AUR is not unique in being a user repository, but it seems somewhat unique in having basically zero oversight. Which is a bad idea for reasons that should be painfully obvious by now.

For comparison, Gentoo’s GURU repository allows everyone to submit packages, but limits the ability to accept these submissions to a subset of trusted users

I wonder percentage of Arch users are actually capable of verifying that an AUR package is safe to install. I doubt that the number is very high, especially with the growing popularity of the distro

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

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 ¯\(ツ)/¯