The comment you replied to is a direct reply to the comment you linked - I don’t think it was intentional, but if it was, then I’d like to say it’s not a very helpful reply as OP already read it.
The comment you replied to is a direct reply to the comment you linked - I don’t think it was intentional, but if it was, then I’d like to say it’s not a very helpful reply as OP already read it.
someone just plain lying about what OS they’re using in order to break fingerprinting.
The idea with avoiding fingerprinting is to look like whatever the biggest group of users looks like, because that’s who you share the fingerprint with. If you use an uncommon value for something, you make fingerprinting easier.
That’s one of the reasons why for example Vivaldi on Linux sets its user agent to match the latest version Chrome on Windows.
Fair enough. I misunderstood, my bad.
Then what’s the meaning of this whole part?
On non-corpo linux syslog can be disabled if you want, though I’d prefer to just symlink/mount /var/log to a memory filesystem instead.
Is it just a random tidbit that could be replaced with a blueberry muffin recipe without any change of meaning of the whole comment? Because it sure won’t help OP at all with their Arch-specific question, so it’s either that, or it provides contrast to the “corpo Linux”, which is how I interpreted it.
And here’s the remaining part of your comment I left out, just to make sure people won’t lose the context between two three sentence long comments (for those without any attention span, it comes before the previous quoted part):
If you’re on arch you use redhat’s garbage.
On non-corpo linux syslog can be disabled
systemctl disable --now systemd-journald
I’d prefer to just symlink/mount /var/log to a memory filesystem instead
Set Storage=volatile
in /etc/systemd/journald.conf
But it’s a design for designs - it tells you how to design your own UIs, it doesn’t dictate what for example a calculator app should look like. You can follow Material Design and still end up with a terrible UI design.
Surely that’s enough for some distinction, right?
They probably fixed all the bugs they considered essential, and the rest is just nice to have fixes that can be moved to the next cycle if necessary (and they still have a week to work on them before release, although they might be careful not to introduce severe bugs now).
The general idea with this approach is that it doesn’t make sense to block a release on a few bugs worked on by only a subset of available developers and having the rest idle - the project can be finished faster by moving the remaining tasks over to the next release and accepting the bugs in the meantime.