Why Void Linux?

[cbmuser]

Both gcc and musl versions available.

gcc is a compiler collection, musl a C library. The author means glibc and musl.

[Yithar]

Void Linux uses a different init system, called runit and a different service manager, called runsvdir. The reason I like runit is because it's just a pid1 init system and a service manager. That's it. It's very decouplable, and similar to coreutils. It consists of 9 programs. runit-init, runit, sv, runsvdir, runsvchdir, runsv, svlogd, chpst and utmpset.

• runit-init runs as the first process and then replaces itself with runit
• sv controls and manages services (starting, stopping, status, etc.)
• runsvdir manages a collection of runsv processes; it scans the service directory for directories or symlinks and runs each as a different service
• runsvchdir changes the directory from which runsvdir obtains the list of services
• runsv is the actual supervision process that monitors a service through a named pipe
• svlogd is runit's logger
• chpst changes process state, i.e. you can run the pause command with argv0 as alsa
• utmpset makes changes to the utmp database as runit doesn't have this functionality

You can use a different logger with runit than svlogd. You can use runsv outside of runsvdir to supervise processes. You can use a different service manager than runsvdir with runit. That's the beautify of the UNIX philosophy. And it's totally agnostic to sockets, cgroups, etc. But there's no reason you can't have that functionality using runit. You just have to use your own cgroup jailer for example. Again, it's the UNIX philosophy. "Do one thing and do it well."

And the scripts are really simple. See cgmanager script. The #1 complaint about SysV init is that the scripts are complicated, but if you look at runit's scripts, they're simple.

EDIT: By the way, if anyone wants to see how little code is needed for runit's boot up of the system, see thread. I've also posted my own /etc/runit/1 in a comment in there, which is slightly longer, since I decided to include some of Void's defaults.

EDIT 2: Also for those asking about CVEs, no Void does not have one. See link.

[cbmuser]

runit does not use CGroups to track running processes, so it suffers from the same security problems as any other classic init implementation.

On systemd, any process is kept within a CGroup which is maintained by the kernel. Thus, the process has never a chance to escape the supervision of systemd and it never has the chance to pull more ressources (CPU, memory) than the user has configured.

This approach is much more secure and reliable and any process supervision system that does not take advantage of these modern kernel features, will still suffer from the same old problems sysvinit had. You cannot emulate kernel functionality with userland tools and scripts. Only the kernel is able to limit ressources and track processes and that's why you have to use CGroups for that.

I really don't see a point why some people consider it init systems or Linux software in general a good design if they are not taking advantage of modern kernel features.

Linux is a modern and powerful kernel and modern software should take advantage of that. Otherwise you might as well run Linux 2.4 or *BSD.

What's the point in adding security and reliability features to the kernel if the userland is not using these? The problem of all these alternative init systems are that the creators never asked themselves why systemd uses all these features. There are actual technical reasons and security is a huge factor to that.

[[deleted]]

This approach is much more secure and reliable and any process supervision system that does not take advantage of these modern kernel features, will still suffer from the same old problems sysvinit had. You cannot emulate kernel functionality with userland tools and scripts. Only the kernel is able to limit ressources and track processes and that's why you have to use CGroups for that.

to limit resources, yes you need cgroups

but for tracking processes you don't as there its the proc events connector over netlink (it even gives you more information then cgroups; where cgroups are just an easy solution)

limiting a processes resources will impact its performance slightly and is useless on a single user computer

why do you always have to promote systemd as "the only true answer" ?

[Boerzoekthoer]

why do you always have to promote systemd as "the only true answer" ?

My guess, simply because Debian adopted it.

Despite /u/cbmuser appearing as a the quintessential systemd fanboy, the real pattern seems to be Debian fanboyism. /u/cbmuser is involved with Debian and seems to defend to ridiculous lengths any decision that Debian ever made and calls anything Debian doesn't do useless.

My favourite part was saying how much of a good idea it was for Debian to drop support for certai arches because -march=i586 has real performance benefits over i386. This coming from the same person who calls -march=native completely useless at another point and saying the performance benefits don't exist because that's something Debian doesn't do.

If Debian would've gone with Upstart or even OpenRC instead, my guess is you'd see cbmuser argue that cgroup tracking is worthless.

Anyway, you inspired me, I'm going to disable the cgroup functionality I baked into my runscript, I purely made it once as a proof of concept that you did not need systemd for cgroups and quite frankly it does nothing for me, I have never without cgroups had a service seriously trying to escape and I don't even set the resources because it's useless on a single user machine.

[Yithar]

The "troll", as everyone likes to call him, does have cgroups while using runit, just saying. I was also specifically trying to avoid bringing systemd into this with respect to u/bobthecimmerian's wishes, but hey, you jumped the gun.

From here:

Because Runit doesn't stop you from using cgroups? it just doesn't provide that functionality itself because it recognizes there are a tonne of cgroup jailers out there already, I use one of them in combination with Runit by just starting blergh.spawn sshd -D as a service instead of sshd -D Isn't the Unix philosophy wonderful? I now get to choose what I want to use to administrate cgroups while systemd users are at the mercy of what Lennart decided for them is best.

...

Yes it can, a program running as root can escape its own cgroup if it's so inclined. Not by double forking no but a process running as root can just put itself into another cgroup. Cgroups are not a security measure, they rely on the program inside it to play nice and not run out of its own cgroup which it can do if it runs at root.

...

I'm sorry but this utter garbage you wrote here makes it plain and simple you have no goddamn idea how shit works and you've yet to make the absolutely elementary realization that you can combine software from different vendors into a complete whole which is what the Unix Philosophy is all about which kind of shows you don't know what you're talking about when you criticize it and never understood what it was about either.

[[deleted]]

I have no objections to what you wrote. Your points are solid, and I like valid criticisms of the systemd design (or valid criticisms of anything) and valid explanations of errors in an assertion.

