Don't get me wrong, I'm happy to attribute a lot of malice to Microsoft, but in this case I really do believe that it was incompetence. Everything I've ever read about 90%+ of hardware vendors is that shipping hilariously broken firmware is an everyday occurrence for them.
This reminds me of when I enrolled only my own keys into a gigabyte AB350 and I just soft-bricked it because presumably some opt-rom required MS keys.
I exchanged it for an Asrock board and there I can enable secure boot without MS keys and still have it boot cuz they actually let you choose what level of signing the opt-rom needs when you enable secure boot.
What I want to say with this is that it requires the company to actually care to provide a good experience.
We used to have “SEO spam”, where people would try to create news (and other) articles associated with some word or concept to drown out some scandal associated with that same word or concept. The idea was that people searching on Google for the word would see only the newly created articles, and not see anything scandalous. This could be something similar, but aimed at future LLM’s trained on these articles. If LLM’s learn that the word “Prism” means a certain new thing in a surveillance context, the LLM’s will unlearn the older association, thereby hiding the Snowden revelations.
With two “--force” options, that is essentially equivalent to “echo o > /proc/sysrq-trigger”, isn’t it? I would think that one “--force” would have the actually desired effect.
Varlink is everything that the usual systemd detractors should want; no binary formats, simpler mechanisms, based on stdout/stdin of processes.
Also, systemd did not create varlink, nor did they create D-Bus. They simply adopted them as the most suitable and established methods for IPC at the time.
> The journal grows massively and is unbounded by default.
Wrong. By default, the journals aren’t even saved to disk. And if you do configure them to be saved to disk, they are limited by default to 10% of the file system size, and at the most 4GiB.
> It took me about 30 minutes of googling
Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual page for that setting.
> Too many things just happen in the background that never used to.
The world is changing. Mounts aren’t static anymore; you must treat a mount just as a running service; run “systemctl stop srv-foo.mount” instead of just yanking out a file system from underneath the feet of any and all services which depended on that mount point.
> I never did figure out how to set the MTU in the configuration either.
“man systemd.directives”, search for “MTU”. Took maybe two seconds.
> Wrong. By default, the journals aren’t even saved to disk. And if you do configure them to be saved to disk, they are limited by default to 10% of the file system size, and at the most 4GiB.
I mean this probably depends on your distro. On Debian, it very much is saved to disk by default. And plenty of my 5GB VMs have in the past filled to 100% such that everything fails with write errors because the log files have consumed about 3GB.
> Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual page for that setting.
Again, fine if you know of the existence of that man page (I didn't) and know what option you're even looking for. Systemd always calls it journal as far as I knew, and doesn't use the syslog, so I didn't even think to google for syslog to change what I wanted.
> The world is changing. Mounts aren’t static anymore; you must treat a mount just as a running service
Thing is, it's all very well to say that, but it's downright dangerous to change the expectations that have held true for 30+ years without even a warning somewhere - e.g. running unmount popping warning "hey, we know you just asked for this to be unmounted, but we might just randomly remount it whenever because whatever you are doing is unimportant".
And this points to the root of the issue - UNIX has been following the UNIX way for over 3 decades. Suddenly, everything is changing, without any indication of things being different until stuff just doesn't work. This is exactly why people don't like systemd.
> > I had to learn the new systemd way of doing it.
> This, I strongly suspect, is your real problem.
Absolutely.
I've got a zillion other things to do, without spending hours every time I upgrade to discover all the new ways systemd has come up with to ruin my life.
When I am forced to interact with systemd, it always slows me down unnecessarily, because the only reason I'm looking at it at all is because it's because something has changed and it's causing me pain.
> On Debian, it very much is saved to disk by default.
Only relatively modern Debian versions. And even then, blame Debian, not systemd.
> It's downright dangerous to change the expectations that have held true for 30+ years without even a warning somewhere - e.g. running unmount popping warning
Firstly, umount “popping a warning” would break so many things, and then you really would have something to complain about. And if we really are talking about 30+ years ago, things have changed a lot since then, too. You used to stop and uninstall a service by finding its PID by running ”ps”, killing its process, and ”rm”-ing its files (and editing /etc/rc.local to remove the service’s startup line) But even before systemd, you would not dream of doing that anymore; you would run “invoke-rc.d thing stop”, or at least ”/etc/init.d/thing stop”, and use your package system to uninstall it. Those are new things since 30+ years ago.
No, I'll blame systemd. I've been using Debian for 25 years and we've only had systemd forced on us in the last maybe 5. OK, yeah, you're right. I'll blame Debian for forcing systemd on us, which is exactly the problem that Devuan is fixing.
Actually, I've been using SunOS and Solaris even longer than Debian. Putting scripts in /etc/init.d / /etc/rc.d isn't "new". It's been standard for at least 30 years. Actually, maybe making /etc/rc.d symlink to the /etc/init.d is early 2000s, I can't remember, but it's certainly not new.
But also, I've written many startup scripts in my time. And no, I absolutely wouldn't find its PID using ps and killing it. In my startup script, I'd save $! in a file, standardised in /var/lock for at least 20 years, and kill that.
And no, I wouldn't manually edit /etc/rc.local - because for decades it's run everything in /etc/rc*.d specifically to prevent the need to manually edit /etc/rc.local. None of this is new.
> umount “popping a warning” would break so many things
I mean, would it really? They've modified mount to pop up a warning to tell you that you manually changed /etc/fstab and what extra steps you need to do to placate systemd just to be able to mount your filesystem. Why can't unmount also do the same, e.g. gated on being run from an interactive tty? Having filesystems randomly mount themselves after you have deliberately unmounted them is actually dangerous.
> Consider quitting the technology business.
How about you consider having some manners?
Somebody responding to a question about why people don't like X with an explanation of how exactly X has changed their workflow for the worse doesn't mean that they should leave the technology business.
I'm sorry for you that your self-worth is so tied up in systemd that you can't bear to hear any criticism of it.
> Surprisingly, Rust, as of now, uses line buffering for both TTYs and non-TTYs.
> The FIXME comment shows the Rust team acknowledges that ideally they should check if something is executed in TTYs or not and use LineWriter or BufWriter accordingly, but I guess this was not on their priority list.
Cloudflare is well known for breaking DNS standards, and also then writing a new RFC to justify their broken behavior, and getting IETF to approve it. (The existence of RFC 8482 is a disgrace to everyone involved.)
> To prevent any future incidents or confusion, we have written a proposal in the form of an Internet-Draft to be discussed at the IETF
Because without the ANY query it is much more difficult for people to immediately enumerate a full list of all subdomains and IPs for a given domain name. They need to be queried individually.
That is false. If all you want is all subdomains and IP addresses, you can query each enumerated name for A records; you get any NS records (or CNAME records) on that name for free in the answer, and can follow those. ANY queries are not needed, and their removal does not help you in the slightest.
The problem with long lines was reportedly markedly improved in Emacs 29:
Emacs is now capable of editing files with very long lines.
The display of long lines has been optimized, and Emacs should no
longer choke when a buffer on display contains long lines. The
variable 'long-line-threshold' controls whether and when these display
optimizations are in effect.
A companion variable 'large-hscroll-threshold' controls when another
set of display optimizations are in effect, which are aimed
specifically at speeding up display of long lines that are truncated
on display.
If you still experience slowdowns while editing files with long lines,
this may be due to line truncation, or to one of the enabled minor
modes, or to the current major mode. Try turning off line truncation
with 'C-x x t', or try disabling all known slow minor modes with
'M-x so-long-minor-mode', or try disabling both known slow minor modes
and the major mode with 'M-x so-long-mode', or visit the file with
'M-x find-file-literally' instead of the usual 'C-x C-f'.
In buffers in which these display optimizations are in effect, the
'fontification-functions', 'pre-command-hook' and 'post-command-hook'
hooks are executed on a narrowed portion of the buffer, whose size is
controlled by the variables 'long-line-optimizations-region-size' and
'long-line-optimizations-bol-search-limit', as if they were in a
'with-restriction' form. This may, in particular, cause occasional
mis-fontifications in these buffers. Modes which are affected by
these optimizations and by the fact that the buffer is narrowed,
should adapt and either modify their algorithm so as not to expect the
entire buffer to be accessible, or, if accessing outside of the
narrowed region doesn't hurt performance, use the
'without-restriction' form to temporarily lift the restriction and
access portions of the buffer outside of the narrowed region.
The new function 'long-line-optimizations-p' returns non-nil when
these optimizations are in effect in the current buffer.
reply