12 ms·
Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for
by marcodiego 5y ago
Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.
- api 5y agoIt’s a functional improvement over old init, but the thing I hate about it is how unnecessarily arcane it is. It seems “designed for job security” or more likely designed for consulting revenue. There is absolutely no need for its command names and everything else about it to be so counterintuitive.
- rnd0 5y ago>It seems “designed for job security” or more likely designed for consulting revenue. Exactly this, yes; and that's why it was pushed the way it was. I dread the day when systemd or an init system just like it consumes the BSD world.
- api 5y agoI feel the same way about Postgres. It's powerful but it's insanely arcane and full of land mines and footguns. It's great for forcing you to hire consultants, DBAs, or pay cloud providers a lot to run it for you.
- int_19h 5y agoWhich SQL RDBMS isn't, though? Postgres is a breeze compared to someting like DB2. High-performance relational databases just seem to be an inherently arcane target.
- api 5y agoCockroachDB is probably the best example of a modern RDBMS.
- petre 5y agoMySQL and SQLite, but the former is not a real transactional database, it's quite a joke compared to Postgres. The latter is a file based database. We use MySQL at work and I am exasperated by it. It's possible that even Firebird is better.
- posix_me_less 5y agoWhat exactly do you miss in MySQL compared to Postgres? With InnoDB it can do transactions, no?
- petre 5y agoProper transactions, like the ones that aren't closed by create, alter or drop table, proper rollbacks, statement timeouts so that a single stalled statement doesn't block the table until you kill it, subscribe/notify among other things. My issue is primarily with performance under load, where you'll eventually end up with lots of blocked queries and an unresponsive database and the only way to solve it is to throw hardware resources at it. Do yourselvs a favour and pick Postgres for new projects. If you properly vacuum your tables you'll probably be fine.
- int_19h 5y agoIf Postgres is unnecessary arcane, then surely MySQL is that squared, given all the legacy traps? You know, stuff like "utf8" not actually being UTF-8.
- Too 5y agoWhat is arcane about systemctl stop and journalctl --since?
- api 5y agoHow do I list what's running? I have to Google that every time. How do I list units? What are units? What the fuck are... and so on. The output is hard to read. The files are all over. The directory and file names are counterintuitive. It’s just… needlessly arcane. Git has the same problem but at least git is excellent enough software in other ways that it makes up for the horrible UX. Systemd is mediocre.
- gotar 5y ago> How do I list what's running? systemd-cgls > How do I list units systemctl list-units Simply use tab completion (like in zsh). And do not dare to compare UX-nightmare from git with systemd...
- klysm 5y agoI’m young enough to have missed the transition and really like systemd, I rely on it for as much as I can
- MuffinFlavored 5y agoLike what if you don't mind me asking, and what did people used to use as an alternative?
- dharmab 5y agoFor the init system, the most common predecessor was a combination of sysvnit and "initscripts" (a shell script for each daemon on your system). Writing the init scripts was simple for the most basic cases but quite complex for complete, bug free case coverage. A big appeal of systemd for packagers and sysadmins was the relative simplicity of unit files. Now we just have to fill out a simple boilerplate INI style file for most services.
- kzrdude 5y agoAnd less distro divergence in how to write the service scripts, or how to start services etc.
- Blikkentrekker 5y agoIt was not. There is strange false history that systemd replaced sysvinit, which occurred only on Debian, because Debian was the last major system to discard sysvinit. Gentoo had replaced sysvinit with OpenRC in 2006; Fedora and Ubuntu were using Upstart in 2005. systemd primarily replaced Upstart and systems that used Runit or OpenRC tended to have stayed with them. Frankness be, this false history seems to be crafted in order to compare it with very outdated technology to make it look good. Obviously systemd is better than sysvinit, technology that almost all systems but Debian had discarded long before systemd was even started. The issue is whether it compares favorably to Upstart, runit, and OpenRC, and to the first I would say yes, because Upstart was full of very ugly hacks and didn't deliver it's ambition. In the second two cases, their mode of operation is so different that it's hard to compare. runit was inspired by daemontools and is very simple and effective and works in a very different way from most models of service management; OpenRC is backwards compatible with sysvinit and is essentially a large library so that init scripts typically need nothing more than something such as: #!/sbin/openrc-run command=sshd args="-D" daemon=no provides=ssh after=net Or something similar to work. I forgot the exact syntax but it works similar to simply assigning some variables and it handles the rest, but it still gives one full access to the shell to use whatever shell functionality one wants.
- a-dub 5y agoit's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to easily take the case off of pid 1 when it misbehaved.
- wrycoder 5y agoRight. I have a simple rule: don’t use a GNU/Linux system that uses systemd. It doesn’t respect the Unix philosophy. It’s trying to turn it into Windows. I’m waiting for Microsoft to buy Red Hat. Failing that, IBM.
- gtirloni 5y agoUh? https://www.redhat.com/en/about/press-releases/ibm-closes-landmark-acquisition-red-hat-34-billion-defines-open-hybrid-cloud-future https://www.redhat.com/en/about/press-releases/ibm-closes-la...
- cfors 5y agoIBM already purchased red hat for $34b 3 years ago, so no need to wait any longer :)
- GekkePrutser 5y agoI think he means that MS would buy IBM and RedHat with it. I doubt they will though. Like others have said MS buying Canonical would make a lot more sense. And there have already been a lot of overtures.
- wrycoder 5y agoWhat I meant is that MS could buy Red Hat from. IBM. Failing that, buy IBM.
- deleted 5y ago
- INTPenis 5y agoThis is the comment I came to upvote and agree with. I am considered a Linux expert in my field but the truth is that I really don't know how systemd internals work well enough to read that review and fully understand it. The review did teach me some things about what Units really are, more than just services and timers, but other than that it was too deep for me. And yet I work full time with Linux systems, building services on Linux systems for major clients and government contracts. From my perspective as a user and operator of Linux, systemd has been nothing but good things.
- coldtea 5y agoI like systemd, but I abhor the arrogance and manouvering with which is was pushed.
- mekster 5y agoThen, thank god it was pushed or else it would've been a pull and push war to cause fragmentation.
- kaba0 5y agoYou mean the completely democratic vote done multiple times by Debian?
- coldtea 5y agoNo, I mean the bait-and-switch embrace-extend-extinguish with false pretexts, documented quite well in TFA...
- ChuckMcM 5y ago" For me and most users, the transition was fully imperceptible." So far. I hope for your sake it continues to be so.
- eadmund 5y ago'I am altering the deal, pray I do not alter it further.' --Darth Lennart I actually appreciate, now, what systemd is trying to do, but I am not certain why it has to take over home directories and everything else to do it. And I am really uncertain why it has to have such bad taste. I can get why it uses C, even though IMHO that is a mistake. But .ini files? D-Bus? XML‽‽‽ Oh well, at least it's not YAML.
- roenxi 5y ago> the transition was fully imperceptible A normal user will never really link the features they see or do not see back to the init system. I'll draw a parallel with the worst subsystem being cut out of modern Linux - X Windows. As far as I can tell Linux is missing good macro systems that can record actions taken by a user, then replay them. For loops for non programmers, basically. This isn't because the idea is radical, but because implementing the vision historically needed a programmer to understand X - which is too hard. There is a hidden link between the subsystem being awful and programs not existing. Similarly, the monoculture created by systemd is influencing how the future of Linux evolves by making some things easier and others harder. End users won't be able to detect those influences though, and unlike X's problems systemd is likely a net positive. Systemd easily improves on the old init scripts.
- vladvasiliu 5y ago> Similarly, the monoculture created by systemd is influencing how the future of Linux evolves by making some things easier and others harder. While I agree with the broader point about (any) monoculture, I don't think that this can be blamed on systemd. Systemd did not itself create the monoculture. When it came up, it was one of a multiculture. Distro maintainers then chose it en masse so that it became a de facto monoculture. I'm not saying that necessarily makes it the best choice, though. On a slightly different note, I find such comments funny in a way, because one of the reasons given for Linux's lack of market share on "the desktop" and, broadly, as a platform for "enterprise" software (think Adobe, etc.) is because the ecosystem is so fragmented. So, essentially, the platform isn't considered because it's not a monoculture (as would be Windows and Mac).
- usrbinbash 5y ago> the monoculture created by systemd systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, but I will happily post it again: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/ https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Such a thing doesn't happen if the thing offered isn't an improvement over what was before. As a matter of fact, this doesn't even happen if the thing offered is only a small improvement. We have seen this time and time again in Programmig languages: Exciting, clever new things that offer real advantages vanishing into obscurity because while they were better, they were not better by a large enough margin. Diversity is great if it offers advantages. Different kinds of RDBMS are a good example. Different kinds of shells. Rust being there as a C alternative, Go being there as a Java alternative, Julia as a possible Python alternative, WASM instead of JS. All great. But keeping something mainstream just because its different, adds no value. People can and do still use other init systems, but I am very glad I no longer have to wrestle 400-line sh init scripts on my production servers.
- nomorecommas 5y agoPretty much. Wish I could say the same for pulseaudio.
- ajvs 5y agoAt least PipeWire is a thing now.
- sennight 5y agoI guess you've never had a reason to check what processes are doing what on your systems. I've never been comfortable with the mess you get upon opening something like top on a systemd managed OS. It isn't just the aesthetics of it... it is difficult to reason through the pages of tasks and it creates a lot of low level performance noise (preemption, task switching overhead, etc). For example, one of my Void flavored machines is using runit: 11 tasks; but a freshly booted headless Debian using systemd: 95 tasks... and that is with a massively slimmed down, purpose built, kernel. Abstractions atop abstraction... the amount of waste in the pursuit of generality has to stop - if this silicon shortage doesn't do it nothing will.