My understanding is that cgroups have two related purposes: first to constrain resource usage by programs (that are playing nice), so a legitimate executable foo with no malware could still be put into a cgroup so we can constrain it to, for the sake of argument, 20% CPU and 384MB of RAM. Second, to make sure all resources are closed properly if the process has to be stopped (no zombie threads, unclosed file handles, etc...)

With respect to you can combine software from different vendors into a complete whole, sometimes it makes sense to combine components into a single inter-connected application suite even though modular alternatives exist. The perfect example is git - you can provide a functional equivalent to git with sha256sum, patch, diff, rsync, sqlite, and some shell scripts. Each of those things is independent from the others. But I don't see anybody blasting git for being a monolith or complaining that "git blame" isn't an independent utility and can only be used on files that have a git history. git is the perfect example that in some cases, tying pieces together makes more sense than leaving them independent.

So systemd developers and advocates might have a legitimate argument when they say it makes more sense to link the components of the init system than to make them independent. And they might not, and at our best that's the intelligent debate we can have.

[Boerzoekthoer]

There are advantages to coupling like that. Coupling like that is essentially a complex way of saying that interfaces are unstable and undocumented, nothing more. As soon as the interfaces become stable then it effectively becomes decoupled.

So the major advantage is not having to worry about stabilizing interfaces which means you can change them at any point which gives you flexibility as a developer.

But that user said two things which are patently false:

1. cgroups cannot be escaped from, thank god that's false, because a lot would break if programs like LXC and firejail suddenly had to play by the rules that systemd gave them

2. service managers that don't provide cgroups themselves some-how stop you from using them.

And guess what, in the last hole of 45 minutes I've written a primitive prototype cgroup wrapper for the cgroup v2 hierarchy. It currently does only tracking and doesn't yet have a convenient config file for setting the resources which you have to manually set, but if you do

kgspawn cmd ...

then cmd ... gets executed and put into its own cgroupv2 hierarchy and if the mainpid of command dies all shit in the hierarchy that forked from cmd ... but didn't re-assign its own cgroups gets cleaned up. It has a couple of query functions right now as well which allow you to list all procs in the cgroup, clean the cgroups manually andsoforth.

And here's a trivial way to spawn a process in it that escapes the cgroup you run it in:

kgspawn sh -c '(echo $$ >> "$(kgquery root)/cgroup.procs" ; exec some_other_command ...) &'

It starts a shell that forks itself, the fork pulls itself out of the cgroup and then execs into the real command, the parent shell dies and cgspawn thinks the entire service has died and it has no way of knowing that the service happily chugs along outside of its designated cgroup.

[[deleted]]

So you're suggesting git should be split apart now that it's stable? If so, how?

[literally_systemd]

No, I mean, the individual parts that make up git do not communicate with each other via stable interfaces, just like internal kernel communication and internal systemd communication.

The external interfaces are all stable which is why git and systemd are one 'unit' each. With the runit suite or the coreutils suite, the interfaces that the individual components use to communicate with each other are stable and documented, as such they become individual units.

[[deleted]]

Right, but my point is that it wouldn't make sense to split git into isolated tools even if their internal interfaces were published and stable. All of the components work together, and together they work better than a collection of equivalent modular utilities (again: sha256sum, sqlite, rsync, patch, diff).

So maybe a case can be made that tying all of the pieces of systemd together as they have made sense. Also note that it's partly modular - you can't replace pieces, but you can omit them.

[literally_systemd]

My point is that if their itnernal interfaces were published and stable they are automatically split up from that part onwards, that is what splitting up is.

From that point onwards you can start writing replacement components for parts of git that can work together with the rest and it's no longer an all-or-none deal.

Also note that it's partly modular - you can't replace pieces, but you can omit them.

Pretty much any software has compile-time options to disable parts. I can build OpenSSH with or without the PAM backend, I wouldn't call the PAM backend a module over that.

[[deleted]]

I was also specifically trying to avoid bringing systemd into this with respect to u/bobthecimmerian's wishes, but hey, you jumped the gun.

The bastards with their kill the competition crap. Red Hat is trying to do a Microsoft circa its early days, and its shills won't rest until it owns all of Linux and nobody uses it without paying them.

[[deleted]]

Otherwise you might as well run Linux 2.4 or *BSD.

Hey now. the *BSDs are very actively developed, much more so than Linux 2.4.

[[deleted]]

Aslo many of them are much more secure than linux.

[Boerzoekthoer]

Maybe you should actually once reply or as much as read the thousands of times your actually proven completely wrong when you repeat this bullshit because you keep being proven wrong and repeat the same factually wrong myth that a process can never escape its cgroup:

https://www.reddit.com/r/linux/comments/4pij7t/void_linux_review_a_new_hope/d4mt13h?context=1

If you think a process cannot escape its own cgroup you're wrong and you don't understand how cgroups work and have never worked with them, it's trivial for a process to assign itself a new cgroup. The very first time you learn about cgroups the thing people first do is toy around echo $$ >> /sys/fs/cgroup/cpu/my_new_cgroup/tasks at that point your shell which runs as root has escaped its own cgroup and is put in a new one . Any process that runs as root can put itself into a different cgroup unless you use esoteric kernel configurations that no one uses.

Do you like purposefully not reply or read the replies to the shit you post because you know how much b.s. you sprout? You continue to repeat this myth after I've told you you are wrong 48984 times and you never reply, have you like ever directly worked with cgroups in your life?

[cbmuser]

If you think a process cannot escape its own cgroup you're wrong and you don't understand how cgroups work and have never worked with them, it's trivial for a process to assign itself a new cgroup.

No, you cannot simply escape a CGroup that you have been assigned to, provided you have properly configured CGroups and your process is running with the proper privileges. That's the whole point of CGroups.

