Honestly though, the argument against systemd is that it moves too much stuff into init, but I don't think it does enough of that, it's still extremely conservative, like, SD-DBus should be using binder x-port IMO.
The thing is systemd really doesn't: the things people claim "shouldn't be in an init system" aren't - but there are systemd branded versions of a lot of basic facilities because you generally need something like them in a usable system.
And a lot of those utilities are just straight better then the alternatives, or at least make a decent practicality vs correctness trade off for desktop Linux.
systemd-cryptenroll for example is just straight up much easier to use for most applications of FDE, unless you're really doing network unlocking with something like Clevis.
No, one complaint (out of many) against SystemD is that it moves too much complexity into PID 0 which is a very special process on Linux that must not crash ever or the whole system goes down with it. The init system is one thing that SystemD insists on running under PID 0 even though it could be designed otherwise.
But PID 0 on Linux is the idle task…? Init is (usually) PID 1, PID 0 kinda just means that nothing is running on a given CPU (with caveats), also killing 0 has special meaning because well it's not a real process…
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.
Funny how you chose `ioctl` specifically to illustrate your point, when that's quite uniquely just a syscall inside a syscall… Ideally, high level library devs should abstract ioctl while treating libc as the stable userland kernel ABI, as has always been the case for the BSD's.
I think the real problem is GNU libc devs' unwillingness to stabilize it (not sure why, perhaps the menace of HURD still haunting them?)
I chose "ioctl" precisely because it has maximum simplicity, in order to show that in "nolibc" it needs externally provided syscall numbers.
Some other syscall wrappers from "nolibc" may be somewhat more complex, by doing some processing on the arguments, before invoking a generic syscall wrapper like "my_syscall3", "my_syscall5" etc. (where the number from the name of the generic syscall wrapper refers to the number of syscall arguments).
Ioctls are the single most complex example for API design, cause like, that's another opaque interface inside one opaque interface. Ioctls will be routed to the desired kernel module (driver) depending on the FD, after all.
Basically all I'm saying is that a syscall "ABI" is but a red herring for everyone but the [mainline] Linux devs themselves.
GenAI is only useful to bump terrible up to mediocre, so it'd be really stupid to spend time honing one's prompting skills. And as you noticed, so far 96% of the population agrees.
It’s really not going to bump up terribles to mediocres. It’s only going to mask the terribles and make it harder to assess intelligence and talent. Underlying human intelligence is not going to get a boost from AI. Intelligence is mostly innate. I would even argue that AI will make average humans marginally dumber for the most part.
Yeah, also, isn't it already proven that offloading thinking onto chat bots causes some kind of irreversible brain damage/dementia? (also BTW "mediocre" is still not "acceptable" despite Slophauses trying to convince people otherwise)
Of course symmetric or even carrier grade NAT is not a firewall, but it's so silly to ignore real world implications thereof in an IPv4 only deployment scenario. Firewalls aren't foolproof and in real life you average NAT is more likely to be closer to that.
Honestly, coding with a chatbot's "help" just slows me down. Also the progress in chatbot space is minimal (at least it feels like that from an end user perspective), essentially nonexistent since like 2024. I only use them cause all search engines are broken on purpose now. It's truly terrible times we live in, but not because the robots could replace us, rather because nontechnical managers are detached from reality as they always were and want us to believe that.
The worst blow for me was search engines, you're so right that are broken on purpose now, that's a total bummer. Also wondering how Google is not loosing money from non shown ads in search
It doesn't really feel like those companies care about money anymore, to me at least it feels like we're in the middle of an ongoing total economic collapse and their actions seem to concur. Why else would they be stockpiling assets, infrastructure and all the tangible stuff they avoided so far? May sound slightly conspiracy-ish, but honestly, it's somehow the theories pushed into mainstream that are laughable nowadays.
It caught my eye also but the article was interesting so I'll forgive OP :-)
On the topic of tamagotchi, if you happen to have a flipper zero there is emulator for it :-) my kid enjoyed it for while and it saved me a few bucks from having to buy one.
Honestly though, the argument against systemd is that it moves too much stuff into init, but I don't think it does enough of that, it's still extremely conservative, like, SD-DBus should be using binder x-port IMO.
reply