The actual init system of systemd, located at, or linked to, /bin/systemd is 1,1 MB (Debian Stretch).
According to the wikipedia page on OpenRC it's size is 900KB.
Please note that the systemd project also develops system management tools, which are not the same as, and not dependencies of, the init system.
So turns out that all those neet spergs memeing online about systemd were just that. Neet spergs online.
Other urls found in this thread:
packages.debian.org
github.com
twitter.com
lol
Maybe that's the source size.
The whole installed size is around 300kb
packages.debian.org
And the actual init size is a fraction of that.
Btw good ole sysvinit is around 40kb.
It's 60 lines of simple shell script in Slackware, half of that are comments and help messages.
Technically Slackware uses BSD-style init scripts not SysV style init scripts. But it does use the same SysV init for PID1.
>The whole installed size is around 300kb
Yes, this is correct. I will change the OP text in my next shitposting session.
>And the actual init size is a fraction of that.
OpenRC is a init. It needs all those other things to work.
>Btw good ole sysvinit is around 40kb.
Yes but it doesn't have dependency resolution or parallelism, it's not on the same "category" as those other two.
The reason people hate SystemD is because it's incorporating a ton of unnecessary libraries that should have remained standalone.
I believe the key offenders are:
logind/consolekit
udev
cryptsetup
resolved
journald was also a disastrous idea and I've had it waste an incredible amount of hard drive space.
>not including the contents of /etc/default/ssh
The OpenRC version is a lot more minimal than the init script version, and it's mostly bash commands, so you don't need to have an in-depth knowledge of the init system to understand the unit.
>OpenRC is a init. It needs all those other things to work.
It doesn't need man pages to work.
And you don't count the other things systemd needs to work, only the PID 1 binary - so that's not a fair comparison.
>Yes but it doesn't have dependency resolution or parallelism
Those are features of a daemon manager, not an init.
>parallelism
How much time does parallelism save you when you boot? Devuan seemed to boot in 10 seconds after I'd typed my decryption password. Gentoo is pretty similar (I don't have openrc parallelism enabled).
How often do you boot anyway? I usually only reboot when there's a kernel update or my system kernel panics.
>>Those are features of a daemon manager, not an init.
Distinction without a difference. Daemon management is a subset of the things an init system is expected to do.
>only the PID 1 binary
The init is in a self contained binary. Systemd developers want it just werks no matter what.
Also: Parallelism is not very relevant for desktop systems. How quickly a life support or production line control systems can reboot is very relevant.
No, it's not.
I can easily run a daemon manager outside the init.
See for example djb's daemontools or runit.
In fact it's preferable to keep it as simple as possible, given how critical PID1 is.
It's also more flexible. I don't need to bog down my small specialized embedded system with a daemon manager, I don't need.
>The init is in a self contained binary. Systemd developers want it just werks no matter what.
Lennart himself likes to say how 'modular' systemd is. And how many binaries it requires.
>>In fact it's preferable to keep it as simple as possible, given how critical PID1 is.
it's telling that I never once heard anyone make this argument until systemd came along.
Because PID1 was always some small tiny binary that did almost nothing?
And no one was stupid enough to replace it with a huge monster of a process before systemd?
>Lennart himself likes to say how 'modular' systemd is. And how many binaries it requires.
Systemd is a init and system and service management framework. The pieces of the framework are independent of each other but the init is self contained, as are some other parts. That's the argument for having hardcoded fallback dns servers for resolved.
Wrong. No onse used this argument against OpenRC and Upstart and they both are much bigger than sysvinit.
13 lines in OpenBSD, including 3 lines of comments and 4 empty ones
>How quickly a life support system can reboot is very relevant
If you were making some kind of hard real time embedded system, you probably wouldn't be using something like OpenRC or SystemD. You'd need an init system that has real time guarantees. I suspect that most real time systems would just create something custom in C/Ada/etc.
>How quickly production line control systems can reboot is very relevant
I've never looked into the software architecture of these kinds of things. Do these kinds of systems need real time guarantees? Are they often done in Linux?
1.1 MB of pure, unadulterated bloat.
yes but unironically
>systemd=good friendly girl code
>openbsd=evil hacker code that will steal your nudes
>3 lines of comments
#!/bin/ksh isn't a comment, it's a file header.
>PuTTY
>Wangblows user detected
why are you on Jow Forums?
You can make the same case for OpenRC.
I doubt it needs ll the files for init scripts for the actual init.
I never really used them so I don't know the details.
But I do remember people saying that upstart sucks.
And no one except for Ubuntu ever used it, which is not known for making good decisions.
>OpenRC and Upstart and they both are much bigger than sysvinit.
That's wrong though. I haven't bothered look at Upstart but this thread clearly shows OpenRC is much smaller.
It's completely irrelevant because you would generally have a redundant setup and do load-balancing.
Some of those systems even use windows. Not even memeing. Remember stuxnet?
Damn, you really got me user.
>how modular systemd is
>how many binaries it requires
It's like calling KDE modular
>You can make the same case for OpenRC.
>I doubt it needs ll the files for init scripts for the actual init.
I would think otherwise. Systemd is more than just a init system, so you have to find the init part and measure it's size. OpenRC is just a init system.
>That's wrong though. I haven't bothered look at Upstart but this thread clearly shows OpenRC is much smaller.
I said they are bigger than sysVinit. You probably misread it.
>windows
They deserved stuxnet
It's not just that it's Windows. It's a proprietary operating system produced by one of the biggest companies of your arch enemy country. The same country you are trying to scare with the nukes you were building with those windows systems.
It's just beyond stupid.
Ah sorry, I noticed I misread that last part.
But if you compare the sizes, then you see that systemd is quite a dramatic increase and three times the size than even upstart.
sysvinit: 40kb (total: 276kb)
openrc: 123kb, (total: 340kb)
upstart: 270kb, (total 1.8mb)
systemd: 1.1mb (total 11.4mb)
Sysvinit-core+OpenRC or GNU/Shepherd is the only two viable options.
The correct table would be:
sysvinit: 40kb
openrc: total: 340kb
upstart: 1.8mb
systemd: 1.1mb
OpenRC and Upstart need all of those other stuff to work (man pages are tiny, let's ignore them). Systemd's init doesn't need those other 10mb to work. Those are for system management. Things like logind and networkd.
OpenRC is still considerably smaller than systemd. But much bigger than sysVinit (8,5 times) and no one uses the bloat argument against it.
It's not the init that's the problem. The problem is that systemd comes with a ton of other crap I don't want like journald.
Also, no used the bloat argument against upstart, which is even bigger than systemd. People just said "canonical is gay" (true).
My point is. The init system of systemd is actually not a big change from OpenRC and Upstart. The problem is that there are many other things under the systemd name that are not related to the init system. So people get confused and think it's a 10mb init.
>this is correct because it makes systemd look slightly less horrible
>OpenRC and Upstart need all of those other stuff to work
citation needed
>But much bigger than sysVinit (8,5 times)
Now that's the most retarded thing. Why are you using the binary size of sysvinit but not of openrc?
The other files of both sysvinit and openrc are init script stuff. They have the exact same importance.
>People just said "canonical is gay" (true)
Because that was enough.
No one ever tried to force upstart on me, or even made me take an actual look at it.
>tfw journald filled up my root partition with "press Y to accept the license and N to declinepress Y to accept the license and N to decline" because i accidentaly double clicked the teamspeak installer without running it in cli
it was a hard thing to fix too, since the system was unresponsive and refused to boot, but thats what you get for being retarded
You're confusing the issue.
What matters is what runs in PID1.
An helper script that OpenRC launches, does not run in PID 1.
Just liberate yourself and install gentoo or some meme anti-systemd distro. I use runit now and it's so much nicer.
>Things like logind and networkd
When people complain about bloat, they're usually complaining about retarded unnecessary shit like logind.
meh i experience much less random issues with systemd than i used to with upstart (most of those were probably me being retarded anyway), and since i learned the basic management tools i will stick to it. Last time i installed gentoo i lost intrest while (and after) compiling xfce.
>citation needed
They are just init systems. Can we assume that the developers didn't include things not relevant to an init system?
>Now that's the most retarded thing. Why are you using the binary size of sysvinit but not of openrc?
I thought it was the total size of the init. That's the size that people used to argue against systemd's init in this thread. If sysV is bigger than that, than systemd's init can not be said to be as bloated as people are saying.
>Because that was enough.
That was not an argument common.
>No one ever tried to force upstart on me, or even made me take an actual look at it.
Upstart was in the path systemd took. Systemd only took over it because it had RH behind it.
Debian and OpenSUSE (the ones I remember) were already discussing the adoption of upstart.
Whichever things PID 1 depends on also matter. If one of those other things break PID also breaks. Doesn't matter if they are all in one file or many.
If OpenRC init file can tolerate faults in this other files so can systemd's init tolerate faults in non essential functions that happen to be in the same file.
>Whichever things PID 1 depends on also matter. If one of those other things break PID also breaks.
What? Openrc's init doesn't have any dependencies.
The other files that come in the OpenRC package that the init system needs to work properly. Such as service starters and stoppers. There is no difference if those things are in a separate file or in a separate function inside the PID 1 binary. If they break the init breaks.
I don't think that's actually right. I haven't tried it myself, but I think even if you go full retard and purposely break rc-update and some other helper commands, the init will still run.
The same can be said if they are all in a single file. Instead of a file not working it's a function.
Now, I don't know what you're talking about. Anyways, here's openrc's init and it just depends on some headers like anything in C.
github.com
Enjoy your network-manager by: RedHat
if he wants to liberate himself he shouldn't be blaming systemd, he should be blaming teamspeak. that's the software he should be ditching over this.
Good thing I don't use sysvinit.
systemd shills like to pretend that everyone else is on sysvinit and that things like openrc, runit or s6 don't exist.
sysv is a common shorthand for script-based init systems in general, whether they be "real" system V, BSD-style, OpenRC, runit, etc.
No it isn't. You pulled that completely out of your ass. Those things you listed are all quite different.
>he should be blaming teamspeak
didn't this get killed by mumble years ago? (and more recently the discord cancer?)
Yeah nah. I'm not sure about the rest but runit is definitely nothing like sysv init.
sorry, but google can confirm it
>google
>botnet
good meme
there are some soft PLCs running on OS but most of the PLCs I have dealt with (siemens/AB/rockwell) need hard realtime 30ms scan cycles and an OS can't be trusted for this. Safety PLCs are worse.
Mostly the HMIs can be software now.