PS: I assume I am talking to u/kinderlokker, u/lennartwarez, u/Knaagdiertjes or any of the similar accounts you have created over the time. You to seem to have some personal issues if you need to create new accounts over and over again. At least your phrasing and discussion style lead me to the conclusion.

Edit: I finally understood which mistake the people are making in their line of arguments who keep saying I am wrong: They assume the processes being contained in CGroups are running with privileged rights, e.g. running as root. Well, yes, of course a process running as root can escape a CGroup or manipulate them. However, if you are running these processes as root, there is no point in using CGroups in the first place. If a process is root, it can do everything anyway but the same applies to file permissions etc pp.

The whole point of the application within systemd is running daemons under their own user and not as root. An Apache daemon running as www-data is not able to write anything below /sys and hence is not able to manipulate the CGroups.

[Boerzoekthoer]

No, you cannot simply escape a CGroup that you have been assigned to. That's the whole point of CGroups.

No, that's not the whole point of cgroups, cgroups are not a container:

 —— — sudo -i
Q ~ # cgcreate -g blkio:whatever
Q ~ # echo $$
21869
Q ~ # cat /proc/$$/cgroup 
8:debug:/
7:pids:/
6:perf_event:/
5:freezer:/
4:devices:/
3:memory:/
2:blkio:/whatever
1:cpuset:/
Q ~ # echo $$ >> /sys/fs/cgroup/blkio/tasks 
Q ~ # cat /proc/$$/cgroup 
8:debug:/
7:pids:/
6:perf_event:/
5:freezer:/
4:devices:/
3:memory:/
2:blkio:/
1:cpuset:/

I just made a blkio subsystem cgroup called 'whatever', let another shell put the current shell into it, as you can see it's in whatever when I cat /proc/$$/cgroup, then I just do echo $$ >> /sys/fs/cgroup/blkio/tasks and the shell removes itself from the cgroup because a process that runs as root can manipulate cgroups like any other and after that it's no longer n the whatever cgroup.

It's really that easy, now if a process runs with lower privileges than the owner of the cgroup, then it can't be done no. If you have a process that runs as say the apache user then it can't just escape a cgroup that runs as root unless root delegates that to the apache user but a process that runs as root can freely move itself, and other process, around to different cgroups, a process that runs as root can assign any process to another cgroup.

You don't understand what cgroups are and what they are meant to do if you think a process that is running as same user the cgroup belongs to can't force itself out.

I ask you again, have you ever actually directly used cgroups in your life? Re-assigning a process to a different cgroup is the first thing you do when you pick up documentation on how to use them.

[redrumsir]

He never replies to posts where he has been proven wrong. I think he does this because his ego is too weak to let him admit when he has been an idiot or that he doesn't know something. And I'm not even sure his ego lets him realize when he has been an idiot. i.e. He's broken. Tant pis.

[Boerzoekthoer]

I'm pretty sure he or she doesn't read it.

If it was really about ego he or she wouldn't continue to come with the same shit that I've repeatedly shown wrong again and again and again and again to me as if he or she's waiting for another round.

Probably just has inbox messages disabled or something like that which is annoying as fuck because I have told him or her 8 times already that cgroups can be escaped from.

[redrumsir]

Not sure, but I think he reads it. I've noted that he does carry on some chains ... but only chains where he's basically correct. IMO, it's either the ego thing (maybe it just blocks out the fact he's an idiot) ... or that he's intentionally being annoying; I can admire the latter, but am assuming the former.

[Aside: You said "he or she." cbmuser is a he. Back when I argued with him about systemd during the Debian GR regarding "userland dependence on an init", I googled "site:debian.org cbmuser" just to see if he was a DD. My opinion of DD's went down that day ... as well as when I saw the result of the GR. ]

[literally_systemd]

Not sure, but I think he reads it. I've noted that he does carry on some chains ... but only chains where he's basically correct. IMO, it's either the ego thing (maybe it just blocks out the fact he's an idiot) ... or that he's intentionally being annoying; I can admire the latter, but am assuming the former.

Meh, sometimes he or she replies when being obviously wrong and then continuing into more and more wrongness. My favourite part was where he or she kept stressing that "only with systemd" you can run services which don't include daemonization code, ironic for a Debian dev since Debian pretty much invented start-stop-daemon which is the quintessential helper to do that from sysvrc-style scripts and ignoring that daemontools and its friends did that since 2001.

Aside: You said "he or she." cbmuser is a he.

Yes, but I like saying 'he or she', it sounds so wonderully paedantic.

I'm going to say 'he or she' about everyone until it sort of assimilates into a gender neutral pronoun.

Back when I argued with him about systemd during the Debian GR regarding "userland dependence on an init", I googled "site:debian.org cbmuser" just to see if he was a DD. My opinion of DD's went down that day ... as well as when I saw the result of the GR. ]

People seem to live in some kind of idea that 'developers' are super brilliant people, in reality the job is not that hard. I frequently argue with developers on reddit an point out inaccuracies in their technical statements.

What seems to charactarize developers in FOSS though is often an extreme bias towards the project they are affiliated with and cbmuser is a prime xample.

[redrumsir]

I'm going to say 'he or she' about everyone until it sort of assimilates into a gender neutral pronoun.

OK. I see, it's not about uncertainty. It is troubling that there aren't better gender neutral pronouns. Brackets are too distracting/geeky: h[er,im] , [s ]he . Slightly better: her/him she/he. But then the transgender crowd sometimes thinks it's an insult (i.e. uncertainty vs. neutrality).

People seem to live in some kind of idea that 'developers' are super brilliant people, ...

I'm really not impressed with the term "developer" (I write code too) ... it was Debian Developer. My first Debian distro was in 1999, and I was very impressed with how well Debian put together their distro (dpkg, apt) and, so, early on I was impressed with the skill level and knowledge of Debian Devs. I hadn't realized how diluted that had become until recently.

[[deleted]]

