Well what it is is that obarun has systemd and systemd-libs blocked in /etc/pacman.conf (ignorepkg)
what arch developers do is they add systemd dependencies to almost everything they can
but when i edit some specific pkgbuild and remove systemd as dependency, i am able to build this application fine and it runs good without cancer!!!!!
And it is annoying, cuz if you want use these programs on arch based distro without systemd, you can't!!! you have to waste your time to remove those nasty dependencies.
Other distros have dummy pseudo-systemd-libraries and elogind but obarun doesn't so packages are 'cleaner'
few days ago i tried to install qemu on obarun, and guess what brltty (qemu dependency) requries systemd to function!! cuz arch linux devs think they do!!! they put this cancer to dependency, what for??
So because i use obarun i downloaded brltty from aur, removed systemd from dependencies from PKGBUILD and guess what, i have managed to build and use qemu without systemd!!!
so why do arch developers add systemd dependencies all the time to packages if it's supposed to be just an init system??? And those packages run fine without systemd?? What's the fucking point??
So from my point of view systemd is cancer because it's useless creation of some twisted minds and just makes my life harder.
There is no init freedom too!!!
You are forced to use systemd arch linux or you get banned!!! You're not supposed to ask questions!!!
1. The binary log is more corruption prone and such corruption has been observed in the wild. It's in the wrong direction. Logs should be simple text files and if complex enough queries are warranted then there should be a copy in a competent database. There is no need to implement a database, we have enough of them.
2. No software is bug free but now one huge piece of software is such that bugs in it crash the entire system. Only the kernel should be so.
3. Speaking of code base size, the more code you run as pid1 the more security holes you have.
4. Throwing out decades of knowledge and replacing it shouldn't be taken lightly and should be accompanied by world class documentation. No such thing.
5. Abusing dbus for IPC is not the best of technical decisions, no wonder they wanted kdbus which of course went nowhere.
6. Speaking of, a lot of things went somewhere because Poettering is basically a bully. kdbus went nowhere because bullying Torvalds is impossible. But really, these sorts of questions shouldn't be decided on who is more insufferable. These guys wouldn't survive contact with a code of conduct and that's not a good thing. (If you remember, Torvalds temporarily didn't.)
While I agree with all of your points, I don't necessarily understand why reverting away from systemd would fix this.
Because, you know, hundreds of user-maintained shitty shell scripts for init.d are the opposite of what you're aiming to achieve, too.
Apache binds sigwinch signals to shutdown for a reason, and those were not good reasons to begin with.
A more sophisticated alternative daemon would need to improve on the signals concept in the kernel beforehand, which certainly has to change; as kernel signalling currently is not even remotely made for such a use case (of a system daemon).
...so I kind of understand poettering's harsh statements, and why linus and him don't get along so well due to both of 'em having very opinionated and probably opposite views.
I think in order to improve at least some of your points, maybe some systemd modules and integration APIs would be the best way to go? Like an sqlite enabled systemd or something? Do you know whether such an initiative already exists?
> Because, you know, hundreds of user-maintained shitty shell scripts for init.d are the opposite of what you're aiming to achieve, too.
false choice - witness rc.d-style init & having a sane shell library / helper programs to handle common start/stop idioms,
as is also apparently provided here.
The binary log can be disabled if you don't want to use it. I personally dislike simple text logs and find them frustrating to use and would rather not go back to them, and using a traditional database engine is overkill here. (An on-disk log database only needs to support create and read operations)
Regarding security and code base size, it's not clear to me that any other architecture here is going to be less error prone. The problem seems to be that a large number of operations that you probably want your service manager to do on Linux require root or CAP_SYS_ADMIN. It doesn't really seem to matter if you put that stuff outside of pid1, a program that needs the same elevated privileges can still stomp on your system and mess with the state of pid1.
I've found systemd has extensive documentation (at https://systemd.io/) and the developers on the IRC and mailing list usually seem to be responsive.
I searched and I could not find any examples of this "bullying" on LKML. It looks like Greg was the person who was sponsoring it and trying to get it merged, not Lennart. And I'm not sure I would call their use of dbus to be abuse. I honestly think it would be cool if other low level daemons used dbus in this way because it makes integration (GUIs, automation, remote control, security policies, etc) a lot easier, as long as you familiarize yourself with the tooling around dbus.
All that said, systemd is made for a general use case and is not ideal for containers or for embedded. I hope these other init systems can find their niche.
Non-systemd systems seem very "hacker" to me. Bonus points for going against the grain and doing a project fewer people care about for the purpose of fulfilling esoteric software philosophies.
The vast majority of unix/linux "media" are sponsored by a handful of industries that all "sell" systemd based distros. Who makes a living writing for a linux media outfit who will turn against the interests of those who pay his salary?
How do you know there is a choice for people if you don't know the amount of bias there is in media what to project as "mainstream" and "popular". When Distrowatch a little while ago, run a poll, about init systems, systemd DID NOT come 1st, and its 3-4 top adversaries got 60% of the votes. Based on this I'd say systemd is a little second class adversary that can only get newbs fooled to use it because that is what mass media tells them they should try.
Ubuntu, Mint, Manjaro, Debian, Fedora. This is what media is pushing down peoples' throats.
Could someone explain it to me? I'm really out of the loop. I replaced Windows with Ubuntu a month ago with the intent to learn Linux. So far I have learned nothing: it's too stable and usable. Clearly something is being done correctly, and I did briefly have a stint with the older boot/service stuff in high school (which was impossible).
Some people don't like systemd because it rolls a bunch of other functionality beyond 'just init' into a giant monolithic beast. The advantage is that distro maintainers are able to present an extremely usable and stable system like Ubuntu, Arch or any of the other mainstream distros. For most people that just want to use their computer to do regular stuff like browse the internet and edit photos and stuff, systemd or otherwise doesn't really matter because you pretty much never need to touch those parts of the system. Alternate init systems are for power users or people with particular constraints. For example, one of the reasons Alpine Linux is able to be so small is because it uses OpenRC instead of systemd.
Personally, I use a non-systemd distro because my computers all have tiny-sized HDDs by today's standards and I hate having to read a bunch of documentation every time I want to create a new system service. To me, it's easier to just write an ordinary shell script. I don't need all the ridiculous logging capabilities that systemd offers. Regular old plain text is enough for me.
I prefer system d because I also have a cloud VM where I use systemd to run a database and an account service online for the games I make. I found systemd to be pretty darn nice for that. basically a better supervisor and far less bulky than using Docker.
That being said, I almost never use (or even think about) systemd on my Linux Mint install.
>"...So far I have learned nothing: it's too stable and usable...."
About 20 years ago I was developing new product (commercial media system) and tried to use Linux. After managing to crash system and my application like few times a day I showed it a middle finger and did it in Windows. Was not worth saving on licensing fee.
I came back to Linux about 3 years ago for writing native servers in C++. The difference in experience is night and day. The system is stable to the point that I do not even notice it. Everything I need works like a charm.
I feel like the only thing holding back the year of the Linux desktop is now apps (more Blender-quality stuff is needed) and people actually taking notice of Linux.
If I want to make my own Linux-based OS, where do I start learning/practicing?
I already know how to install and use Arch, should I read and build Linux From Scratch or should I concentrate on understanding the kernel and the low level libs first?
All of these init systems, including systemd, upstart and Windows Service Manager, pretend they can properly deal with failure, but they don't do it well or predictably.
If you have a service other services depend on, and then it goes down - you obviously need to restart the service that went down, but you may or may not need to restart the dependents, they may or may not have intermittent failures that are going to trigger other things -- It's just a huge mess.
Almost all systems work almost all of the times but when they don't, it is incredibly hard to reason what will happen because of the interaction between services and init system. The problem is inherent and I don't think a general service manager can fix it.
Even on systems that use systemd, I install djb's daemontools, and run my services under it; It only tries to do the things that can be reasoned about - services are indepedent; if you want to orchestrate dependencies, you need to do so in a way that makes sense for your own services because there is no general solution. It is incredibly simple, yet as robust as all the shiny systems (and perhaps more so).
s6 (on which Obarun is based, if you go deep enough) started life as a daemontools clone, but it added enough complexity to lose the robustness, predictability and simplicity of djb's design.
Arch Linux developers add systemd dependency to lot of packages, but reality is that for somebody like me who is obaruner, i have to edit PKGBUILD's and remove unneccessary systemd package and i manage to build and run them without without systemd
This is why systemd is cancer, it forces arch devs to add unneccessary systemd deps and that makes life pain in the ass for somebody who uses non-systemd arch linux based distro.
Others use dummy libsystemd, or dummy systemd but is it real solution, obarun doesnt provide dummies, so pkg codes are 'cleaner'
Try to build some package that requiries systemd, remove it from dependencies and do it, you'll see lot of programs run fine without systemd!!! So why the hell arch linuxers add systemd dependency to almost everything they can??
Well i am obarun user but beginner so i can't give lots of insights.
I know that artix uses systemd and systemd-libs dummy packages, because most of pkgs from arch have systemd in dependencies, which is completely useless...
obarun doesnt provide these. You can grab a pkgbuild and remove systemd dependency and other stuff.
Your best bet is to go on obarun forums and ask yourself
also obarun provides it's own 66 suite
https://web.obarun.org/software/
This init system obarun provides is bloody fast, you can configure your trees to suit your needs and your system will take 5 seconds to boot.
Artix is a bit like ubuntu of non-systemd arch linux.
This is obarun announcement that was removed from /linux reddit because it critises systemd
https://sysdfree.files.wordpress.com/2020/11/linux-removes-o...
That announcement doesn't even mention systemd. It was probably removed because of its bombastic, grandiose claims - "most advanced init system", "make every other system appear obsolete", "more effective than ever before or with any other system" etc.
Yeah because systemd is the best because debian and other major distros adopted it so everyone has to use it now. Im pretty sure that youre allowed to say that systemd is the best though
Obarun is a real breath of fresh air. By the time the image downloaded I had read some of the documentation about 66, I am a little familiar with s6 and its advantages (I don't think any other system makes better use of the kernel than s6) and I was happy to see a simple way to make s6 work.
This is really what makes s6 hard and less known, it is missing what 66 provides to average user.
I haven't used systemd for more than a few times testing distros, and the difference on machines that are older is HUGE. Anything with systemd on old machinery is like a messed up windows installation dragging its feet to do any little thing. I can't understand how can so many people defend it WHEN THEY HAVEN'T TRIED ANYTHING ELSE. It is obvious they haven't.
I use void and runit and I run a very simple system, so s6/66 is a ton of luxury, and between a minimalist runit system and an s6 system there is little performance difference. But after seeing Obarun I am ready to try 66 on Void.
32 comments
[ 4.5 ms ] story [ 84.2 ms ] threadCan you expand on this claim?
few days ago i tried to install qemu on obarun, and guess what brltty (qemu dependency) requries systemd to function!! cuz arch linux devs think they do!!! they put this cancer to dependency, what for?? So because i use obarun i downloaded brltty from aur, removed systemd from dependencies from PKGBUILD and guess what, i have managed to build and use qemu without systemd!!! so why do arch developers add systemd dependencies all the time to packages if it's supposed to be just an init system??? And those packages run fine without systemd?? What's the fucking point??
2. No software is bug free but now one huge piece of software is such that bugs in it crash the entire system. Only the kernel should be so.
3. Speaking of code base size, the more code you run as pid1 the more security holes you have.
4. Throwing out decades of knowledge and replacing it shouldn't be taken lightly and should be accompanied by world class documentation. No such thing.
5. Abusing dbus for IPC is not the best of technical decisions, no wonder they wanted kdbus which of course went nowhere.
6. Speaking of, a lot of things went somewhere because Poettering is basically a bully. kdbus went nowhere because bullying Torvalds is impossible. But really, these sorts of questions shouldn't be decided on who is more insufferable. These guys wouldn't survive contact with a code of conduct and that's not a good thing. (If you remember, Torvalds temporarily didn't.)
Because, you know, hundreds of user-maintained shitty shell scripts for init.d are the opposite of what you're aiming to achieve, too.
Apache binds sigwinch signals to shutdown for a reason, and those were not good reasons to begin with.
A more sophisticated alternative daemon would need to improve on the signals concept in the kernel beforehand, which certainly has to change; as kernel signalling currently is not even remotely made for such a use case (of a system daemon).
...so I kind of understand poettering's harsh statements, and why linus and him don't get along so well due to both of 'em having very opinionated and probably opposite views.
I think in order to improve at least some of your points, maybe some systemd modules and integration APIs would be the best way to go? Like an sqlite enabled systemd or something? Do you know whether such an initiative already exists?
false choice - witness rc.d-style init & having a sane shell library / helper programs to handle common start/stop idioms, as is also apparently provided here.
The binary log can be disabled if you don't want to use it. I personally dislike simple text logs and find them frustrating to use and would rather not go back to them, and using a traditional database engine is overkill here. (An on-disk log database only needs to support create and read operations)
Regarding security and code base size, it's not clear to me that any other architecture here is going to be less error prone. The problem seems to be that a large number of operations that you probably want your service manager to do on Linux require root or CAP_SYS_ADMIN. It doesn't really seem to matter if you put that stuff outside of pid1, a program that needs the same elevated privileges can still stomp on your system and mess with the state of pid1.
I've found systemd has extensive documentation (at https://systemd.io/) and the developers on the IRC and mailing list usually seem to be responsive.
I searched and I could not find any examples of this "bullying" on LKML. It looks like Greg was the person who was sponsoring it and trying to get it merged, not Lennart. And I'm not sure I would call their use of dbus to be abuse. I honestly think it would be cool if other low level daemons used dbus in this way because it makes integration (GUIs, automation, remote control, security policies, etc) a lot easier, as long as you familiarize yourself with the tooling around dbus.
All that said, systemd is made for a general use case and is not ideal for containers or for embedded. I hope these other init systems can find their niche.
The vast majority of unix/linux "media" are sponsored by a handful of industries that all "sell" systemd based distros. Who makes a living writing for a linux media outfit who will turn against the interests of those who pay his salary?
How do you know there is a choice for people if you don't know the amount of bias there is in media what to project as "mainstream" and "popular". When Distrowatch a little while ago, run a poll, about init systems, systemd DID NOT come 1st, and its 3-4 top adversaries got 60% of the votes. Based on this I'd say systemd is a little second class adversary that can only get newbs fooled to use it because that is what mass media tells them they should try.
Ubuntu, Mint, Manjaro, Debian, Fedora. This is what media is pushing down peoples' throats.
Personally, I use a non-systemd distro because my computers all have tiny-sized HDDs by today's standards and I hate having to read a bunch of documentation every time I want to create a new system service. To me, it's easier to just write an ordinary shell script. I don't need all the ridiculous logging capabilities that systemd offers. Regular old plain text is enough for me.
That being said, I almost never use (or even think about) systemd on my Linux Mint install.
About 20 years ago I was developing new product (commercial media system) and tried to use Linux. After managing to crash system and my application like few times a day I showed it a middle finger and did it in Windows. Was not worth saving on licensing fee.
I came back to Linux about 3 years ago for writing native servers in C++. The difference in experience is night and day. The system is stable to the point that I do not even notice it. Everything I need works like a charm.
I already know how to install and use Arch, should I read and build Linux From Scratch or should I concentrate on understanding the kernel and the low level libs first?
Why not start with Arch or Obarun. Very few other distros allow so much hacking and choice as arch (and arch-based).
To start an independent and autonomous distro you need to build a few thousand packages first. The wealth of Arch+AUR is nearly unbeatable.
LFS is good exercise but that is about it. Reinventing the wheel is not very sensible.
If you have a service other services depend on, and then it goes down - you obviously need to restart the service that went down, but you may or may not need to restart the dependents, they may or may not have intermittent failures that are going to trigger other things -- It's just a huge mess.
Almost all systems work almost all of the times but when they don't, it is incredibly hard to reason what will happen because of the interaction between services and init system. The problem is inherent and I don't think a general service manager can fix it.
Even on systems that use systemd, I install djb's daemontools, and run my services under it; It only tries to do the things that can be reasoned about - services are indepedent; if you want to orchestrate dependencies, you need to do so in a way that makes sense for your own services because there is no general solution. It is incredibly simple, yet as robust as all the shiny systems (and perhaps more so).
s6 (on which Obarun is based, if you go deep enough) started life as a daemontools clone, but it added enough complexity to lose the robustness, predictability and simplicity of djb's design.
I can see it layers over s6 with 66 for service management.
This init system obarun provides is bloody fast, you can configure your trees to suit your needs and your system will take 5 seconds to boot. Artix is a bit like ubuntu of non-systemd arch linux. This is obarun announcement that was removed from /linux reddit because it critises systemd https://sysdfree.files.wordpress.com/2020/11/linux-removes-o...
Coincidence?
Obarun is a real breath of fresh air. By the time the image downloaded I had read some of the documentation about 66, I am a little familiar with s6 and its advantages (I don't think any other system makes better use of the kernel than s6) and I was happy to see a simple way to make s6 work.
This is really what makes s6 hard and less known, it is missing what 66 provides to average user.
I haven't used systemd for more than a few times testing distros, and the difference on machines that are older is HUGE. Anything with systemd on old machinery is like a messed up windows installation dragging its feet to do any little thing. I can't understand how can so many people defend it WHEN THEY HAVEN'T TRIED ANYTHING ELSE. It is obvious they haven't.
I use void and runit and I run a very simple system, so s6/66 is a ton of luxury, and between a minimalist runit system and an s6 system there is little performance difference. But after seeing Obarun I am ready to try 66 on Void.