5 minutes of fame when Debian said “if you want other init systems, maintain them”, soon-to-be-Devan folks slammed the door and effectively ruined the chance of multi-init debian by fracturing efforts into their fork instead. But hey, all the news were abuzz about them.
I don’t know anything about Devuan, but the init system is replaced, not removed. You need an init system. Devuan probably has something more barebone than systemd.
Comparing myself to the ultra rich doesn’t affect me any more than comparing myself to super athletes. It’s the people around me that matters and they’re not significantly more wealthy than me. You’ll never be content in your life if this is the bar to reach.
Except pro athletes don’t earn more than the rest of the world combined. Pro athletes don’t control the prices of everything you’ve ever bought or rented. Pro athletes don’t supply the politicians with enough legal bribes in a corrupt system that they’re effectively in charge of the country.
If you don’t think billionaires sucking up all the resources and political power matters to your daily life, you’re either delusional or wilfully blind.
I wasn’t talking about the wealth of pro athletes but their athletic capabilities. Your workouts will be miserable for the rest of your life if those are the people you’re comparing yourself to.
The point is that the astronomical levels of income and wealth of centimillionaires and billionaires aren’t possible without ruining society in thousands of ways that DO affect YOU directly and profoundly whether or not you’re actively comparing yourself to anyone.
I think that the comparison is a bit flawed in the way that comparing pretty much any of us to one of the super-rich is more akin to comparing a patient in a state of clinical death to the Warhammer 40k™ top-tier warriors, not just pro athletes
If I were to dedicate all my life to sports I would maybe make it into the pro level during the lifespan, even if that would mean that I’d have to choose some sport that allows old people 🌚
I I were to continue working the way I work today and get a hundred times raise in payment, it would take me about 60 thousands of years to get what Jeff has and that is if I don’t eat or rent a flat anymore.
That’s quite a bit of difference, don’t you think?
Other people’s health is not a zero-sum game. There is an increasing wealth gap wherein the resources and value of humanities labour are being increasingly concentrated in the hands of a tiny minority to the detriment of everyone else.
It’s like being at a party where just before the food is served some unhinged lunatic runs in and manages to somehow fit all the food for the entire party into their underwear and run off with it.
People saying “hey, maybe we shouldn’t invite that person to parties anymore” and you reacting like “well, I don’t compare how much food I have with people who have stolen all the food. All that matters is that you’re all just as hungry as I am. You’ll never feel full if you compare yourself to someone who stole all of the food!” is very difficult to respond to in a way that is compatible with the way the Beehaw community works…
As a Discord user, I am sad if this person took the username of the real spez, it means spez cannot use his username anymore :( no one would ever do that, it must therefore be the real one
Systemd is huge. It’s a complex project that covers not just the init system, but also process management, networking, mounts, sessions, many other things. Many people think its monolithic design run counter with the Unix philosophy and wish to use distros without systemd.
Just to avoid misunderstandings: it's not a monotolithic blob, it is thought so because its first project was a system daemon that manages system services. It is described as "a software suite that provides an array of system components for Linux operating systems.", it is highly modular and offer many optional components that each have their own purpose.
I recommend visiting Gapminder. For example the Dollar Street, where you can get an inside how different life around the world is, depending on income.
Also, it’s various other statistical tools like this animated graph, where you can see the billionaires running away to the right. Also interesting is the short blip of people having more wealth at around 1980 - 2010, which immediately got sucked back into “slightly right of extreme poverty mountain”.
I truly applaud your mental fortitude. I honestly had to stop scrolling through your info graphic after passing the malaria part. I simply couldn’t take it all in at once. I will come back to it tomorrow and take in another chunk of it, I’ll see how far I get then but I intend to take it all in albeit in bite sized chunks.
Keep it up and I’ll be looking for more of your projects later if I can handle it. The world is truly broken but I’m a firm believer that eventually we the common people will open our eyes to it and enact change. I don’t know how and I wish I knew how to contribute to that in some way even though I don’t believe I have the power within the current system.
It’s mostly opinionated. systemd is written in C, uses a consistent config, is documented well, has a lot of good developers behind it, is very fast and light, and does what it’s doing very well. Since systemd also is split up into multiple parts, it still follows the “do one thing, do it right” philosophy.
There are some people that believe that systemd “took over” the init systems and configuration demons of their distro, and does “too much.” It really does quite a lot: it can replace GRUB (by choice), handle networking config, all the init stuff of course, and much more.
However, I have lived through the fragmented and one-off scripts that glued distros together. Some distros used completely custom scripts for init and networking, so you had to learn “the distro” instead of “learn Linux.” They were often slower, had worse error handling, had their own bugs, were written in various scripting languages like tcl, Perl, Bash, POSIX shell, etc. It was a mess.
The somewhat common agreed-upon init system was System V, which is ancient. It used runlevels, nested configuration (remember /etc/rc.d?), and generally, it was mostly used because it was battle tested and did the job. However, it is arguably esoteric by modern standards, and the init philosophy was revised to more modern needs with systemd.
You can probably tell my bias, here. If you have to ask, then you probably don’t have a “stance” on systemd, and in my opinion, I would stick with systemd. There were dozens of custom scripts running everywhere and constantly changing, and systemd is such an excellent purpose-built replacement. There’s a reason why a lot of distros switched to it!
If you want to experience what other init systems were like, I encourage you to experiment with distros like the one you mentioned. You might even play with virtual machines of old Linux versions to see how we did things a while back. Of course, you probably wouldn’t want to run an old version of Linux for daily use.
It should also be mentioned that init systems are fairly integral to distros. For example, if you install Apache httpd, you might get a few systemd .service files. Most distros won’t include init files for various init systems. You can write them yourself, but that’s quite a lot of work, and lots of packages need specific options when starting them as a service. For this reason, if you decide you want to use a different init system, a distro like the one you mentioned would be the best route.
Some distros used completely custom scripts for init and networking, so you had to learn “the distro” instead of “learn Linux.”
I never really noticed init scripts differing much between distros, but I also didn’t play around with many. If the systemD scripts are the same across every system, then this is the first positive thing that I’ve heard about systemD, so thanks for that.
Init scripts were different, I can confirm. And it was pretty bad if you were doing your job and had to change something on a Debian massive machine, then moved to a red hat one.
Ah ok, most of my experience has been on debian or derivations in the past decade. It seems weird that the init scripts would need to be different on various systems, I thought they had been pretty well standardized, with variables in the /etc/default/ entries pointing to specific folders or startup options. Ah well.
Great answer. I do use systemd boot on one of my systems as well. It isn’t exactly systemd itself is it? Simply a boot loader packaged as part of the general systemd boot suite, right?
Yeah exactly. It does have some features that require integration with the init system, which systemd obviously supports, but it could be used independently of systemd quite happily, and other init systems could easily support those integrations.
Systemd-the-init does depend on some core services and thise need to be used together: Init, logging and IPC. Anything running systemd-init will have journald for logging and IIRC DBus for communication. That’s because you need to control a system managing services, so you need to communicate with it and you need to document whatbthe managed services do, so you need logging. And you do want tested and stable code here (reusing something that was widely used in Linux before systemd started) and you do not want that code in the init process either. So systemd-the-init has very simple code tomlog and journald then has thencode needed to stream logs out to disk or to interact with other logging systems.
Everything else is optional and in separate binaries written in a layered architecuture: Each layer uses services provided by the lower layer and offers services to layers higher up in the stack. So lots of services depend on systemd-the-init to start other processes instead of reimplementing that over and over again (thus gaining unified config files for everything that gets started and all the bells and whistles systemd-the-init has already or will pick up later).
Or if you prefer a more negative spin: “Systemd is on huge entangled mess of interdependent binaries” :-)
Slackware uses the sysvinit program, but doesn’t have System V-style scripts. Which is somewhat confusing, but sysvinit is a basic init program that will just do whatever /etc/inittab tells it, so you can write your startup scripts to work however you want.
Slackware uses what people tend to call a BSD-style init, but it’s nothing like the modern BSDs, nor the older BSDs, not really. If you use Slackware, you’ll learn how Slackware’s init system works, but that’s about it.
Ah my mistake. I’m just generally curious about what distros use an alternative to systemd (not that I have any issues with systemd myself but I like variety).
So I googled what init system Slackware uses and read this page.
No, you’re right that it has scripts, they’re just not the scripts used by SysV-style init systems. They have different names, are in different locations, and are executed differently.
I used Slackware for several years back in the 90s, and from that experience I’d recommend against learning it. I mean, with VMs today it’s simple to try new distributions, so go for it, but I’d put it waaaaay down the list of distributions/operating systems to try. If you have anything else you’re interested, put it first. Slackware is standard Linux so there’s nothing really special you’d find when using it, and it’s just a painful experience in general. I think some people will argue that it helps you “really learn Linux”, but I don’t think so. It just helps you learn Slackware’s idiosyncrasies, and learning pretty much any other distribution would be more beneficial than that.
Slackware has advanced from when I used it in the 90s, but only barely (they have a network-based package manager now, I guess, although it proudly avoids dependency resolution!)
Oof that stance on dependency resolution is a big no for me. As much as I hated building gnome from source it was amazing that Gentoo can do that in a single command.
I am fan of principles like KISS and “Do one thing and do it right”. From this point of view is systemd disaster because it is almost everywhere in the system - boot, network, logs, dns, user/home management… It’s always surprise for me if nothing breaks when I do upgrades.
I understand why systemd is here but I’m not at all happy to use it.
From this point of view is systemd disaster because it is almost everywhere in the system - boot, network, logs, dns, user/home management…
That’s almost like complaining that GNU coreutils is a disaster from KISS point of view because it includes too many things in a single project - cat, grep, dd, chown, touch, sync, base64, date, env… Not quite, because coreutils is actually a single package unlike systemd.
The core systemd is big (IMHO it needs to be in order to provide good service management, and service management is a reasonable thing to include in systemd), but everything you listed are optional components. If your distro bundles them into one package, that’s on them.
Systemd includes many complex things, coreutils includes many simple things. And coreutils are ported to many different OS’es, systemd is linux only. Ask why?
Lets imagine, my linux distro runs with openrc/upstart and I like systemd-journal features. Am I able to run system-journal without any other systemd components running?
It is well known that systemd’s service management is built around cgroups, which is a Linux-only concept for now. Other OSs have their own ways to accomplish similar things, but adapting to that would require huge changes in systemd.
Am I able to run system-journal without any other systemd components running?
No, the only part of systemd project that doesn’t depend on systemd core is systemd-boot. And there’s also elogind, which is an independent project to lift systemd-logind out of systemd.
But honestly, I don’t see the issue here. You can’t use systemd’s components elsewhere, but your previous complaint was the opposite - that systemd is everywhere, as if you were forced to use networkd, resolved (which pretty much no distro uses AFAIK because it’s way worse than other DNS resolvers), homed, timedated etc. when you use systemd as init.
Also, I have a correction for my previous comment: systemd-journald is not an optional dependency, as it’s used as a fallback if the configured log daemon fails. I’ve only learned after writing that comment.
It may speed up your boot time, at least it happened to me on Void (maybe the reason is how minimal this distro is though). I personally prefer runit over systemd in how it handles services, but honestly you most probably won’t notice a much difference - definetely not worth reinstalling whole system.
First off, systemd-the-repo does contain way more than an init system. But yes, I am pretty sure systemd-the-init is slightly bigger than runit.
Secondly: Systemd-init does set up some useful linux kernel features for the processes it manages in an easy and consistent way. That’s why other services started to depend on systemd-the-init by the way: Systemd does linux-specific things developers find so useful that they prefer adding a dependency on systemd over not having the functionality.
Runit does not support any linux kernel specific features at all to stay portable to other unixes. Other alternative inits made the same design choice.
Thirdly: The overall attack surface of the system without systemd is bigger than a typical systemd system. That’s because so much code run by the init system is way more locked down as systemd provides easy ways to lock down services in a cross-distribution way. Note that the lockdown functionality is 100% linux kernel features, so it involves little code in the init itself. Users of other inits can of course add the same lockdown features as service-specific startup code into the init scripts. We saw how well that works across distributions with sysv-init…
Finally lots of security features implemented outside systemd-the-init require a systemd system as they need the lockdown features offered by the systemd-init. One example is systemd-logind: That depends on systemd-init to be secure where the pre-systemd attempts all failed to archive that goal. Logind makes sure only the user sitting at a screen/keyboard can actually interact with the device interfaces of the kernel device files managing that hardware, so no other user but you can see ehat you type and take screenshots of your screen. Contrast that to devuans approach: Add all users allowed to start the UI to a group and make the devices controllable by that group. Much simpler, KISS and the Unix way… but it also allowes all users on the system that ssh into the machine somebody sits on can log what other users can type. Apparently that is not a problem, since no system ever will have more than one user in the age of personal laptops and desktops. That seriously isvtheir answer… and they even rejected to maintain the ubuntu-before-systemd logind replacement when canonical asked them, because such functionality is not needed im Devuan.
Runit is brilliantly simple, and as the old granite maul examine text says, “simplicity is the best weapon”.
I’m sorry, you won’t be able to convince me to use it, it doesn’t feel KISS (I left Arch when they swapped). Fuck binary logs too. The only place I use it is on my phone which is SailfishOS.
Void to me is what Arch used to be – I tend to use minimal replacements where I can, e.g. Openntpd as ntp, socklog as logger, seatd as logind, zfsbootmenu instead of systemd-boot, no polkit et cetera.
it’s the closest usable distro for me to cut most of the poetteringware out apart from messing around with Gentoo (which I can’t be arsed with any more). I am not a fan.
Like or dislike systemd, be it convenient or not, you can’t deny it’s a behemoth.
I am not trying to convince you: Use whatever you want.I am trying to explain it, so that people can have a more informed discussion. The web is full of either systemd is the best since sliced bread and systems is horrible. It is neither: It is just a technical system that made technical choices that make certain things easier or even possible and others harder or even impossible.
The sytemd time thingy is actually more minimal than openntpd: It only supports sNTP and not the full NTP protocol and is a client only… Openntpd is a full NTP implementation with both client and server. It also is a great technical choice, so keep using it, especially when you need an NTP daemon.
You behemoth is my plumbing layer:-)
I like the ton of small and simple tools that systems brings along: systemd-nspawn is a really lightweight way to run containers that works basically everywhere, no need to install docker or podman. Disk resizing, sysusers, tmpfiles, boot, Key Management, homed, etc. enables me to build reliable, immutable images for my systems. There is no tooling whatsoever for this outside the systems umbrella.
If you do not try to build a 1980-style UNIX system, then you basically are stuck with systemd. Nobody else is even thinking about how to move forward. If you try to raise the challenges you see outside systemd, you get laughed at and are told that your usecase is obviously stupid. The limitations admins ran into 1980 are gospel now and you may not question any of that.
Fair play, as you say it is a “love it or hate it” affair. I personally really like the simplicity and stability of old school UNIX.
OpenBSD comes to mind as the closest thing in contemporary times and I would use it as a daily driver but I need Linux for a few bits.
Void to me seems like the Linux equivalent. Minimal, stable, no bullshit. Alpine also fits this criteria but is a bit more sparse in some packages that I use. Both great distros.
Systemd is 1.5+ million lines of code! However convenient, it felt forced by Redhat into the Linux world and many of us who do not like it feel bent over backwards to be fucked in the arse by Poettering et al.
As solely an init system, may I suggest a superior alternative, s6?
(I am in hospital on morphine so I may not be making sense).
Text logs are binary, too… they just uses a pretty common binary encoding.
Where do you actually use text logs? I did not use text logs outside of hobby machines ever during my career. Logs were either aggregated in databases or at least stored in temper-resistant formats (usually due to legal requirements).
Do you actually use text logs in a professional setting? Just curious.
With textlogs you have a hard time noticing a couple of added/removed/changed characters or even entire log entries. Thats exactly why some industries may not use text logs in the first place as permanent records that are at least temper-evident are mandated.
If binary logs go kaputt they tell you exactly which entries were effected and still display every bit of data they contain. Typically you do not grep in binary logs: Grep can not make sense of all the extra data in the logs (way more than in a typical syslog), so grep is just a poor tool for the job. You typically can use grep as binary logs so contain lots of text. This is ignoring compression, encryption and other extras of course.
lemmy.ml
Newest