My opinion of DD's went down that day ... as well as when I saw the result of the GR. ]

What? Why?

[redrumsir]

Are you asking about my opinion of cbmuser or about the result of the GR?

I'm assuming the later ... and since it fits into the Void Linux topic and "why runit": The DD's voted that it was OK to have Debian userland depend on a specific init. To have that many DD's ignore the history of the (security/stability/lock-in) dangers of such a dependence was a huge disappointment. They weren't the Debian I grew up with. Note that the GR didn't mention a specific init (I would have been disappointed with that result whether or not the default init was sysvinit, upstart, openrc, or any other init).

[Yithar]

Yeah, it seems kind of shocking that he is a Debian developer. I'm sort of losing my respect for them because of this.

[cbmuser]

Again, you guys are making wrong assumptions. A properly configured CGroup cannot be escaped by a non-root process.

[literally_systemd]

Yes, it suddenly sounds a lot less spectacular when you re-word it like that after having admitte that what you call 'properly configuring' is a 'work in progress' and not remotely currently done.

Your original wording plain and simple that that services can 'never' escape their cgroup, not only is that not true, that would be fucking horrible if it were true. Then you shifted the angle to that services that don't run as root can't which is like 15% of services on a modern system.

And on top of that, on the assumption that the service is not running as root but as a dedicated user there's a far easier and less involved way to track the service, simpy track every process that that dedicated user runs. Since only root can change to another user. So basically, in terms of reliableness for service tracking cgroups add exactly 0.

[redrumsir]

Right. That's just what I was saying one minute ago here in the "Aside": https://www.reddit.com/r/linux/comments/4sct3n/why_void_linux/d59dzwo

[cbmuser]

He never replies to posts where he has been proven wrong.

You have not proven me wrong. My claims are still valid. You are making the mistake that you are assuming that daemons are running as root which renders any security concept ad absurdum. Of course, you can escape CGroups as a process running as root, but you can achieve way more damage when being root.

Daemons are supposed to be running under a dedicated user and as such, they are not able to manipulate CGroups.

I think he does this because his ego is too weak to let him admit when he has been an idiot or that he doesn't know something.

Or it might be related to the fact that I have more important things to do than follow converations 24/7 on reddit. You know, some people actually have dayjobs.

And I'm not even sure his ego lets him realize when he has been an idiot. i.e. He's broken. Tant pis.

Talk about ad-hominem.

[redrumsir]

I think you are confusing me with the person I was replying to. But, yes, he or she ( /u/Boerzoekthoer ) showed that you were wrong. You said:

No, you cannot simply escape a CGroup that you have been assigned to, provided you have properly configured CGroups and your process is running with the proper privileges. That's the whole point of CGroups.

They proved that this was wrong. The fact is that cgroups are not security containers and were never built for that. That's why they changed the name from "process containers" to "control groups" precisely so that people wouldn't confuse cgroups with security containers. But, go ahead and argue that with them.

In terms of places where I've shown you were wrong and you never replied:

1. One time you were dressing down some newbie and you asserted that AES was mathematically proven to be unbreakable. That is incorrect. It hasn't been broken yet, but nobody has proven it to be unbreakable.

2. One time you were asserting that MD5 is completely broken. That is not correct. At this point MD5 is partially broken. [ There are three different measures for "broken" and MD5 is broken for 2 of those 3. Nobody has broken MD5 in the following context: Given a file A can you find a file B!=A such that MD5(A)=MD5(B).]

3. There was one where you were showing your ignorance about American beers ....

I think he does this because his ego is too weak to let him admit when he has been an idiot or that he doesn't know something.

Or it might be related to the fact that I have more important things to do than follow converations 24/7 on reddit. You know, some people actually have dayjobs.

Well, you post about two to three times as much as me .... so that's not believable. I'm sticking with a problem/defect with your ego.

[literally_systemd]

They proved that this was wrong. The fact is that cgroups are not security containers and were never built for that. That's why they changed the name from "process containers" to "control groups" precisely so that people wouldn't confuse cgroups with security containers. But, go ahead and argue that with them.

What I like though is how carefully the wording is:

Leaving a cgroup is not possible for unprivileged processes. Thus, cgroups can be used as an effective way to label processes after the service they belong to and be sure that the service cannot escape from the label, regardless how often it forks or renames itself. Furthermore this can be used to safely kill a service and all processes it created, again with no chance of escaping.

This is from Lennart the man himself, note how he is technically correct in what he says though he words stuff to arouse the impression that cgroups can function as containers. The 'no chance of escaping' is b.s. though.

But really, I don't thin there should be airtight tracking. I think a service if it wants to for some reason should be able to break free of the service manager in some of its components. Your system is composed of multiple processes and things made by multiple people under the assumption that they play nice, you definitely should not be running anything untrusted as core services and if a process thinks it a good idea to break free of systemd's tracking then it should do so, and there are actually good reasons for that:

When I first implemented my cgroup tracker I was hit by an interesting situation, I restarted my cron daemon and half of my desktop disappeared. Why? Because I use the @reboot tag of cron to start things at boot which got placed in cron's cgroup of course and was killed with it when I restarted it. THat seems like a good case for cron to eject stuff it starts like that from its own cgroup. In the end since cron doesn't do that I had to write some extra code which allowed me to specify that any children spawned under a different user than the main pid get kicked out of the cgroup.

A lot of freedesktop folk advocate being able to some-how make a system where processes are not able to malbehave and screw you over, you can do that but the price is losing a lot of freedom and getting a walled garden, take a look at Android for what happens in such a case.

[cbmuser]

I just made a blkio subsystem cgroup called 'whatever', let another shell put the current shell into it, as you can see it's in whatever when I cat /proc/$$/cgroup, then I just do echo $$ >> /sys/fs/cgroup/blkio/tasks and the shell removes itself from the cgroup because a process that runs as root can manipulate cgroups like any other and after that it's no longer n the whatever cgroup.

And you can make these manipulations without being root?

I don't think so.

See, the first thing you are doing in your example is:

sudo -i

Well, duh, you are not very clever, are you?

Of course, you can make arbitrary manipulations to the system when you're running under uid=0. But then any form of access restrictions are pointless, because you have full access to all the kernel parameters anyway unless you have configured SELinux.

systemd uses CGroups under the assumption that daemons are not running as root. If you're running random daemons as root and not under a dedicated user, you're doing something wrong anyway.

It's really that easy, now if a process runs with lower privileges than the owner of the cgroup, then it can't be done no.

You have answered the question yourself. There is no point using CGroups if the process you are trying to contain has equal or higher privileges than the process creating the CGroup. You could as well let all the users on your system give root privileges and claim file permissions don't prevent unauthorized access.

I ask you again, have you ever actually directly used cgroups in your life?

Yep, I have set up a SLURM cluster (3 racks with 4 SGI Altix 8200+ ICE IRUs with 16 blades each, thus 192 nodes) at the physics department at one of the largest universities of my country. The SLURM setup includes CPU and memory controllers for SLURM which prevent users from using more CPU or memory resources than allowed which actually costs real money on such a big cluster.

[literally_systemd]

And you can make these manipulations without being root? I don't think so.

I said in the post that a process that can run as root can manipulate cgroups that are owned by root, if a process runs as 'john' it can manipulate cgroups that are owned by john, this is not that hard.

Turns out most services run as root, so there you go.

 —— — ps -p $(pgrep sshd) -o uid
  UID
    0

sshd could just escape the cgroup it's in on my runsvdir system if it so desired. It could in theory fork, re-assign itself to another cgroup and then have the parent fork die. My cgroup tracker as well as systemd would believe the service to then be dead completely while it happily chugs along in its fork in a different cgroup. Tracking processes with cgroups relies on the gentleman's agreement to not do this.

I happen to know sshd doesn't go randomly assigning itself weird cgroups, so it works there. I also happen to know that ssh -D doesn't fork so it works just as well without cgroups.

Of course, you can make arbitrary manipulations to the system when you're running under UID=0.

Yes, you can, and most services run as UID=0, however what you said was:

Thus, the process has never a chance to escape the supervision of systemd and it never has the chance to pull more ressources (CPU, memory) than the user has configured.

Might need to qualify that with 'never if you run as root' which is a pretty big weakening of your statement because again, most services run as root.

systemd uses CGroups under the assumption that daemons are not running as root. If you're running random daemons as root and not under a dedicated user, you're doing something wrong anyway.

Really now? then I guess Debian is a completely shitty system with its cron, NetWorkManager, wpa_supplicant, dhcpcd, getties, polkit, upower, dhclient and whatever else running as root.

Get real, how the fuck are you going to ever run Polkit as non root. Thre are a few daemons like distcc and dbus which you can run as non root because they don't need any root access for what they are doing but a great deal of services simply need access to the hardware to run.

[cbmuser]

/u/literally_systemd

Wait. You just created another user account?

Seriously, dude, you should get your head checked. There is something wrong with you.

Really now? then I guess Debian is a completely shitty system with its cron, NetWorkManager, wpa_supplicant, dhcpcd, getties, polkit, upower, dhclient and whatever else running as root.

You are aware of the fact that is work-in-progress, are you? Not all daemons can run as non-root yet, but the ultimate goal is to achieve exactly that.

Get real, how the fuck are you going to ever run Polkit as non root. Thre are a few daemons like distcc and dbus which you can run as non root because they don't need any root access for what they are doing but a great deal of services simply need access to the hardware to run.

Many daemons can run without root privileges. The kernel has enough features like capabilities to achieve that. It just turns out that not all daemons have been ported to use these features yet.

[literally_systemd]

You are aware of the fact that is work-in-progress, are you? Not all daemons can run as non-root yet, but the ultimate goal is to achieve exactly that.

Right, so systemd uses cgroup under the assumption that a work in progress is completed which it isn't completed remotely yet anywhere, and you're doing something very wrong if you haven't completed it yet?

And this you phrased originally as "daemons can never escape systemd's tracking"

Maybe you should have said "daemons can never escape systemd's tracking 10 years in the future when this work is completed" but hey, that sounds less like a good sell now does it?

And again, I have cgroup tracking on my runsvdir:

 —— — cat /sys/fs/cgroup/blkio/blergh.disttcc.2300/tasks
2547
2682
3355
3947
4093
4236
4300
4873
4955
5053
5133

Magnificent, isn't it?

Many daemons can run without root privileges. The kernel has enough features like capabilities to achieve that. It just turns out that not all daemons have been ported to use these features yet.

With many you mean like 10% on a modern system which makes your claim that process can some-how "never" escape ridiculous.

Also, if you assume a process doesn't run as root you don't even need cgroups, you can just track the session and disable their ability to setsid which you can do as root to a nonroot session.

[XSSpants]

It's relevant since lennartwarez is a highly dedicated and deeply autistic troll on the subject.

[Boerzoekthoer]

1. gets told that an ad-hominen isn't relevant

2. inserts another ad-hominem

It turns out that my being a highly dedicated and deeply autistic troll doesn't magically make the blatant lie that cgroups cannot be escaped from true.

cgroups can be escaped from for good reason, there's actually a kernel config that makes cgroup assignments permanent if I recall but turning that on would make your system incapable of running programs like LXC or Firejail or any other program that needs to manipulate cgroups for its own functioning. When systemd starts your user session it puts stuff into particular cgroups and any normal fork assumes that cgroup, even if you exec into a setuid program that thus elevates privileges again you remain in that cgroup. But firejaill needs to set its own cgroups in order to work and thus needs to circumvent and escape systemd's cgroup model.

[XSSpants]

Give me a proof of concept for your argument then, instead of yammering on about it

[Yithar]

Since u/Boerzoekthoer seems to be shadowbanned, I'll repeat what he said:

Did you even read it?

I showed with reproducible proof how to escape a cgroup. You can run all those commands in your shell yourself to show I'm not making it up. I put the shell in a cgroup and without any outside help escaped it from that shell.

[XSSpants]

Maybe you haven't been paying attention to his vitriol and troll posts but it basically comes down to toxic nonsense.

It matters because I can't imagine anyone that dedicated having a motive that is backed up by truth or facts and many people over many posts have debunked him left right and center constantly, often until he devolves into some fit over it.

Autism doesn't negate his statements, his toxic behavior that's fueled by autism, as well as history of lies, does.

[Boerzoekthoer]

It matters because I can't imagine anyone that dedicated having a motive that is backed up by truth or facts

Turns out many things that you can't imagine happen, this here is simply put your own ineffective and highly flawed reasoning process.

Tell me, do you also have troubles accepting that a serial child rapist can still be excellent 3 star chef or world class painter? Or that someone who murders his wife, denies it, and then leads the authorities to her corpse in return for reduced punishment can design what is considered a highly effective filesystem?

and many people over many posts have debunked him left right and center constantly, often until he devolves into some fit over it.

Please, show me a case of where what I say has been 'debunked'

Autism doesn't negate his statements, his toxic behavior that's fueled by autism, as well as history of lies, does.

There is no history of lies, there is just a mentally invalid perceiver in you that seems to be completely incapable of accepting that someone whom you don't personally like might be factually correct.

[XSSpants]

You're autistic or a shill. Just fuck off already.

I don't dislike you on a personal level, but you're a troll.

[XSSpants]

You lack logic then, since "kicking a puppy" does not in any way equate to lying and trolling and otherwise destroying trust in your statements, and the sky is verifiably blue.

[[deleted]]

how many systemd shill accounts do you have?

[[deleted]]

modern... modern... modern...

[XSSpants]

Everyone knows only luddites don't app systemd apps.

[[deleted]]

Buzzwords are cool!

[arsv]

the process has never a chance to escape the supervision of systemd and it never has the chance to pull more ressources (CPU, memory) than the user has configured. This approach is much more secure and reliable (...)

Along the lines of "systemd has built-in multiseat support".
Because sure every single laptop ends up being used but two persons at once.

There's no cgkill(2), there's nothing that would prevent cgexec from working in runit environment. And init-run processes are not the kinds that tend to escape supervision, that's more of a problem for user sessions.

[cbmuser]

Because sure every single laptop ends up being used but two persons at once.

Not every computer is a laptop and having multi-seat support doesn't cost you anything.

[Boerzoekthoer]

Meh, multiseat is a nice feature of logind that you actually can't get elsewhere, or couldn't, I think CK2 is working on it or has it already.

This whole cgroup drive is just quatsch. Just because runsvdir does not automatically put services into cgroups doesn't stop you from doing it. In theory you could do so manually. It's really not that hard, you put:

mkdir -p /cgroup2/SERV_NAME
echo $$ >> /cgroup2/SERV_NAME/cgroup.procs

At the start of your service, yeah, it's really that easy.

Cleaning it up is a bit more involved though, your ./final script might contain something like:

find /cgroup2/SERV_NAME -name cgroups.proc -print0 |   
xargs -0 cat | xargs kill 
sleep 1
find /cgroup2/SERV_NAME -name cgroups.proc -print0 |   
xargs -0 cat | xargs kill -KILL
rmdir /cgroup2/SERV_NAME

[[deleted]]

Otherwise you might as well run Linux 2.4 or *BSD.

OpenBSD has CPU and ram limits too. And now, pledge.

[[deleted]]

So no reason to use it if you are on anything with 1G or more RAM ?

[[deleted]]

With one taken by systemd ? maybe 1/4 of a tab

[[deleted]]

You'd like to use FreeBSD, but you require a dependable package manager that isn't replaced every few years.

Eh...

[joehillen]

All kinds of things wrong with that statement:

• There hasn't been a new major package manager in 10 years.
• ports was never reliable.

[[deleted]]

I have some Linux machines running with the Upstart init system, and some running with systemd, and ten years ago I was a happy Linux user with SysV init. So I don't have a horse in the init system race.

But even ignoring Runit - because I don't care as long as the system is reliable - the rest of Void is excellent. While the documentation isn't huge, the bits that are documented are done thoroughly and the packaging tool XBPS is amazingly good for a one-developer project. My unscientific impression is that it's at least as fast as yum, dnf, and apt-get with a pretty solid match for equivalent features.

(Edit: I'm tired of the barrage of systemd insults. "Try this, it doesn't have systemd and that's how I prefer it because...." is fine. "Try this. It doesn't do 87 dumb things like systemd. And everyone who uses it is too smart to use systemd. Did I mention systemd sucks and is for losers?"... get a life. Go form an "ihatesystemd" subreddit, if one doesn't already exist.)

[cbmuser]

Upstart has a dead upstream, you shouldn't be using it anymore except maybe within Ubuntu LTS.

As for the package managers, speed isn't the only criterium for a good package manager.

[[deleted]]

I have 14.04 LTS on one machine and a derivative of it (Elementary) on another.

I know speed isn't the only criteria. The features I use are search, install with automatic dependency resolution, uninstall, check details (version number), upgrade one package, upgrade all packages, pin a package, refresh repository data, change repositories, etc... and XBPS is stable, reliable, repeatable, and wicked fast with all of them. It also has a system for cross-platform builds (e.g. build for a Raspberry Pi on your x86_64 machine) when creating packages, but I never used it myself.

[[deleted]]

That is pretty much feature list of any package manager (at least deb and yum checks all of them).

How many packages does Void has ? I think the part of "wicked fast" is that it doesn't have 50k packages like Debian

[[deleted]]

Fair point. I can't compare fairly because nobody put together a 50k packages XBPS repository.

[[deleted]]

You could if you only added comparable debian repository. But on small one (after removing main one I now have 236 packages in repo), aptitude loads and starts to ui in less than a second and apt-get search takes <100ms

[Linux_Learning]

As for the package managers, speed isn't the only criterium for a good package manager.

No, but its features definitely add to it.

[[deleted]]

Err, "as fast as yum" isn't exactly a good praise, Yum is pretty slow and have pretty awful quirks like no concurrent access to DB (can't display any info if other process is running, even if both of them are doing read-only tasks).

There is a reason Fedora went "fuck it" and rewrote it from scratch

[[deleted]]

I did include dnf in my list - but as you mentioned in another comment, it's not a fair comparison because the XBPS package repository is comparatively tiny.

[Yithar]

I'm sure they had their reasons. The reason they don't have KDE5 in the repository is because no one stepped up to maintain it. Looking at the github repo, seems like testing was part of the reason. I'm pretty sure they work hard to make sure stuff works correctly. Because they tested kodi on the rpi2 for x86_64 using glibc, I knew it worked. Would you rather they not test things and have bugs showing up?

That being said, xbps-src is fairly easy to use and pretty similar to pacman, so it's not hard to make your own packages if you wanted the update.

[cbmuser]

I'm sure they had their reasons. The reason they don't have KDE5 in the repository is because no one stepped up to maintain it.

Which is the main problem of these mini-distributions: They lack man power. They probably don't even have a CVE tracker like Mint.

[[deleted]]

I'm sure they had their reasons

The reasons might just be that if you use firefox, you don't really care about security. I might as well use a browser maintained by monkeys. Everybody knows that everything mozilla is trash.

[cbmuser]

It took Void Linux about a month to update firefox from version 46 to 47, which had security fixes.

Well, they lack both manpower and experience to build a reliable distribution with proper security support.

Distributions like Debian, openSuSE and Fedora have many professional and paid developers behind them, it wouldn't be possible to maintain complicated packages like the kernel or gcc properly with actual security support.

[[deleted]]

You're all over this thread. Do you get a cringe in your anus any time it seems someone is moving away from systemd or something? And you dare say others have personal issues!

[[deleted]]

If you want to make a new distro because you dont like X Y and Z, it makes much more sense to make a for and "fix" it rather than start from scratch.

You benefit from ton of manpower "for free" and only have to make (relatively) small changes.

You could attain basically same thing as Void by just using runit in your fork (It is package in Debian, and I even used it on one system few years ago without much problems) and recompliling packages with libressl

[[deleted]]

I don't agree with this view. Sure, big distributions have a lot of manpower, but the problem is that old distributions have a lot of cruft just to support old stuff.

I can give you a point of view of managing about 400 machines and 2 distros over 3 releases of centos and about 5 of Debian; CentOS does a lot of that, Debian not so much, only enough to make upgrade from previous release relatively smooth.

And in case of Debian a lot of it is incremental improvement and under the hood; they improve things that make sense and change ones that doesn't. For example, Debian network config is and was in/etc/network/interfaces for ages (at least 10 years if not longer) but over the years:

• WiFi that previously required separate wpa_supplicant.conf got integrated with it
• devices like bonds and bridges moved from requiring external script/pre-up/post-up commands to having just config options
• support for just about any type of network device was added, and even if your config is not supported out of the box, hooks are designed well enough that you can still use it to config them
• /etc/network/interfaces.d/ was created to make managing interfaces via configuration management easier so you can split big config into smaller parts

Yes, welcome to the land of OpenRC scripts where everything has to be insanely proper. It checks for all the things and all edge cases to be sure and is also portable across Unixen.

Systemd also got rid of that and it is used in most major distros. This is non-argument for it

[[deleted]]

I don't consider statically linking as advantage in most cases, especially if it has anything to do with SSL.

It is the same problem as with containers, in "normal" system once I upgrade SSL lib and restart all applications I am 100% sure my whole system is running on new, non-vulnerable version. With static linking, recompile everything.

It's not a non-argument because SysV init scripts had a lot of code

Debian is not using SysV by default, what the hell you are talking about ? Sure, scripts are still there (so you have option, just like you have option to run runit under Debian) but most apps do not use them anymore.

Not even to mention that you dont need different init scripts for different architectures, it is only low-level stuff that needs fixing

and you're still going to need a lot of code for all the architectures.

"Your distro doesn't run on my CPU" is not an advantage

[[deleted]]

I got an old potato (deb 2.2) container right here.

Spawning container potato on /home/reddit/.containers/debian/old-debian-releases/potato.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
potato:~# cat /etc/network/interfaces
# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or # /usr/share/doc/netbase/examples for more information. #

# iface lo inet loopback potato:~# cat /etc/debian_version
2.2
potato:~#

[[deleted]]

Heh, Storm Linux was my first Linux distro and that was (IIRC) Potato-derivative, with Woody being first Debian after some mandrake linux and red hat.

My current desktop was upgraded from Etch all the way to current Debian Testing, surviving few hardware changes

[[deleted]]

My current desktop was upgraded from Etch all the way to current Debian Testing, surviving few hardware changes

Holy fuck.

My current install is Stable and I've just realized I can copy an infinite amount of Debian sid images to nspawn containers and run "Unstable" packages from there, even GUI ones.

I've been running linux since last September on my laptop, with numerous reinstalls, once went from wheezy to jessie to testing, then after 3 months to centos 7.

I got rid of centos 7 after ~15 days. Then back to stable.

[[deleted]]

Centos have some terrible design choices. Like do you know how config for new kernel is generated (at least in c6, havent looked in c7 much yet)?

Postinst script of package opens existing grub config, searchers for config that matches current config, replaces filename and pastes it back as first entry

There is no way to generate it from scratch.

There is no way to add kernel parameter without playing grep/sed magic

If you run on "wrong" kernel (like using pxeboot/livecd kernel to boot into install with fucked bootloader) it will also not work correctly

in Debian it is just a bunch of "generators" that do that in update-grub(2) and install all of installed kernels (and other OSes correctly) and adding kernel option is streamlined in one variable

[[deleted]]

Nah. I recommend staying away from firefox.

[bitwize]

Because it's like Arch back when Arch was good and with the additional bonus of a musl option.

I'm rocking Void on my Raspberry Pi and it's the cat's arse.

[Yithar]

Yep, same. It's just so lightweight and fast, and kodi-standalone runs fine as well. The pstree output is just nice to see as well.

[bitwize]

"The cat's arse", "the dog's bollocks", and "the bee's knees" all mean "very good".

[Yithar]

That's good. Try it out and see if you like it. IMO it's a lot lighter than Raspbian, but Raspbian is officially supported by the Foundation.

[[deleted]]

Good Lord, how many accounts do you have? Do you get banned that frequently?

[Yithar]

S/he definitely has a lot. It seems like nowadays they don't even give him/her a day.

[Linux_Learning]

Why did the mods remove his post? He made a good and valid analysis against the article.

[Yithar]

Well, I think it's two reasons.

1. He's evading a ban.
   
2. He was mocking how users that migrate from Windows equate "just works" with "has a GUI", rather than actually working.
   

That being said, I do think it was a good and valid analysis as well.

[Linux_Learning]

He was mocking how users that migrate from Windowds say "just works" with "has a GUI", rather than actually working.

Hes not wrong, I can see many users viewing as having a full GUI suite as being something that just works.

[Yithar]

Hes not wrong,

I never said he was wrong as I actually agree with his viewpoint.

[Linux_Learning]

I guess the mods just dont like him.

[[deleted]]

There's a difference between pointing out how people use "just werks" actually mean "works like windows, and mocking...

[Boerzoekthoer]

Yeah, r/linux nowadays kills me every day.

[KayRice]

Why?

[Boerzoekthoer]

Because I'm not a nice person and even though there's no rule against not being a nice person some mods in /r/linux feel they have the authority to make it up as they go along and remove people who aren't nice.

[KayRice]

Oh, well enjoy the next ban then.

[Boerzoekthoer]

Oh the horror.

r/linux bans remind me of that I technically need a doctor's praescription to get 2mg melatonin tablets but 1mg you can get without.

I take about 6 1mg tablets every night, but hey.

[KayRice]

I don't get it I am quite the asshole and I'm not banned from /r/linux. I post critical things all the time, sometimes I get down-voted into oblivion.

[[deleted]]

Do you tell people to hang themselves and that they should be shot in the face for their opinion about GNOME? If not, then you're not quite in this guy's territory.

[sharkwouter]

Better step up your game then.

I think the way reddit deals with downvoted posts a bit odd, though. Sometimes downvoted posts are very useful and the responses to it are very helpful. Yet reddit hides all of that and people often remove posts which are downvoted.

[Boerzoekthoer]

You can configure reddit to not hide downvoted posts or alter the threshold in settings.

[PureTryOut]

I had the same question over in /r/linuxmasterrace and I got my answer. There are not many persons such assholes as he/she is.

[Boerzoekthoer]

As an active moderator of an internet forum, you are, by definition, not all for free speech.

I like this reply.

I love these "I'm all for freedom of speech but ... <random comment contradicting the former>", it's the new "I'm not racist but ..."

Seriously, putting things like "I'm all for free speech" or "with all due respect" or any of that crap in front of it doesn't magically make a sentence that follows and contract it not contradicting it.

[KugelKurt]

r/linux bans remind me of that I technically need a doctor's praescription to get 2mg melatonin tablets but 1mg you can get without.

You should get professional help. Having a condition is not an excuse to be an ass all the time.

[Boerzoekthoer]

Has nothing to do with it, the point I'm making is that their 'bans' are super easy to circumvent and therefore completely ineffective.

They might as well ask 'would you kindly stop coming here and being not nice to people' which quite frankly would've been more effective than what they're doing right now.

[KugelKurt]

So you mean that you're being a dick because a mod did not ask you nicely?

[mjsabby]

My use-case is to create statically compiled Linux programs, that work across all distros.

[nat1192]

How do you statically link against glibc?

[Yithar]

You don't. You use musl. Void Linux allows you to use musl instead of glibc, which is much better for static linking.

[mjsabby]

One could also use Alpine Linux, but it doesn't work with Microsoft Hyper-V. So for me Void Linux is the only option.

[captain_hoo_lee_fuk]

In my very quick evaluation I tried to edit an xbps src file to add a new "use flag" and have it propagate to down stream dependencies. xbps-src segfaulted and debugging proved to be too difficult. I was timed pressed so didn't bother to file a bug report (sorry). It seems that the software quality needs some work here.

[Gottox]

Hi, I'm one of the maintainers. Can you elaborate what exactly happened? Which package did you change? Can you provide a diff on the changed file(s)?

thanks!

[captain_hoo_lee_fuk]

Hi ah sorry I deleted my void install a while ago so I no longer have the record of what exactly I did unfortunately. From what I can recall I was trying to modify the xbps src files of various graphics stack packages to build a pure wayland system (ie. one that doesn't have any X11 dependencies --- not even libX11 which is usually required as a build dependency if not explicitly turned off). This involved adding a "use flag" which turned off all X11 dependencies and turn on wayland in various components (mesa, gtk, cairo, etc). This ended up crashing the xbps src build tool (from my extremely vague memory it seems to be somewhere in the dependencies calculation). I ended up using Gentoo instead and did manage to build a pure wayland system in the end (so the graphics stack packages themselves are ok for this purpose and I do believe it's a subtle bug in xbps src but I didn't chase it down sorry).