Linus: “I no longer feel like I can trust ‘init’ to do the sane thing”(lkml.org)
lkml.org
Linus: “I no longer feel like I can trust ‘init’ to do the sane thing”
https://lkml.org/lkml/2017/7/6/577
346 comments
Yes, he specifically goes out of his way to refer to init as generically as possible. But then drops this line at the end of the post:
And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why.
It's not hard to understand what he meant and for some of us it's articles like this on HN which give an opportunity to talk about systemd without being off topic.
IMO the take away from the article is that systemd has become enough of a moving part that it would be unwise to rely on it for default anything. Maybe I read it wrong but there's my take on the technical argument against using init to set default limits on processes. There are already defaults in the kernel so use them and allow an override for admins that need one.
And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why.
It's not hard to understand what he meant and for some of us it's articles like this on HN which give an opportunity to talk about systemd without being off topic.
IMO the take away from the article is that systemd has become enough of a moving part that it would be unwise to rely on it for default anything. Maybe I read it wrong but there's my take on the technical argument against using init to set default limits on processes. There are already defaults in the kernel so use them and allow an override for admins that need one.
It's impossible to misinterpret that he's referencing systemd, but that's not the point of his post. He's saying, "Kernel over here, Init over there, One way transaction". You're talking about whether Systemd is qualified to be init. He's talking about whether the Kernel-side or Init-side is responsible for defining a given value. He declares his bias clearly (trusts Kernel, doesn't trust Init, especially doesn't trust Init via Systemd) and then makes his point. I'm just deeply saddened that literally two comments out of a hundred bothered to discuss his point, that divide, at all.
So talk about that divide. Clearly a lot of people care a lot about Sysemd and want to talk about it. It's even the title of the post.
Complaining that people aren't having the conversation you want to have is just weird. Start the conversation you want instead of complaining that others are failing to have it. No one is obliged to hold the conversation you want.
Complaining that people aren't having the conversation you want to have is just weird. Start the conversation you want instead of complaining that others are failing to have it. No one is obliged to hold the conversation you want.
I came here to learn about a technical issue that HN felt worthy of the front page, because I'm not certain how I feel about systemd yet. I ended up learning what a bunch of people feel about systemd, but nothing about whether this is a reasonable divide strategy, or whether anyone has any arguments to counter his, or .. anything whatsoever. I'm glad the thread benefited the wellness of the community by providing an outlet for unresolved rage, but y'all missed a key opportunity here to consider a new semantic about the Kernel-Init(Systemd) interaction before it's fixed into stone by commits or whatever.
Was the title different when you clicked on this story? If you clicked a story about how Linus no longer trusts init and expected some deep discussion of init/kernel separation, I kind of feel like you were destined to be disappointed. The topic was clearly Linus's distrust of init, not architectural purity.
The suckless community maintains a page about SystemD's flaws (Why it "sucks"), and what they think an init system should do, and what it shouldn't. It's a relatively concise summary of the position of the people opposed to SystemD: http://suckless.org/sucks/systemd
So far I haven't found a page like this by the SystemD advocates. I haven't really found much of an argument by them, to be quite honest. It would be nice to hear of one, of course.
So far I haven't found a page like this by the SystemD advocates. I haven't really found much of an argument by them, to be quite honest. It would be nice to hear of one, of course.
Yes, exactly. Great post.
> for some of us it's articles like this on HN which give an opportunity to talk about systemd without being off topic.
I would argue it is off topic because it's barely relevant to the submitted link. Just post "Tell HN: systemd sucks" and you can talk systemd all day long.
You could even include some actually real and concrete concerns, like trying to bloat the kernel with some linux-on-teh-desktopz IPC which will probably be replaced by the next big thing by 2025, bundling some weird syslog replacement, bundling a half-assed DNS cache (it was originally vulnerable to spoofed answers right off the bat, besides the recent remote code execution oopsie), polluting dmesg with systemd log messages, asking the kernel to workaround systemd crashing when the kernel is booted with debug output, Poettering's dismissal of the UEFI bricking fiasco, the recent failure to drop privileges on usernames starting with 0, ...
You guys behave as if some overblown pretext were needed to flame systemd :p
I would argue it is off topic because it's barely relevant to the submitted link. Just post "Tell HN: systemd sucks" and you can talk systemd all day long.
You could even include some actually real and concrete concerns, like trying to bloat the kernel with some linux-on-teh-desktopz IPC which will probably be replaced by the next big thing by 2025, bundling some weird syslog replacement, bundling a half-assed DNS cache (it was originally vulnerable to spoofed answers right off the bat, besides the recent remote code execution oopsie), polluting dmesg with systemd log messages, asking the kernel to workaround systemd crashing when the kernel is booted with debug output, Poettering's dismissal of the UEFI bricking fiasco, the recent failure to drop privileges on usernames starting with 0, ...
You guys behave as if some overblown pretext were needed to flame systemd :p
I don't understand your complaint, especially given that your last two links are more discussion about problems with systemd instead of the divide you think is the interesting point.
I apologize, I'm not sure how I could improve it to make it more clear.
It's really confusing that you complained that no one is discussing the architectural decisions separating kernel from init but then you link to a comment that discusses "1) systemd's bad programming taste and complexity, and 2) Lennart Poettering's inability to admit when he is wrong." Your (second) link is 75% about the interpersonal failings of Poettering and 0% about the separation of kernel and init.
Also with respect to your comment: "I am disgusted to report that ... the 2 above-linked comments are the sum total of actual replies to the content Linus was trying to discuss." Linus did not post this here and in no way was attempting to discuss this with the HN crowd. cnst posted this with the intention of discussing Linus's apparent distrust of init.
Also with respect to your comment: "I am disgusted to report that ... the 2 above-linked comments are the sum total of actual replies to the content Linus was trying to discuss." Linus did not post this here and in no way was attempting to discuss this with the HN crowd. cnst posted this with the intention of discussing Linus's apparent distrust of init.
Ted Ts'o, the Linux ext2/3/4 filesystem developer, posted this two days ago at G+ as well. Interesting discussion, particularly about 1) systemd's bad programming taste and complexity, and 2) Lennart Poettering's inability to admit when he is wrong.
"For me a lot of "good taste" is about adding complexity when it's needed, and avoiding it when it's not needed. And if you do have complexity, making sure you have the tools so you can debug things when they break. And for me one of the things that I don't like about systemd is that it has added a lot of complexity, and when it breaks, trying to debug it can be almost impossible."
Also:
"Heck, I don't even I want to file bug reports, just so I can get abusive messages from Lennart. At least when Linus flames me, it's because I did something wrong which hurts users and which I d*mned well should have known better, given my years of experience in the community. Lennart just flames you because you're wrong, and he's right. By definition."
And:
"The high bit, in my opinion, is "not being able to admit you are wrong". If someone (such as Lennart) is always right, then it's impossible to have a technical discussion in a post-mortem to avoid similar problems in the future. In a company, if there are personnel issues like that, you can escalate to the person's manager, or use other mechanisms. In the open source world, all you can do is route around the damage. Whether you call the inability for someone to admit that he or she has contributed to the problem a "lie" or just that they were "mistaken" is really beside the point as far as I'm concerned."
https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
"For me a lot of "good taste" is about adding complexity when it's needed, and avoiding it when it's not needed. And if you do have complexity, making sure you have the tools so you can debug things when they break. And for me one of the things that I don't like about systemd is that it has added a lot of complexity, and when it breaks, trying to debug it can be almost impossible."
Also:
"Heck, I don't even I want to file bug reports, just so I can get abusive messages from Lennart. At least when Linus flames me, it's because I did something wrong which hurts users and which I d*mned well should have known better, given my years of experience in the community. Lennart just flames you because you're wrong, and he's right. By definition."
And:
"The high bit, in my opinion, is "not being able to admit you are wrong". If someone (such as Lennart) is always right, then it's impossible to have a technical discussion in a post-mortem to avoid similar problems in the future. In a company, if there are personnel issues like that, you can escalate to the person's manager, or use other mechanisms. In the open source world, all you can do is route around the damage. Whether you call the inability for someone to admit that he or she has contributed to the problem a "lie" or just that they were "mistaken" is really beside the point as far as I'm concerned."
https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
Ts'o strikes me as damn close to Torvalds in attitudes. The guy have been with the kernel for almost as long as Torvalds himself, happily developing EXT version after EXT version for it.
The problem is with more recent people, that seem to be more "american" their approach. Always looking to climb the ranks and find new domains of development to undertake rather than stick with one area and become deeply proficient.
The problem is with more recent people, that seem to be more "american" their approach. Always looking to climb the ranks and find new domains of development to undertake rather than stick with one area and become deeply proficient.
systemd is a mess. A while ago I tried writing a script for CD ripping that ran when udev detected a music CD in the optical drive, ripped the CD, then ejected the disk.
This kept failing. It turned out to be systemd having a hardcoded timeout of something like 30 seconds on any process launched by udev, that couldn't be changed without recompiling it from source, or having it fork off some other process group that lacked this limitation.
From what I can tell, systemd has some of the worst sort of developer myopia, where whole swaths of legitimate use cases are actively destroyed.
This kept failing. It turned out to be systemd having a hardcoded timeout of something like 30 seconds on any process launched by udev, that couldn't be changed without recompiling it from source, or having it fork off some other process group that lacked this limitation.
From what I can tell, systemd has some of the worst sort of developer myopia, where whole swaths of legitimate use cases are actively destroyed.
It sounds like you're blocking udev while your script executes, and instead you should start a service from your udev script and then exit. For example, see systemd-run(1).
> ...where whole swaths of legitimate use cases are actively destroyed.
Your use case is fine. Your implementation doesn't fit with udev's design; that's all.
> ...where whole swaths of legitimate use cases are actively destroyed.
Your use case is fine. Your implementation doesn't fit with udev's design; that's all.
I was having udev starting a separate ripping script as a background process, and it worked on pre-systemd udev systems.
systemd kills the entire udev process tree (all children) including the ripping script after 30 seconds.
systemd kills the entire udev process tree (all children) including the ripping script after 30 seconds.
Actually, it's udevd itself doing that. A regular child-killing rampage is built into its main loop. To avoid it, one must arrange to not run the desired program directly, but rather to make udevd activate another service that in turn runs the desired program.
To fix this, perhaps it'll need to fork and detach the session, as per the standard daemonisation sequence. c.f. http://www.itp.uzh.ch/~dpotter/howto/daemonize
systemd's session killing stuff will happily kill anything that's been daemonised by the standard approach :(
And I am fairly sure that this design predates systemd by several years.
[deleted]
[deleted]
Making too many assumptions about the user environment is not smart. Then you start putting constraints and becoming defensive when these assumptions are questioned. This is becoming a pattern for systemd as is blaming everyone else. [1]
Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone.
For instance if you have too many network interfaces and naming is a problem then switch on predictable network names which btw is anything but predictable for human beings and let the 97% who don't carry on.
12 digit random names are simply not predictable or better for human beings than eth0, wlan0? If there is a problem predictable network names is not the solution.
Similarly if you need binary logging and an audit trail then turn on binary logging but don't impose it on everyone else.
Its time to move beyond silly accusations of 'hate' etc every time there is a discussion about systemd because at the moment it just serves to deflect criticism and avoid accountability for questionable decisions.
[1] https://github.com/systemd/systemd/issues/2407
Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone.
For instance if you have too many network interfaces and naming is a problem then switch on predictable network names which btw is anything but predictable for human beings and let the 97% who don't carry on.
12 digit random names are simply not predictable or better for human beings than eth0, wlan0? If there is a problem predictable network names is not the solution.
Similarly if you need binary logging and an audit trail then turn on binary logging but don't impose it on everyone else.
Its time to move beyond silly accusations of 'hate' etc every time there is a discussion about systemd because at the moment it just serves to deflect criticism and avoid accountability for questionable decisions.
[1] https://github.com/systemd/systemd/issues/2407
Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone.
Indeed. Even if I have multiple ethernet interfaces, I'd prefer to map a MAC address to eth[0-9] myself. But most machines only have one ethernet interface and one WiFi interface anyway.
These things pop up all over the place. E.g.: why would I want to have NetworkManager on a server, which never switch networks and need to set up a VPN connection? Why do I need firewalld on a server? I rarely need a zone-based firewall on my laptop (probably like most users, I just block all incoming traffic), let alone a server.
Layer upon layer is piled to solve hypothetical situations that do not arise for > 90% of the population.
(I do like systemd as a service manager, but systemd and the surrounding ecosystem has made it terribly difficult to understand and debug UNIX systems.)
Indeed. Even if I have multiple ethernet interfaces, I'd prefer to map a MAC address to eth[0-9] myself. But most machines only have one ethernet interface and one WiFi interface anyway.
These things pop up all over the place. E.g.: why would I want to have NetworkManager on a server, which never switch networks and need to set up a VPN connection? Why do I need firewalld on a server? I rarely need a zone-based firewall on my laptop (probably like most users, I just block all incoming traffic), let alone a server.
Layer upon layer is piled to solve hypothetical situations that do not arise for > 90% of the population.
(I do like systemd as a service manager, but systemd and the surrounding ecosystem has made it terribly difficult to understand and debug UNIX systems.)
Most of my machines have more than 1 wired interface, and guess what? Those predictable names have caused me way more problems than they ever fixed. And those problems have always been harder to fix. Just stable names, like udev used to do were enough for nearly everything.
> why would I want to have NetworkManager on a server, which never switch networks and need to set up a VPN connection?
It's funnier because NetworkManager must wait for the filesystems to be mounted, but then, networked filesystems (that are, those ones, important there) need a functioning network that NetworkManager postpones to after it's up.
> why would I want to have NetworkManager on a server, which never switch networks and need to set up a VPN connection?
It's funnier because NetworkManager must wait for the filesystems to be mounted, but then, networked filesystems (that are, those ones, important there) need a functioning network that NetworkManager postpones to after it's up.
why would I want [insert a systemd design decision]
Because systemd wants to be The One Ring of Linux, and tries to be all things to all systems and all people.
Because systemd wants to be The One Ring of Linux, and tries to be all things to all systems and all people.
Another example of this type of defensive response to bug reports:
https://github.com/systemd/systemd/issues/6237
systemd runs services as uid 0 because it can't parse a valid user name (of a non-uid 0 user). Of course it's not systemd's fault. It's not even a problem at all.
https://github.com/systemd/systemd/issues/6237
systemd runs services as uid 0 because it can't parse a valid user name (of a non-uid 0 user). Of course it's not systemd's fault. It's not even a problem at all.
Poettering has a strong bias towards making sure bugs get fixed in the right layer, instead of creating forever-living-workarounds in higher layers.
In the bug you reported, however, I noticed that he pushed a commit to work around the underlying bug, so he's not completely impractical.
In the bug you reported, however, I noticed that he pushed a commit to work around the underlying bug, so he's not completely impractical.
Unless he can introduce a layer he controls. Observe that rather than work with Alsa to find some way to handle transient audio devices, he introduces Pulseaudio.
Linus has the proverbial moral authority to bootstrap an init system and the technical skill to pull it off. Amusingly, this strikes me something like the chairman of the Federal reserve hinting that he thinks interest rates are too high. Hopefully, the systemd developers will take notice and clean up some of their act. (Not to insinuate anything. They have widely known problems in playing nice with other projects, taking feedback, etc.)
waits patiently for Linus to get fed up with ___ enough to write it himself
dies
dies
I don't really think he would, will, or wants to. But that he could, and actually might if he begins to feel that systemd hurts Linux, might create some positive pressure on the systemd developers. That's exactly the thing, like the fed. They have enough power that an implied threat can fix things (sometimes to some extent) without them actually taking any action.
I mean, he wrote git for that reason.
At this point, less likely on systemd devs than those who employ them (Red Hat) and distro maintainers (Debian, Ubuntu, Fedora, Gentoo, Arch, etc.).
Actually Gentoo still uses sysvinit by default, which is one of the reasons I like it. They also maintain a fork of udev (eudev) that doesn't require systemd.
OpenRC is default, but yes.
OpenRC is a collection of init scripts, not the PID 1 /sbin/init binary AFAIK.
This is true, OpenRC depends on sysvinit to run PID 1, but given the comparison to systemd we have to ignore the (unixy) distinction between OpenRC and sysvinit since systemd has eaten everything >_<.
> Gentoo still uses sysvinit by default
> OpenRC is default
> we have to ignore the (unixy) distinction between OpenRC and sysvinit
Nice try :)
> OpenRC is default
> we have to ignore the (unixy) distinction between OpenRC and sysvinit
Nice try :)
[deleted]
They [systemd] shouldn't piss him off too much. He will sit down for a week, come out with his own init system which will take over the world. /s but not entirely :)
Like what happened to git in the past, will Linus write a new init himself this time?
Considering the broad range of such softwares that already exist, written by people such as Felix von Leitner, Gerrit Pape, Laurent Bercot, and so on, why do you think that Linus Torvalds is the person to write one? Or needs to write one?
* http://blog.darknedgy.net/technology/2015/09/05/0/
* http://skarnet.org/software/s6-linux-init/
* http://smarden.org/runit/runit-init.8.html
* http://www.fefe.de/minit/
* https://jdebp.eu/Softwares/nosh/guide/system-manager.html
* http://blog.darknedgy.net/technology/2015/09/05/0/
* http://skarnet.org/software/s6-linux-init/
* http://smarden.org/runit/runit-init.8.html
* http://www.fefe.de/minit/
* https://jdebp.eu/Softwares/nosh/guide/system-manager.html
There were many version controls systems before Git came along. He doesn't need to write it. But if he wants, he has the technical chops to do a damn good job of it.
Few did what Git does, take multiple forks and merge them.
Most that came before were good at forking, but not so good at merging.
Most that came before were good at forking, but not so good at merging.
[deleted]
I sure hope so... I've had to revert several Ubuntu machines to upstart and I have to "sudo service restart network-manager" 3 of 10 times my primary desktop starts (so I scripted it..)
Based solely on my personal experience (which is mainly Ubuntu desktop and server) Systemd is a hot broken mess. To me it feels like good goals with poor implementation.
I actually miss how simple init used to be... I understand the motivations for improving it, but if I had to choose ease of grokability or better boot times, I'll take grok every time.
Based solely on my personal experience (which is mainly Ubuntu desktop and server) Systemd is a hot broken mess. To me it feels like good goals with poor implementation.
I actually miss how simple init used to be... I understand the motivations for improving it, but if I had to choose ease of grokability or better boot times, I'll take grok every time.
Given how many things systemd does and how this set of things is increasing with every version (lately including dhcp and ntp client, for example), it feels to me that the goal is to bring as much things under systemd (and thus Red Hat) as possible.
It's a sad day that the biggest Linux company is doing Embrace, Extend, Extinguish, but I guess I shouldn't have expected more from RH.
It's a sad day that the biggest Linux company is doing Embrace, Extend, Extinguish, but I guess I shouldn't have expected more from RH.
[deleted]
Linus wrote git because BitKeeper was taken away from him due to the Andrew Tridgell incident, not because he disliked BitKeeper; he didn't even mind that it was closed source.
Decided to google about this...
Found this article: https://www.pcworld.idg.com.au/article/129776/after_controve...
I wonder, how many people reading that article would predict the rise of stuff like GitHub and GitLab and the success of Git to the point of crushing CVS and making SVN decline in popularity?
Found this article: https://www.pcworld.idg.com.au/article/129776/after_controve...
I wonder, how many people reading that article would predict the rise of stuff like GitHub and GitLab and the success of Git to the point of crushing CVS and making SVN decline in popularity?
> [...] the success of Git to the point of crushing CVS and making SVN decline in popularity?
CVS was already on the way out even prior to git's inception, because of SVN. SVN's unofficial goal is essentially to be a better CVS, and it was a great success on that front. However, IMO its success made its core dev team complacent.
For example, one complaint I hear often of SVN is that it's slow. Go use CVS for a week -- and I mean not just doing a checkout and make a few commits, but merge, diff, switch branch, add / remove / rename sub-trees, etc.; bonus points for involving >3 people trying to do the same simultaneously -- then try and tell me SVN is slow.
Nonetheless, SVN is not fast, but it's fast enough when there was no viable competition. Then git came along, and even the staunchest opponents must conceded that it's lightning quick. And people will tolerate a lot of BS from a tool if it does the job and does it quickly.
SVN's performance has improved significantly since the 1.4.x days, around the time when git first made its appearance. No doubt some improvements were on the roadmap regardless, but surely having competition lit a fire in getting them out the door.
CVS was already on the way out even prior to git's inception, because of SVN. SVN's unofficial goal is essentially to be a better CVS, and it was a great success on that front. However, IMO its success made its core dev team complacent.
For example, one complaint I hear often of SVN is that it's slow. Go use CVS for a week -- and I mean not just doing a checkout and make a few commits, but merge, diff, switch branch, add / remove / rename sub-trees, etc.; bonus points for involving >3 people trying to do the same simultaneously -- then try and tell me SVN is slow.
Nonetheless, SVN is not fast, but it's fast enough when there was no viable competition. Then git came along, and even the staunchest opponents must conceded that it's lightning quick. And people will tolerate a lot of BS from a tool if it does the job and does it quickly.
SVN's performance has improved significantly since the 1.4.x days, around the time when git first made its appearance. No doubt some improvements were on the roadmap regardless, but surely having competition lit a fire in getting them out the door.
Considering the architecture of the git and fundamental tradeoffs that you make after deciding on: content addressability, internal data representation, tracking content instead of files, taking snapshot of the content of entire commit as opposed to just its diff - the only avoidable BS people get from git is its "porcelain" CLI. There have been many tools tools to address it (like easygit).
Git is extremely well engineered, it's just that its UI is not conducive to learning it.
Git is extremely well engineered, it's just that its UI is not conducive to learning it.
For me, there are numerous advantages of git over svn:
1) git log uses a pager by default and is lightning fast compared to svn log which needs a server connection and is not paged
2) the "current commit id" is the same across all directories in a repo, while in svn every directory can be at a different revision
3) side benefit of #2, a "git status" in a subdirectory also shows the status of files in upper-level paths of the repo
4) backup-ability: every git checkout is a full clone, so if the server is down, or you're on the road without wifi, you can still work even with history
5) partial commits (git add/commit -p) is a godsend, I don't get why svn still hasn't implemented this
6) the tooling around hosting is way better - websvn is a laugh compared to gitweb and even more so compared to gitlab/bitbucket/github
7) support for branches
1) git log uses a pager by default and is lightning fast compared to svn log which needs a server connection and is not paged
2) the "current commit id" is the same across all directories in a repo, while in svn every directory can be at a different revision
3) side benefit of #2, a "git status" in a subdirectory also shows the status of files in upper-level paths of the repo
4) backup-ability: every git checkout is a full clone, so if the server is down, or you're on the road without wifi, you can still work even with history
5) partial commits (git add/commit -p) is a godsend, I don't get why svn still hasn't implemented this
6) the tooling around hosting is way better - websvn is a laugh compared to gitweb and even more so compared to gitlab/bitbucket/github
7) support for branches
CVS was already being kicked out the door at that time by SVN. A lot of people looked at Git as a potential replacement for SVN (at least, I did. Took several years for me to really 'get' it, though. I'm not sure even today I completely 'get' Git: there are a lot of possible workflows).
I didn't dream of it in terms of GitHub.
I didn't dream of it in terms of GitHub.
> I'm not sure even today I completely 'get' Git: there are a lot of possible workflows
In my experience most people are using git with a svn workflow. They use github (gitlab, or something internal to the company) as the central server, and work only from the central server. Make github speak svn, and alias all the git commands to svn and they couldn't tell the difference.
In my experience most people are using git with a svn workflow. They use github (gitlab, or something internal to the company) as the central server, and work only from the central server. Make github speak svn, and alias all the git commands to svn and they couldn't tell the difference.
In my experience most people are using git with a svn workflow.
Yeap, but with a lot of local branches, and that makes a huge difference. Branching with SVN seriously sucked (although I've heard it's gotten better).
Yeap, but with a lot of local branches, and that makes a huge difference. Branching with SVN seriously sucked (although I've heard it's gotten better).
> making SVN decline in popularity
Depends on the business area. I am still using SVN in 100% of our customers.
And they don't seem keen to move into Git anytime soon.
Depends on the business area. I am still using SVN in 100% of our customers.
And they don't seem keen to move into Git anytime soon.
To misquote a saying about academia: "progress doesn't come with incumbents accepting new ideas, but with them dying-off".
[deleted]
Please no. That would be like if Gandalf wielded the One Ring. I've no doubt the result would be very functional and well engineered, but it would be awful in other ways.
That would be the best possible outcome.
Unlikely, for the same reason that he didn't tackle application packaging[0]: because writing a successful init system would necessitate either perfect backwards compatibility with shell scripts (next to impossible unless you're basically just copy-pasting sysvinit) or a massive coordination problem of rewriting the long tail of all the crazy different daemons people run to be compatible with the new system.
Git didn't have this problem because:
0. Version control systems don't have to interact with as many other software packages anyway (editor/shell integration is nice, but you can live without them and just run git directly from the command line);
1. There were compatibility layers that let Git talk to popular VCSes;
2. The fact that you use Git personally does not affect anyone else, obviating the bulk of the need for coordinated upgrades (there were stories, from before GitHub was a thing, of 'guerrilla Git users' in companies that officially used CVS).
These three things ensured that a relatively painless incremental upgrade path existed; in the case of init systems, it will be much harder to establish.
[0] He talks about it in https://www.youtube.com/watch?v=1Mg5_gxNXTo ; can't find the timestamp right now, but it's in the latter half of the video IIRC.
Git didn't have this problem because:
0. Version control systems don't have to interact with as many other software packages anyway (editor/shell integration is nice, but you can live without them and just run git directly from the command line);
1. There were compatibility layers that let Git talk to popular VCSes;
2. The fact that you use Git personally does not affect anyone else, obviating the bulk of the need for coordinated upgrades (there were stories, from before GitHub was a thing, of 'guerrilla Git users' in companies that officially used CVS).
These three things ensured that a relatively painless incremental upgrade path existed; in the case of init systems, it will be much harder to establish.
[0] He talks about it in https://www.youtube.com/watch?v=1Mg5_gxNXTo ; can't find the timestamp right now, but it's in the latter half of the video IIRC.
The quote here in the title is missing the vital context -- the full quote is
""And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why.""
""And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why.""
This reminds me of a relevant joke.
Systemd walks into a bar. It shoots the bar owner and proclaims itself to be the new owner. It then turns the bar into a farm, brewery and distillery, opens a casino, a freight rail line and an investment bank. Oh, and there's an init system thrown in there somewhere too.
Systemd walks into a bar. It shoots the bar owner and proclaims itself to be the new owner. It then turns the bar into a farm, brewery and distillery, opens a casino, a freight rail line and an investment bank. Oh, and there's an init system thrown in there somewhere too.
The internals of systemd are maybe not the best. But the UI is definitely easier to grasp than what existed previously.
I suspect that you are not aware of what actually did exist previously. Mewburn rc had short pretty much declarative service definition files. Upstart had declarative configuration too, as did InitNG. Launchd, Upstart, and Solaris SMF had the launchctl/initctl/svcadm concept. daemontools/runit/perp/s6 had universal logging of standard output/error. And so forth.
* http://blog.darknedgy.net/technology/2015/09/05/0/
* http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...
* http://blog.darknedgy.net/technology/2015/09/05/0/
* http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...
SMF without XML is gods init system.
It's so cleanly engineered, just like ZFS.. makes me sad that solaris died a death.
(Their package management was crap though tbh)
It's so cleanly engineered, just like ZFS.. makes me sad that solaris died a death.
(Their package management was crap though tbh)
Well illumos exists and people can always pick up SystemXVI and work on it.
* https://github.com/ServiceManager/ServiceManager/ (https://news.ycombinator.com/item?id=10212770)
* https://github.com/ServiceManager/ServiceManager/ (https://news.ycombinator.com/item?id=10212770)
I'm a sysadmin, I'm at the mercy of OS developers as to what I run on prod, and Solaris/IllumOS does not have the mindshare linux does.
I am certain that right now the choice of POSIX OS's at large companies such as mine is Debian or RHEL/CentOS. Smaller companies get away with ubuntu.
But nobody is making new infrastructure with IllumOS/Solaris. The most people will deviate is probably Free/OpenBSD.
I am certain that right now the choice of POSIX OS's at large companies such as mine is Debian or RHEL/CentOS. Smaller companies get away with ubuntu.
But nobody is making new infrastructure with IllumOS/Solaris. The most people will deviate is probably Free/OpenBSD.
Come back and say that when you've tried using systemctl to find out why a service is failing. 200-line zero-content error messages are what finally made me purge systemd from my machines.
The UI is easier? I'm gonna need you to explain this.
Declarative unit files are far easier to manage than fragile ad-hoc scripts.
Sysv init and rc-files are two different things. You can use whatever configuration system you like with sysv init, e.g openrc.
What systemd "solved" was already solved.
When you know this you understand that the motivation of the people behind systemd was not technical.
One of the top contributor of systemd is banned from the linux kernel because of bad coding. The other top contributor gave us the fiasco of pulseaudio. Both work at the same major company. Draw your own conclusions.
What systemd "solved" was already solved.
When you know this you understand that the motivation of the people behind systemd was not technical.
One of the top contributor of systemd is banned from the linux kernel because of bad coding. The other top contributor gave us the fiasco of pulseaudio. Both work at the same major company. Draw your own conclusions.
This is only a tiny piece of the experience though. What about journalctl? systemctl? etc? That stuff is alien vs tail -f or ./just/run/some.sh which works with everything _except_ systemd.
You can google how to do the equivalent to `tail -f /var/log/foo.log` in a minute.
What do you mean by ./just/run/some.sh?
What do you mean by ./just/run/some.sh?
> You can google how to do the equivalent to `tail -f /var/log/foo.log` in a minute.
Doesn't the fact that I have to google an alternative workflow for something that behaves consistently across pretty much all other software make its UI worse, at least in that regard? I get that maybe it's a justified trade-off, but that doesn't make the UI any better.
> What do you mean by ./just/run/some.sh?
I suppose just dumping an exec command into an executable file and call it a service.
Doesn't the fact that I have to google an alternative workflow for something that behaves consistently across pretty much all other software make its UI worse, at least in that regard? I get that maybe it's a justified trade-off, but that doesn't make the UI any better.
> What do you mean by ./just/run/some.sh?
I suppose just dumping an exec command into an executable file and call it a service.
You can use syslog in conjunction with the systemd journal. Some distributions come set up that way by default, and for the others you can just `apt-get install rsyslog` or whatever. When you have a syslog daemon installed, `tail -f` and everything else you're used to works exactly the same as before, you can pretend the journal doesn't even exist if you want. And if you don't have a syslog daemon installed... well, i don't know if that's really journalctl's fault, is it?
Sure, just throw in several extra steps, huge numbers of syscalls and make any admin add complexity to their systems. For a busy service, this is a performance issue that the systemd devs simply reject out of hand as "doing it wrong".
you can pretend the journal doesn't even exist if you want
Why must I have it if I don't need or want it? What is this, Windows?
Why must I have it if I don't need or want it? What is this, Windows?
That doesn't seem like an especially compelling argument. There are components of every ready-made operating system that you 'don't need or want'. I don't need or want an IPv6 stack, or debugfs, or half of the other features that come with most distributions' Linux kernels, and i don't need or want legacy bull shit like (d)ash and cpio and Python 2. But there they always are anyway, and i don't lose much sleep over that fact.
journald by default doesn't keep logs from the previous boot, which is extremely annoying. What's the point of having a logging system where you have to keep the old one around to read old logs? I've also had it seemingly not have any loglines for queried units when it should have; not sure what happened there.
Do you mean that logs are cleared on every boot? Because that isn't happening for me.
In one configuration, journald logs to an in-memory filesystem; in another, it logs to an on-disc filesystem; in a third, it tries on-disc and falls back to in-memory; in a fourth it does not save the log either in memory or on disc. Different distributions configure this differently.
This falsehood keeps popping up, and not only can't it be shown to be true, it's illogical.
Init scripts are static. They don't change, they aren't ad-hoc, they aren't fragile. All modern Sysv init script systems have static scripts which 'include' a basic key=value pairs of environment variables from a config file. Nobody modifies scripts, or at least, they should not be doing it, and don't need to.
Many init scripts on my system have timestamps from the year 2002, and this system was just installed. They don't change because they don't need to change.
OTOH, Declarative unit files are configuration management taken away from the configuration management system, adding complexity.
Init scripts are static. They don't change, they aren't ad-hoc, they aren't fragile. All modern Sysv init script systems have static scripts which 'include' a basic key=value pairs of environment variables from a config file. Nobody modifies scripts, or at least, they should not be doing it, and don't need to.
Many init scripts on my system have timestamps from the year 2002, and this system was just installed. They don't change because they don't need to change.
OTOH, Declarative unit files are configuration management taken away from the configuration management system, adding complexity.
Init scripts for a lot of system services sure.
Then you have your init scripts for random other services added by $USER, consider yourself lucky you haven't come across these.
Then you have your init scripts for random other services added by $USER, consider yourself lucky you haven't come across these.
until everyone starts working around flaws and missing features in the core. then the declarative files will be just a pile of hacks that in the end are just obfuscated ad-hoc script files.
and the scary part: we are not even fully there yet and it already reeks.
and the scary part: we are not even fully there yet and it already reeks.
In theory, a perfect bugless system that enforces a certain DSL upon sysadmins who won't have to maintain startup scripts is a good thing. A thing which systemd is not.
Aren't declarative unit fils an equivalent to windows .ini files ?
But the UI is definitely easier to grasp than what existed previously
Really? so you really think:
The systemd UI is a hot steaming pile of garbage that has made my day-to-day life on the CLI harder, not easier.
Really? so you really think:
systemctl <command> <service>
[optionally, some initsystem] <service> <command>
The systemd UI is a hot steaming pile of garbage that has made my day-to-day life on the CLI harder, not easier.
But I prefer running
systemctl status <service>
Maybe it is just me, but I don't really look for the init script to provide me a status on whatever it is that it inited. "OK" or "FAIL" is good enough in that specific context. It is the services' job to provide me with information on how it failed (or succeeded, or partially failed) through an easily and always accessible logging mechanism.
Different services have different failure modes with nuances that can never be generically captured by whatever means you chose to launch the service, in any kind of meaningful way. When a Database service stops serving data, my first though isn't "Lets see what the init system thinks", my first thought is "Lets see what I can find in various Database service logfiles" which will, 99.9% of the time, be something specific to the database service.
Inits' job in my view is "start this, and get out of the way". "Start this", and do logging, and do DNS/DHCP/manage-daemons/manage-restarts-on-fail/manage-the-fs/here-is-a-kitchen-sink/do-you-want-fries-with-that/oh-yes-and-here-is-NTP isn't what I am personally looking for in an init system, and - frankly - is a ridiculously stupid and idiotic approach from a server architecture perspective.
This isn't about the merits or lack thereof of binary logging, or the merits of whatever else systemd brought to the party. This is about needing tweezers, and being given a 500 function swiss army knife, where the other 499 functions get in the way of it being used as a very good tweezer.
Systemd is trying to be my default OS via the init system backdoor. I'll choose my own OS, thanks.
Different services have different failure modes with nuances that can never be generically captured by whatever means you chose to launch the service, in any kind of meaningful way. When a Database service stops serving data, my first though isn't "Lets see what the init system thinks", my first thought is "Lets see what I can find in various Database service logfiles" which will, 99.9% of the time, be something specific to the database service.
Inits' job in my view is "start this, and get out of the way". "Start this", and do logging, and do DNS/DHCP/manage-daemons/manage-restarts-on-fail/manage-the-fs/here-is-a-kitchen-sink/do-you-want-fries-with-that/oh-yes-and-here-is-NTP isn't what I am personally looking for in an init system, and - frankly - is a ridiculously stupid and idiotic approach from a server architecture perspective.
This isn't about the merits or lack thereof of binary logging, or the merits of whatever else systemd brought to the party. This is about needing tweezers, and being given a 500 function swiss army knife, where the other 499 functions get in the way of it being used as a very good tweezer.
Systemd is trying to be my default OS via the init system backdoor. I'll choose my own OS, thanks.
When a service stops my first thought will be check what ${init} says rather than a myriad of different inconsistent logs and badly written shell scripts say.
Then I'll check those logs if required.
Regarding DNS, DHCP et al, yes you have a point. Managing restarts on fail is a logical extension of init however.
Then I'll check those logs if required.
Regarding DNS, DHCP et al, yes you have a point. Managing restarts on fail is a logical extension of init however.
It's not exactly consistent. Different rows for different services (sometimes different for the same type of units), an inconsistent amount of logs included (maybe), the status is not reported consistently, whatever. It's mildly helpful for visual inspection, and that's it.
Example? It's far more consistent than the case switch for status in an init shell script (if it exists).
I still haven't found an easy to remember command which prints journal log for the past 10 minutes.
While dmesg did that by default.
While dmesg did that by default.
Just wanted to say that the issue is about automatically copying rlimits from the init processes to all processes executing setuid binaries - apparently Linus thinks that init could possibly apply some rlimits to itself for its own purposes which wouldn't necessarily be suitable for copying to any other random process.
IMO this idea with copying is in itself even less sane than init using rlimits on PID 1.
IMO this idea with copying is in itself even less sane than init using rlimits on PID 1.
Gee, such a surprise. Why didn't you speak out about it earlier, then?
I was thinking exactly this as I was reading the message. Linus was the one voice that could probably have prevented systemd from taking control. This comment strikes me as too little, too late. I just hope that the transition back to a saner solution, if it will ever happen, won't be too painful now. Or it could trigger mass migration out from Linux. I, for one, am living happily in BSD land by now.
Because he do not want to get involved with userspace bikesheding (beyond posting rants about insane defaults in his distro of choice).
He sees his domain beginning and ending with the kernel, and that's it.
Sadly certain people below him, that he trust deeply, are not so content (some even support Poettering and crew). And i fear the day he hand off the keys to the kernel to them.
He sees his domain beginning and ending with the kernel, and that's it.
Sadly certain people below him, that he trust deeply, are not so content (some even support Poettering and crew). And i fear the day he hand off the keys to the kernel to them.
Linus giving his opinion on userland is a far cry from bikeshedding though...
For those who can't stand lklm.org UI, here's the mail on spincs.net:
https://www.spinics.net/lists/kernel/msg2550717.html
https://www.spinics.net/lists/kernel/msg2550717.html
When so many think that something is wrong, maybe there is some truth about it...
If even the creator have concerns, man, that's not a joke!
If even the creator have concerns, man, that's not a joke!
I would assume this is about systemd. Personally my experience with it has been great - the occasional screw-ups (they did happen - something related to dbus made all systemctl commands fail until a reboot) were nothing compared to the time I gained not having to worry about prehistoric initscripts.
So while it isn't perfect, it's IMO a step in the right direction, if only by lowering the barrier to entry to actually using and managing the thing.
If you are worried about stability then you shouldn't rely on a single machine anyway. Personally I manage systemd screw-ups (though I haven't had one in production yet - all of them were on my personal machines while monkeying around with Archlinux) just like any other hardware failure - by making sure my app/service stays available even if I yank the power cord from the machine.
So while it isn't perfect, it's IMO a step in the right direction, if only by lowering the barrier to entry to actually using and managing the thing.
If you are worried about stability then you shouldn't rely on a single machine anyway. Personally I manage systemd screw-ups (though I haven't had one in production yet - all of them were on my personal machines while monkeying around with Archlinux) just like any other hardware failure - by making sure my app/service stays available even if I yank the power cord from the machine.
It seems obvious he is referring to systemd. I like systemd, but Linus hates it when people break userspace, and systemd has broken userspace a lot.
Poettering seems to take the advice of "release early and often" to heart and pushes things into widespread usage long before they're quite fully baked. PulseAudio was awful for years, and then it was good and we all stopped complaining about it. systemd was kinda crap for months after it became widespread...a ton of breakage, including in ways that were occasionally dangerous. We're lucky, I guess, that systemd didn't take as long as PulseAudio to stop sucking all the time (systemd still sucks some of the time, but what it replaced sucked a lot, too).
So, yeah, you can't break userspace if you want Linus on your team, and systemd has broken userspace now and then.
Poettering seems to take the advice of "release early and often" to heart and pushes things into widespread usage long before they're quite fully baked. PulseAudio was awful for years, and then it was good and we all stopped complaining about it. systemd was kinda crap for months after it became widespread...a ton of breakage, including in ways that were occasionally dangerous. We're lucky, I guess, that systemd didn't take as long as PulseAudio to stop sucking all the time (systemd still sucks some of the time, but what it replaced sucked a lot, too).
So, yeah, you can't break userspace if you want Linus on your team, and systemd has broken userspace now and then.
You seem to exist in a fictional universe where pulseaudio "got good" and doesn't suck. All these years later I have never seen that be the case. I think a much more likely explanation is that desktop Linux is less common since the rise of OS X in the "Unix-like developer machine" market so there are now fewer people noticing it sucks.
I believe the universe I exist in is real, but how would I know for sure?
Anyway, I haven't had to google about a pulseaudio problem in at least a few years. I've been using Linux as my primary desktop OS since 1995. I've hated Linux audio for most of that time, and I've broken it in every possible way. But, today, my Fedora system has sound that Just Works. I don't know how it Just Works (though I know it's pulseaudio), because I haven't had to learn...because it Just Works. It works for Steam games, it works for browser audio, it works for system notifications, it works for movies, it even works for audio and music software. It's pretty weird.
Anyway, from what I can tell, the bugs, misfeatures, poorly thought out implementation, etc. all got worked out somewhere along the way. It took a long time. But, it did get fixed.
Have you actually used it in the past couple of years?
Anyway, I haven't had to google about a pulseaudio problem in at least a few years. I've been using Linux as my primary desktop OS since 1995. I've hated Linux audio for most of that time, and I've broken it in every possible way. But, today, my Fedora system has sound that Just Works. I don't know how it Just Works (though I know it's pulseaudio), because I haven't had to learn...because it Just Works. It works for Steam games, it works for browser audio, it works for system notifications, it works for movies, it even works for audio and music software. It's pretty weird.
Anyway, from what I can tell, the bugs, misfeatures, poorly thought out implementation, etc. all got worked out somewhere along the way. It took a long time. But, it did get fixed.
Have you actually used it in the past couple of years?
The main problem with PulseAudio is that it "just works" for the majority of users, but then it fails randomly, unpredictably, unrepeatably and with no indication of what is going wrong, and most of the time you get a "uh, works for me". This is a kind of experience that I was used to expect in Windows, not in Linux.
Just two more random examples:
RPi 3, audio would hang randomly when opening a new process using audio from another using audio. The solution would be to either play an audio sample from the command line to unclog the audio system, or uninstall PulseAudio.
Ubuntu 16.04. Rewinding the video while using mplayer could cause the audio to play at a faster rate. Again uninstalling PulseAudio would solve the problem.
Just two more random examples:
RPi 3, audio would hang randomly when opening a new process using audio from another using audio. The solution would be to either play an audio sample from the command line to unclog the audio system, or uninstall PulseAudio.
Ubuntu 16.04. Rewinding the video while using mplayer could cause the audio to play at a faster rate. Again uninstalling PulseAudio would solve the problem.
yeah, future version of PA should had one command 'uninstall'; all linux users would use PA with joy now.
I often feared PA, and something in ALSA (I almost know zero about linux audio stack) made it a zero effort / 99% working thing that matched what I want for audio, that is a no sweat thing that just push sound. I can live without multi room networked audio, but having local audio crash randomly is too much a PITA. Feels like having lisp macros on top of VBA.
That said I wish we could find a better solution. Something between ALSA and PA. Also PA demands quality driver, IIRC Lennard told he cannot get blamed for that, it's a bit like GPUs in a way; and I wish we'd have open hardware audio chip that were simple and not lying.
I often feared PA, and something in ALSA (I almost know zero about linux audio stack) made it a zero effort / 99% working thing that matched what I want for audio, that is a no sweat thing that just push sound. I can live without multi room networked audio, but having local audio crash randomly is too much a PITA. Feels like having lisp macros on top of VBA.
That said I wish we could find a better solution. Something between ALSA and PA. Also PA demands quality driver, IIRC Lennard told he cannot get blamed for that, it's a bit like GPUs in a way; and I wish we'd have open hardware audio chip that were simple and not lying.
I don't know why you're downvoted.
One thing though: if Lennard blames the drivers, he should at least implement some fallback mechanism to use when a feature is unavailable or can't be relied on to work reliably. Honestly, if with the same drivers ALSA works fine and PA doesn't, it's hard to blame the drivers.
I think it's a bit more subtle than that. PA asks more from the hardware to do more than ALSA (sampling capabilities, and latency), if the drivers report fake numbers to ALSA it might work fine for its limited use case, while it fucks PA logic entirely.
That said a default fallback would be so good. I can't stop thinking that LP writes things for his own world and leave it there when he's "satisfied" with it; even if it means shit for the rest. Which means the issue is that he shouldn't be in charge of socially impactful components.
That said a default fallback would be so good. I can't stop thinking that LP writes things for his own world and leave it there when he's "satisfied" with it; even if it means shit for the rest. Which means the issue is that he shouldn't be in charge of socially impactful components.
> I can't stop thinking that LP writes things for his own world and leave it there when he's "satisfied" with it; even if it means shit for the rest. Which means the issue is that he shouldn't be in charge of socially impactful components.
Unless you have examples of solid patches fixing these kind of problems that he rejected, this is a significantly unfair statement.
Unless you have examples of solid patches fixing these kind of problems that he rejected, this is a significantly unfair statement.
Fair point, he's not the only coder in his projects, and maybe it's unfair social response that influence me, but his projects always rub people the wrong way, even though they carry brilliant useful ideas. Also if the overall design impede fixing without too much hassle ..
He seems to suffer from massive ego. He always assumes that if his stuff is failing, it’s somehow someone else’s fault, and refuses to acknowledge fault even when evidence is presented.
At least that’s what’s been apparent to me from the things that I’ve read by him and about him.
At least that’s what’s been apparent to me from the things that I’ve read by him and about him.
He often has a lot of good points, but it's not enough when assuming a pivotal role in society. You cannot just be right 60% of the time, because 40% people leftover is far too much. It's saddenning for instance, PA had valueable goals, but if the design assumes hardware that doesn't exist (exagerating) then it's not a good fit for a standard audio stack.
And I'm not sure it's really ego.. I'd rate him at about 0.07geohots.
And I'm not sure it's really ego.. I'd rate him at about 0.07geohots.
I did try to use it and discovered that it's impossible to configure mpd to run as a system service and be able to play sound while also allowing desktop applications to play sound. I forget all the details, but the way I figured out how to get sound to do what I wanted was to enable alsa dmix and to pipe everything possible through dmix, using pulseaudio only for the one or two essential apps that insist on it.
Funny, I just did that yesterday. I was reconfiguring my mpd server and I saw it was configured to use alsa (which, incidentally broke my sound occasionally). I set it up to use Pulseaudio and now I can listen to mpd server while listening to deezer.com that runs through browser while making a skype call on the same machine (not that I'd want to do it, anyway).
Also, alsa+dmix does everything pulseaudio does (for all my use cases) without having to run an extra daemon / abstraction layer.
> for all my use cases
Exactly. Does it support redirecting audio streams to another machine on the same network? That's a vital feature in our hackspace, where everyone can send audio to the room speakers via PA, and it's also used extensively in my living room (where the speakers are connected to the home server).
Exactly. Does it support redirecting audio streams to another machine on the same network? That's a vital feature in our hackspace, where everyone can send audio to the room speakers via PA, and it's also used extensively in my living room (where the speakers are connected to the home server).
I don't know, but sending audio over a network sounds like the sort of use case that requires a sound server. Playing sound locally doesn't. Although, as I said elsewhere, I have mpd stream to icecast for playing my audio remotely so, in my case, I don't need pulseaudio for this: I imagine you could configure a similar setup where anyone on the local network can register with icecast as a "radio station" znd stream sound that way.
A workflow that enables network transparency by using a tool for radio stations might work for music, but not for anything with latency requirements. Imagine playing any video game with even a 100ms audio delay.
That's something that really bothers me about pulse: it looks like it should have a nice unixy design and work well, but actually using it is, in my experience, a complete potshot.
For me the important advance was redirecting an audio stream to a different device on my machine, as I wanted to happen when I plugged in my USB headset. Currently that works more smoothly on Linux for me than Windows.
Also, something like this should work for network sound :) http://plasmasturm.org/log/soundserverhack/
When you log out of your desktop session, does mpd continue playing? I have mpd setup to stream via icecast so I can listen to my music remotely and the issue I was having was that when I logged out of my desktop, the music would stop playing because the sound server was tied to my desktop session.
You will need to disable automatic starting, and start it manually. https://wiki.archlinux.org/index.php?title=PulseAudio&mobile...
(see also linked upstream docs)
[deleted]
I believe personal experience is anecdotal at best and not "the universe". My anecdotal experience with pulseaudio is that it simply does not like my setup (internal sound card + 4 external usb card + occasional hdmi sound transport) and having an occasional pop or crack on a 10kW PA system is not desirable.
I've read a pulseaudio guru post explaining that when you know what you are doing you can work out a pulseaudio config that reduce pulseaudio latency issues, real time resampling, drop outs and high cpu usage. Just don't use the default config.
I've read a pulseaudio guru post explaining that when you know what you are doing you can work out a pulseaudio config that reduce pulseaudio latency issues, real time resampling, drop outs and high cpu usage. Just don't use the default config.
internal sound card + 4 external usb card + occasional hdmi sound transport) and having an occasional pop or crack on a 10kW PA system is not desirable.
This is a common issue. It happens on Windows and Mac, as well. Am I to understand you don't experience it with some other way of handling sound (e.g. not using PulseAudio)? Are all of them being driven by the same program?
I DJ, and have used multiple independent interfaces in the past; there were frequently pops and warbles as the various timing crystals in the various interfaces fell out of sync and were forced back into sync by the software. It happened on both Windows and Linux (though it was slightly less pronounced on Linux, and I never figured out why). JACK might be the best way to deal with that problem on Linux, though I never tried it (I just switched to a dedicated DJ controller with multiple outs and headphone output).
But, it's a common enough problem that most DJ software has something about the problem in their FAQ.
This is a common issue. It happens on Windows and Mac, as well. Am I to understand you don't experience it with some other way of handling sound (e.g. not using PulseAudio)? Are all of them being driven by the same program?
I DJ, and have used multiple independent interfaces in the past; there were frequently pops and warbles as the various timing crystals in the various interfaces fell out of sync and were forced back into sync by the software. It happened on both Windows and Linux (though it was slightly less pronounced on Linux, and I never figured out why). JACK might be the best way to deal with that problem on Linux, though I never tried it (I just switched to a dedicated DJ controller with multiple outs and headphone output).
But, it's a common enough problem that most DJ software has something about the problem in their FAQ.
Eh, you can change the cpu buffer a bit. That's about it. PA is still a wrapper.
As far as I know, Pulseaudio still hasn't fixed the four and a half year old bug which causes Bluetooth audio to get more and more out of sync until you reconnect: https://bugs.freedesktop.org/show_bug.cgi?id=58746
The one procedure I use to fix non-working sound on Linux consists of 1 - look at the package manager for pulse-audio; 2 - Uninstall it.
Works every single time. last time I did it was around March. (I still don't know how it creeps back into my computers.)
Last time pulse was creating problems for me I decided that since I was now writing an application that links to the sound system, let's stop linking to low level functions and use pulse abstractions that some people claim to be better.
Turns out that the pulse "abstractions" are basically verbatim copies of alsa. Just with some added badly documented options. Some with very descriptive names, other with cryptic ones, but whatever, no option seems to do exactly what its name implies. Besides, pulse abstracts away most of the flexibility of the sound hardware, so you can't use it, and well, every time I tried running something with it, I got an assertion failure on pulse code... Always with some completely non-descriptive description.
Works every single time. last time I did it was around March. (I still don't know how it creeps back into my computers.)
Last time pulse was creating problems for me I decided that since I was now writing an application that links to the sound system, let's stop linking to low level functions and use pulse abstractions that some people claim to be better.
Turns out that the pulse "abstractions" are basically verbatim copies of alsa. Just with some added badly documented options. Some with very descriptive names, other with cryptic ones, but whatever, no option seems to do exactly what its name implies. Besides, pulse abstracts away most of the flexibility of the sound hardware, so you can't use it, and well, every time I tried running something with it, I got an assertion failure on pulse code... Always with some completely non-descriptive description.
What were your problems exactly? In my case I used Linux full time from late 2012 to early 2014 and during that time I haven't had a single problem related to it, all while running bleeding edge Archlinux. The only issue was with bluetooth headphones but I'm pretty sure it was more with BlueZ being a pile of garbage than Pulseaudio being bad, given that BlueZ was giving me problems with all sorts of other (non sound) peripherals as well.
Mostly the same issues as BeetleB. It purports to pump audio samples. It does not. Another moving piece in between your app and ALSA, which seems to break down inexplicably when the crap that it's abstracting "just works" with zero configuration. Many times the solution to an audio problem on linux is to get rid of pulse. Still.
Also had issues with bluetooth, as you seem to have. I will permit the idea that this is possibly unrelated (bluez is garbage, yes), but bluetooth audio was working for me previously, and only broke when pulse entered the picture.
FWIW from an API perspective I still think OSS seems better than ALSA... Linux audio seems to be a repeated case of people confusing interface with implementation, and the interface only ever gets more complex.
Also had issues with bluetooth, as you seem to have. I will permit the idea that this is possibly unrelated (bluez is garbage, yes), but bluetooth audio was working for me previously, and only broke when pulse entered the picture.
FWIW from an API perspective I still think OSS seems better than ALSA... Linux audio seems to be a repeated case of people confusing interface with implementation, and the interface only ever gets more complex.
The amusing part is that FreeBSD is still on OSS, and it "just works" - and they let multiple apps play audio at the same time simply by opening the same device. It's been that way... I don't even remember how long, but I think it was already there 15 years ago?
And OpenBSD introduced its own userspace daemon for mixing multiple audio streams together. The by-then already existing libsndio would then just default to opening the socket provided by that daemon. So, the change was transparent to applications (no code changes, they already used libsndio) and users (no configuration, at least for people running defaults) and didn't cause years of grief, agony, churn, hatred, and shitstorm.
Of course you can still trivially disable the daemon and you lose software mixing & resampling, but things that work within these limits will run ok. But there really shouldn't ever be need to disable it, it just works.
The sndio api is pretty damn nice & simple too. https://man.openbsd.org/sio_open.3
Of course you can still trivially disable the daemon and you lose software mixing & resampling, but things that work within these limits will run ok. But there really shouldn't ever be need to disable it, it just works.
The sndio api is pretty damn nice & simple too. https://man.openbsd.org/sio_open.3
I tried installing it a few months ago, and... could not get any sound. Similar experience several years ago. I'm sure I could Google and fix, but for me, it did not "just work".
Don't get me wrong. For years, ALSA was a pain. But in the last 10 years, ALSA has always "just worked" for me. I think the only time I had to fiddle with ALSA in the last decade was to get the mic on a headset to work.
Don't get me wrong. For years, ALSA was a pain. But in the last 10 years, ALSA has always "just worked" for me. I think the only time I had to fiddle with ALSA in the last decade was to get the mic on a headset to work.
For me, "Just Works" includes me not having to install it at all, not it being easy to set-up on LFS. Pulseaudio is pre-installed on Fedora, Ubuntu, etc.
ALSA is part of the kernel, it's likely been pre-installed in every Linux you have ever run. It's not a mark against it that you choose to install distros developed to use pulseaudio.
Well, that's almost what I had. It didn't come preinstalled, but it's in the package manager. I installed it, and, no sound.
I've occasionally seen issues on one of my machines where applications would send out garbled audio until I killed the PulseAudio process and restarted the application (the latter was insufficient alone; PA had to be killed). Hasn't happened lately, though, and it might've had more to do with the application.
I use Slackware, which tends to be more conservative about these things; the fact that PA is now the default in Slackware is a good indicator of PA having overcome its growing pains.
I use Slackware, which tends to be more conservative about these things; the fact that PA is now the default in Slackware is a good indicator of PA having overcome its growing pains.
Nah, Slackware adopted PA because bluez now insist on using PA for audio IO.
I have a feeling if PA was really as broken as it was once upon a time, Bluetooth audio would've been sacrificed in favor of a more stable and reliable system.
Additionally, I somewhat doubt BlueZ would've made PA such a hard dependency if they weren't reasonably sure that it's stable enough for primetime.
Additionally, I somewhat doubt BlueZ would've made PA such a hard dependency if they weren't reasonably sure that it's stable enough for primetime.
Are you actually using PulseAudio? Having run Arch (well, Parabola) since 2011, I haven't had any problems with PulseAudio... because I've never installed PulseAudio. Actually, I did have a problem with Wine and lib32-libpulse lagging slightly behind the video (where it's only a fraction of a second off, but enough that it doesn't feel like the words match the faces); and then I figured out how to get Wine to use ALSA, just like everything else.
User of desktop linux here (after 3 years of trying and failing with OS X).
Also people at work are allowed to use desktop linux at work as long as we don't bother IT.
(This with a serious company with even older more seriois roots.)
I think desktop linux is still on the rise.
Also people at work are allowed to use desktop linux at work as long as we don't bother IT.
(This with a serious company with even older more seriois roots.)
I think desktop linux is still on the rise.
I was one of those developers with an OS X machine who decided to buy a Thinkpad and throw Ubuntu on it. pulseaudio worked out of the box for me and I definitely preferred it over the stunted OS X audio mixer that doesn't even let you define per-application audio.
The MacOS mixer is pretty much the epitome of "just works" even though I agree with you that it doesn't let you control levels per application.
However I've been using the MacOS sound system (not just the mixer) for many years through many devices (mics, external dacs, HDMI transports, DP etc) and it has always worked without any problems.
However I've been using the MacOS sound system (not just the mixer) for many years through many devices (mics, external dacs, HDMI transports, DP etc) and it has always worked without any problems.
I don't have much personal experience, but I /often/ hear about OSX users very wary of updating MacOS because of issues with sound equipment. This goes back to Classic. It may have gone away in the past 3-5 years, but the stigma is still there.
Never had issues with PulseAudio in the recent times. I use Linux for all my desktop needs, including gaming. Of course if you have specific audio needs that require more realtime processing, you can for example use Jack.
Maybe you really do live in a different universe, because my audio sounds good and I legitimately can't remember the last time I had to worry about it. It's been years, and now for the first time on Desktop Linux I can connect a Bluetooth or USB audio device without wondering if I could actually coax my software into using it.
OS X in incresingly less Unix-like with every new version. They even changed its name back to MacOS.
You mean "macOS". But I don't see the relevance. Is it because the name no longer contains an "x" character? The X in OS X had no relation to unix, it was because it was the successor to MacOS 9 (and in fact the full name was originally Mac OS X).
They even advertised it as Unix-like.
https://www.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Us...
We are using it for develoment but it's considerably more work to setup the develoment environment than installing a Linux distribution with everything we need available by default or a command away. Also in El Capitan the root user is disabled by default.
http://www.infoworld.com/article/2988096/mac-os-x/sorry-unix...
https://www.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Us...
We are using it for develoment but it's considerably more work to setup the develoment environment than installing a Linux distribution with everything we need available by default or a command away. Also in El Capitan the root user is disabled by default.
http://www.infoworld.com/article/2988096/mac-os-x/sorry-unix...
> installing a Linux distribution
Linux != Unix. Darwin is much closer to BSD.
> Also in El Capitan the root user is disabled by default.
Lies. I never touched a thing and (on 10.13 ß):
- SEP prevents you (or any random script/software/installer you run) from meddling with system files and that is a good thing too, no different from sensible SELinux or AppArmor policies.
Linux != Unix. Darwin is much closer to BSD.
> Also in El Capitan the root user is disabled by default.
Lies. I never touched a thing and (on 10.13 ß):
$ sudo su -l
password:
Galileo:~ root# ps -u root | wc -l
115
- SEP prevents you (or any random script/software/installer you run) from meddling with system files and that is a good thing too, no different from sensible SELinux or AppArmor policies.
Whether or not it's Unix-like has nothing to do with the name. I was taking issue with the fact that you were suggesting the name change indicated that it's less Unix-like.
That said, macOS is just as Unix-like as it's ever been. As lloeki said, it's actually closer to BSD than Linux, which may explain some of your gripes.
As for the root user, it's been disabled by default since Mac OS X first came out. Being able to log in as root is considered a security risk, and there's no need for it. If you want root access, use sudo.
That said, macOS is just as Unix-like as it's ever been. As lloeki said, it's actually closer to BSD than Linux, which may explain some of your gripes.
As for the root user, it's been disabled by default since Mac OS X first came out. Being able to log in as root is considered a security risk, and there's no need for it. If you want root access, use sudo.
What all are you lumping into dev environment setup? For many years most projects have only needed two steps (CLI toolchain install, Homebrew) plus the project specific setup.
Different versions of perl, node, mariadb, apache. I am using Homebrew as well, was using Macports but it pulls too many dependencies. You still need to install Xcode for which you need an appstore account. On Linux you're pretty much done after you install the OS, or maybe you might need to apt install build-essential.
Do you need more than the basic CLI tools? “xcode-select --install” didn't used to require an App Store account.
How are you managing different package versions on Linux – PPAs to avoid conflicts with the system Perl, Apache, etc,
How are you managing different package versions on Linux – PPAs to avoid conflicts with the system Perl, Apache, etc,
Perl allows multiple installations using plenv or perlbrew. You activate one of those or the system Perl. For the rest we just need one version - the one that runs in the production machines.
The name change is unrelated. MacOS is still officially a Unix, however: https://www.opengroup.org/openbrand/register/brand3627.htm
Very much this. The only big change with pa in last few years is - applications accepted and embraced it - to the point of dropping OSS & ALSA.
I personally hope Linux application developers support PipeWire as it becomes available so that the usability issues around low-latency audio in Linux can be sorted out (i.e. it works out of the box):
https://blogs.gnome.org/uraeus/2017/06/20/fedora-workstation...
https://blogs.gnome.org/uraeus/2017/06/20/fedora-workstation...
I really hate seeing how Firefox on Linux is spiraling the drain in this regard. First GTK3, then PA.
There really is a changing of the guard in Linux userspace, and the change is for the worse.
There really is a changing of the guard in Linux userspace, and the change is for the worse.
To be fair, pulseaudio has stopped causing me problems, which in my book is equivalent to "got good".
Now if only the same could be said for bluez...
Now if only the same could be said for bluez...
I haven't used PulseAudio until very recently when Firefox started requiring it for audio (chrome/chromium still support plain ALSA), that said I haven't come across any problem, what should I be looking out for ?
Mostly minor things nowadays. I've seen so far:
- a while ago pa got audio routing wrong on a new/obscure laptop, wrong audio routing as in - speakers would not turn off if you plug in headphones. That eventually got fixed with dnf upgrade and no effort on my part;
- on ultrabook, pa sucks noticeable amount of battery by waking up 100 times a second (while no audio is being played). Something akin to what this poor chap is describing:
https://www.reddit.com/r/Fedora/comments/6d7776/pulseaudio_b...
- a while ago pa got audio routing wrong on a new/obscure laptop, wrong audio routing as in - speakers would not turn off if you plug in headphones. That eventually got fixed with dnf upgrade and no effort on my part;
- on ultrabook, pa sucks noticeable amount of battery by waking up 100 times a second (while no audio is being played). Something akin to what this poor chap is describing:
https://www.reddit.com/r/Fedora/comments/6d7776/pulseaudio_b...
Nothing really, it's fine for nearly everything and just tends to get on with the job.
The only bug that's affected me in the last couple of years was that the default volume on USB headsets was always set way too low. Pavucontrol helped sort it out
https://freedesktop.org/software/pulseaudio/pavucontrol/
The only bug that's affected me in the last couple of years was that the default volume on USB headsets was always set way too low. Pavucontrol helped sort it out
https://freedesktop.org/software/pulseaudio/pavucontrol/
The only problem I've had recently is that I can't seem to split up different ports on the same card (optical home theatre/soundbar for music, desktop stereo for everything else), but that's not something I was able to do with ALSA anyway.
Something to do with opening the card in different profiles I think.
Something to do with opening the card in different profiles I think.
How, exactly, has systemd "broken user space"? That's clear neither from the lkml thread, nor here. I'm not sure what this discussion even has to do with systemd; and I'm not even sure how you can "break user space" from a user space program, which init is.
You might be able to modify your descendants' environment, but the rules under which that can happen are maintained and enforced by the kernel. It seems to me that if user space programs can do undesirable things, that's the fault of the kernel itself. To be sure, setting those boundaries and rules is one of the kernel's main jobs.
You might be able to modify your descendants' environment, but the rules under which that can happen are maintained and enforced by the kernel. It seems to me that if user space programs can do undesirable things, that's the fault of the kernel itself. To be sure, setting those boundaries and rules is one of the kernel's main jobs.
Another example:
You could interpret this as "breaking user-space", as it's contrary to long-running practice and user-expectations.
Or you could say that systemd is superior as it's reliably cleaning up unwanted lingering processes which may have bothered some before. And this is worth the hassle of explicitly running intended background processes via systemd-run(1), or adding code to e.g. tmux/screen doing the equivalent via the dbus-api.
$ nohup ./long_running_process &
$ logout
You could interpret this as "breaking user-space", as it's contrary to long-running practice and user-expectations.
Or you could say that systemd is superior as it's reliably cleaning up unwanted lingering processes which may have bothered some before. And this is worth the hassle of explicitly running intended background processes via systemd-run(1), or adding code to e.g. tmux/screen doing the equivalent via the dbus-api.
Dagnabbit systemd! Thank you. You just solved a mysterious bug for me.
The whole purpose of nohup is to get your process to ignore your session ending. Why on earth systemd would up and decide that you didn't do that on purpose is beyond me.
When people say they hate systemd, it's precisely this kind of thing that we're talking about.
The whole purpose of nohup is to get your process to ignore your session ending. Why on earth systemd would up and decide that you didn't do that on purpose is beyond me.
When people say they hate systemd, it's precisely this kind of thing that we're talking about.
Yes, this breaks something that has worked in Unix for 30+ years. Awful.
Systemd does give us extremely quick boot times, though! Too bad I generally don't reboot my Linux systems more than once a month.
Systemd does give us extremely quick boot times, though! Too bad I generally don't reboot my Linux systems more than once a month.
Indeed. systemd does boast respectable boot times (not as fast as hand-crafted shell script, but pretty good for a generic init).
On the other hand, error handling is pretty awful, especially during shutdown: Every now and then systemd would decide to give that one unresponsive sshd process a generous couple of minutes to shut down. Or will wait for a random filesystem to unmount itself for another 90 seconds. Sometimes outgoing systemd will lock up completely, until you do the magic ritual of pressing ctrl+alt+del 7 times within 2 seconds all while spinning around on your toes trice counter-clockwise and barking - to force "immediate" restart. Better yet - on special occasions this ritual devolves into farce: _after_ hammering ctrl+alt+del at machine gun rate it will print "rebooting now" and... lock up again. Until you hammer ctrl+alt+del again - only to see another empty "rebooting now" promise. SysRq would - of course - have no problem at all remounting filesystems ro and rebooting from this sad limbo.
On the other hand, error handling is pretty awful, especially during shutdown: Every now and then systemd would decide to give that one unresponsive sshd process a generous couple of minutes to shut down. Or will wait for a random filesystem to unmount itself for another 90 seconds. Sometimes outgoing systemd will lock up completely, until you do the magic ritual of pressing ctrl+alt+del 7 times within 2 seconds all while spinning around on your toes trice counter-clockwise and barking - to force "immediate" restart. Better yet - on special occasions this ritual devolves into farce: _after_ hammering ctrl+alt+del at machine gun rate it will print "rebooting now" and... lock up again. Until you hammer ctrl+alt+del again - only to see another empty "rebooting now" promise. SysRq would - of course - have no problem at all remounting filesystems ro and rebooting from this sad limbo.
The more one read the more one get flashbacks to the very Windows painpoints that made one adopt Linux in the first place...
I actually explained in detail how one could fix this, a year ago.
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221
Absolutely. I cannot fathom why they thought that SIGKILL was appropriate instead of SIGHUP, even if they made the misused choice of considering it their responsibility at all.
Here's a good explanation of the behavior, how to disable it, and why Fedora will be turning it back on in 26 (it's been off by default). https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_...
No, that's just Zbigniew Jędrzejewski-Szmek's explanation repeated ... by Zbigniew Jędrzejewski-Szmek. I see from elsewhere on this page that you have unwisely bought into the idea promulgated on that page that Zbigniew Jędrzejewski-Szmek will "work with upstream authors and Fedora maintainers of programs like screen and tmux". No, xe won't; and demonstrably has not.
You need to look at some of the history here. Over the course of the past six years, Zbigniew Jędrzejewski-Szmek has twice cycled around the same loop, once in 2011 and once in 2016. Xe goes to the developers of tmux, tells them that tmux needs to change to be systemd specific, and the developers of tmux ask why systemd cannot provide the same semantics for interactive login sessions that have been employed for the past 38 years, with HUP for session hangup and TERM/KILL at system shutdown; or why at the very least xe does not talk to the C library people. Zbigniew Jędrzejewski-Szmek goes away, and then comes back about 5 years later with the exact same thing, unchanged.
Unfortunately, buying into that Fedora wiki page is as unwise as buying into the rather erroneous Freedesktop explanation of how version 2 cgroups work. You will note that the wiki page dates from around the same time as Zbigniew Jędrzejewski-Szmek's last cycle around the loop, which hit the headlines last year.
* https://news.ycombinator.com/item?id=11797075
* https://news.ycombinator.com/item?id=11797926
* https://news.ycombinator.com/item?id=11782364
You need to look at some of the history here. Over the course of the past six years, Zbigniew Jędrzejewski-Szmek has twice cycled around the same loop, once in 2011 and once in 2016. Xe goes to the developers of tmux, tells them that tmux needs to change to be systemd specific, and the developers of tmux ask why systemd cannot provide the same semantics for interactive login sessions that have been employed for the past 38 years, with HUP for session hangup and TERM/KILL at system shutdown; or why at the very least xe does not talk to the C library people. Zbigniew Jędrzejewski-Szmek goes away, and then comes back about 5 years later with the exact same thing, unchanged.
Unfortunately, buying into that Fedora wiki page is as unwise as buying into the rather erroneous Freedesktop explanation of how version 2 cgroups work. You will note that the wiki page dates from around the same time as Zbigniew Jędrzejewski-Szmek's last cycle around the loop, which hit the headlines last year.
* https://news.ycombinator.com/item?id=11797075
* https://news.ycombinator.com/item?id=11797926
* https://news.ycombinator.com/item?id=11782364
Unrelated, but how come you've chosen to use the `xe` pronoun?
I couldn't find any mention of it in Zbigniew's blog.
I couldn't find any mention of it in Zbigniew's blog.
I've sometimes used it (or ve) in the past, because there's no good gender-neutral pronoun and I don't like to assume. (This is partly a politeness thing and partly an accuracy thing.)
Occasionally when I would do so, people would get confrontational about it, so I mostly stopped. But now that means I sometimes waste time trying to find someone's gender even though that's totally irrelevant, and/or try to work around needing a pronoun at all, and/or use "they" even though I don't like it. None of these solutions is great.
(Btw, I don't parse you as confrontational. Comments like yours wouldn't have bothered me.)
Occasionally when I would do so, people would get confrontational about it, so I mostly stopped. But now that means I sometimes waste time trying to find someone's gender even though that's totally irrelevant, and/or try to work around needing a pronoun at all, and/or use "they" even though I don't like it. None of these solutions is great.
(Btw, I don't parse you as confrontational. Comments like yours wouldn't have bothered me.)
From what I can tell, they use it for everyone.
[0] https://news.ycombinator.com/item?id=11785977
[1] https://news.ycombinator.com/item?id=14665518
[1] https://news.ycombinator.com/item?id=14580113
[2] https://news.ycombinator.com/item?id=14553959
[0] https://news.ycombinator.com/item?id=11785977
[1] https://news.ycombinator.com/item?id=14665518
[1] https://news.ycombinator.com/item?id=14580113
[2] https://news.ycombinator.com/item?id=14553959
FWIW, "Zbigniew" is a male forename.
I don't get it. They say that the default should be to kill everything that doesn't opt out, but that already has been the default. SIGHUP gets sent to all processes, and those processes can explicitly ignore SIGHUP. In the new scheme, SIGKILL gets sent to all processes, except if the process has requested not to be killed through systemd's API. A misbehaving program in the old scheme would still be misbehaving in the new scheme, so there is no added benefit.
The added "benefit" is that once more systemd gets to define behavior.
Systemd is not about building refinements on unix, it is about turning Linux into something like OSX or Android. a OS that use unix semantics only for bootstrapping convenience.
Effectively they are turning the Linux kernel into a convenient source of drivers, but beyond that could not care one bit about unix.
I really wish i could find the interview again where it mentions that Poettering in the past have advocated throwing away the chapters on unix programming from one of the seminal works on programming unix and Linux.
Systemd is not about building refinements on unix, it is about turning Linux into something like OSX or Android. a OS that use unix semantics only for bootstrapping convenience.
Effectively they are turning the Linux kernel into a convenient source of drivers, but beyond that could not care one bit about unix.
I really wish i could find the interview again where it mentions that Poettering in the past have advocated throwing away the chapters on unix programming from one of the seminal works on programming unix and Linux.
That's what I'm getting, but I'm trying to at least give systemd advocates the benefit of the doubt. When I have the time and energy, it can be a good use of time to poke at people with questions.
There are a couple of inits in common usage on Linux; systemd is now the most popular and ships standard on the most popular distributions. I can't imagine Linus would be feeling grouchy toward a nearly defunct init (that had been in use mostly unchanged since the 90s), so we're left with systemd. Unless you've got a better idea about what he means?
It is not a secret that kernel devs have a love-hate relationship with systemd, and have for years. That's why Linus said, "You all presumably know why." He was speaking with context that everyone on the LKML already knows.
First result when I google it (but it's been a thing for a long time and on many fronts with many interesting bugs and arguments): http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA
I don't really subscribe to the "systemd is terrible and is the worst thing that ever happened to Linux" theory, and I'm not trying to be one of those folks that takes every opportunity to make a thread about how much systemd sucks. I like systemd. I mean it when I say that. But, in this case, it seems obvious it is about systemd. I have a hard time coming up with another plausible theory.
Edit: Also, now that I'm thinking about Linus and Poettering butting heads...well, that's hilarious. A couple of brilliant assholes arguing is funny to me. I dunno how much it's actually happened (and how much happened through proxies), but still. Funny.
It is not a secret that kernel devs have a love-hate relationship with systemd, and have for years. That's why Linus said, "You all presumably know why." He was speaking with context that everyone on the LKML already knows.
First result when I google it (but it's been a thing for a long time and on many fronts with many interesting bugs and arguments): http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA
I don't really subscribe to the "systemd is terrible and is the worst thing that ever happened to Linux" theory, and I'm not trying to be one of those folks that takes every opportunity to make a thread about how much systemd sucks. I like systemd. I mean it when I say that. But, in this case, it seems obvious it is about systemd. I have a hard time coming up with another plausible theory.
Edit: Also, now that I'm thinking about Linus and Poettering butting heads...well, that's hilarious. A couple of brilliant assholes arguing is funny to me. I dunno how much it's actually happened (and how much happened through proxies), but still. Funny.
Maybe eventually Linus will become so fed up with systemd, that he would write an init system of his own, which would become a major success just like git did. Then conversations like this one will be pointless, because everyone and their dog with the possible exception of RedHat would have long switched to Linus' init.
Systemd and the whole controversy around it is anything but funny. It's upsetting and it already divided the community.
Systemd and the whole controversy around it is anything but funny. It's upsetting and it already divided the community.
Maybe eventually Linus will become so fed up with systemd, that he would write an init system of his own
Can't. Fucking. Wait. Seriously, that day cannot come soon enough. systemd might have some useful ideas, but their implementation is crap, and the overall intrusion on how to get stuff done is significant.
Can't. Fucking. Wait. Seriously, that day cannot come soon enough. systemd might have some useful ideas, but their implementation is crap, and the overall intrusion on how to get stuff done is significant.
It's a little funny.
systemd has some great stuff in it. I have my nits to pick with it but, on the whole, it's better than what we had before. And, don't we all just want things to be a little better every day?
I think it's all gonna work out fine in the end (and if not, we'll all be dead someday, anyway).
systemd has some great stuff in it. I have my nits to pick with it but, on the whole, it's better than what we had before. And, don't we all just want things to be a little better every day?
I think it's all gonna work out fine in the end (and if not, we'll all be dead someday, anyway).
I use tmux and emacs --daemon constantly. My experience with systemd is that I need to check whether KillUserProcesses is enabled, or else systemd will kill my processes. My experience with init was nonexistent, because it never came up as an issue.
Most distros have set KillUserProcesss to no for the short-term. Fedora plans to make all of the obvious user programs aware of the change (and able to create a new systemd unit for the process) and turn it back on for Fedora 26.
https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_...
Their reasoning is pretty good, IMHO. It provides more control at low cost, and it's a one-line configuration change if you want the old behavior. But, everything I need it for (pretty much just screen and tmux) will already be aware and will handle setting up the new systemd unit automatically.
https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_...
Their reasoning is pretty good, IMHO. It provides more control at low cost, and it's a one-line configuration change if you want the old behavior. But, everything I need it for (pretty much just screen and tmux) will already be aware and will handle setting up the new systemd unit automatically.
It is a one-line configuration change IF you know that it exists, and you have administrator privileges on the machine. If either of those conditions fail, systemd has broken your setup.
Not only that, but there was an existing mechanism for this. On a disconnect, SIGHUP would be sent to all processes. A background process can explicitly ignore SIGHUP in order to remain running on disconnect. I would be fine if systemd were sending SIGHUP to processes, because that would fit with the existing method of opting out. Sending SIGKILL, and having to use systemd's API to opt out of being killed is ridiculous.
This adds more complexity for no added benefit. My standard .bashrc now needs to have a line checking whether KillUserProcesses is enabled, so that I can bug the admin to disable that idiocy if it is.
Not only that, but there was an existing mechanism for this. On a disconnect, SIGHUP would be sent to all processes. A background process can explicitly ignore SIGHUP in order to remain running on disconnect. I would be fine if systemd were sending SIGHUP to processes, because that would fit with the existing method of opting out. Sending SIGKILL, and having to use systemd's API to opt out of being killed is ridiculous.
This adds more complexity for no added benefit. My standard .bashrc now needs to have a line checking whether KillUserProcesses is enabled, so that I can bug the admin to disable that idiocy if it is.
>A background process can explicitly ignore SIGHUP
The problem with SIGHUP is that a background process can't explicitly ignore SIGHUP, it can only implicitly ignore it. If you send SIGHUP to a process and it doesn't exit you have no idea if it didn't exit because it wants to hang around or if it didn't exit because the process is hung.
Part of the motivation for fixing that is to eliminate things like gnome-keyring-daemon hanging around after the user logs out.
The problem with SIGHUP is that a background process can't explicitly ignore SIGHUP, it can only implicitly ignore it. If you send SIGHUP to a process and it doesn't exit you have no idea if it didn't exit because it wants to hang around or if it didn't exit because the process is hung.
Part of the motivation for fixing that is to eliminate things like gnome-keyring-daemon hanging around after the user logs out.
Correct me if I am wrong, but I would call signal(SIGHUP, mysignalhandler) to be an explicit ignoring of SIGHUP. I have taken a non-default action in order to have a non-default behavior.
Since gnome is the one that requires behavior and integration with systemd beyond what can be done with signals, a reasonable workaround would be to have the extra logic in systemd apply only to gnome. As it is, they are changing to a default that is entirely unreasonable outside of a desktop environment, and requiring others to work with the new system.
Since gnome is the one that requires behavior and integration with systemd beyond what can be done with signals, a reasonable workaround would be to have the extra logic in systemd apply only to gnome. As it is, they are changing to a default that is entirely unreasonable outside of a desktop environment, and requiring others to work with the new system.
>I would call signal(SIGHUP, mysignalhandler) to be an explicit ignoring of SIGHUP.
But that doesn't explicitly ignore SIGHUP. You're explicitly handling it but from an outside perspective we don't know if your SIGHUP handler is supposed to be a no op, output some progress information, terminate the program in some special way or what. All the system knows is that it signaled your program and your program is still around 10 seconds later. In terms of your program, it hasn't taken any external action, hence not being explicit.
As for the Gnome project though, that's just an example. I'm talking about cases where the application should terminate upon receipt of SIGHUP but doesn't. That default isn't changing, the method to avoid the default action is. Back when SIGHUP was created all software that wanted to ignore it needed to make a handler to avoid the new default behavior. If you want to be able to kill misbehaving processes that were supposed to terminate on SIGHUP then the design needs to change. There's no way to fix this without making some breaking change.
As to requiring others to work with it, your distribution is the one that's making you do that. systemd upstream has had killuserprocesses for a while now. It's just a configure option when building systemd. It's not like your distro is having someone else build packages for them, setting appropriate config options is entirely on them. Some distros are building systemd with that on by default, and some aren't.
As for the Gnome project though, that's just an example. I'm talking about cases where the application should terminate upon receipt of SIGHUP but doesn't. That default isn't changing, the method to avoid the default action is. Back when SIGHUP was created all software that wanted to ignore it needed to make a handler to avoid the new default behavior. If you want to be able to kill misbehaving processes that were supposed to terminate on SIGHUP then the design needs to change. There's no way to fix this without making some breaking change.
As to requiring others to work with it, your distribution is the one that's making you do that. systemd upstream has had killuserprocesses for a while now. It's just a configure option when building systemd. It's not like your distro is having someone else build packages for them, setting appropriate config options is entirely on them. Some distros are building systemd with that on by default, and some aren't.
But, it breaks a standard Unix behaviour going back years, and it can't be configured by a non root user.
I would say the same with pulseaudio; before this, there were a mess of audio servers (esd / ksd or none) - now things are definitely better.
I have not required a audio server in years, and i have not adopted PA. What i did was enable dmix, that comes with Alsa.
A behavior that is even default Alsa these days if it detect that you use sound hardware without mixing.
The one "issue" that PA "fixed" was that of temporary audio devices (bluetooth, USB). But then i find the whole notion of USB headphones (a pair of headphones soldered to a minimal USB sound card) a massive abomination. and i fail to see why paired Bluetooth audio devices are exposed directly into the /dev tree rather than behind the Bluetooth dongle device.
A behavior that is even default Alsa these days if it detect that you use sound hardware without mixing.
The one "issue" that PA "fixed" was that of temporary audio devices (bluetooth, USB). But then i find the whole notion of USB headphones (a pair of headphones soldered to a minimal USB sound card) a massive abomination. and i fail to see why paired Bluetooth audio devices are exposed directly into the /dev tree rather than behind the Bluetooth dongle device.
> a couple of brilliant assholes
Define brilliant. One changed the computing landscape by starting (and running for decades) the biggest opensource copyleft project in the history of mankind; the other is a bog-standard corporate engineer who simply leverages his parent company status to piss off most people and get away with it. Placing them on the same level is an insult to Linus, who might occasionally be an asshole but is still the most effective leader the opensource community has ever seen.
Define brilliant. One changed the computing landscape by starting (and running for decades) the biggest opensource copyleft project in the history of mankind; the other is a bog-standard corporate engineer who simply leverages his parent company status to piss off most people and get away with it. Placing them on the same level is an insult to Linus, who might occasionally be an asshole but is still the most effective leader the opensource community has ever seen.
The funny thing is that Torvalds is not much of an asshole unless you violate the trust he have placed in you.
He will gladly chastise himself for errors etc, and is quite humble in public.
Poettering on the other hand have a history of hubris and assholeness.
Consider for example that he not only heckled a presenter at a conference. But when the presenter bowed out early he climbed the stage, beer bottle in hand, to grab the microphone.
It would not surprise me of Poettering have never met hardship during his school years (apparently the signing scheme used in journald was based on his brother's doctoral thesis no less) until he hit the net with his projects, and simply do not know how the handle negative feedback.
He will gladly chastise himself for errors etc, and is quite humble in public.
Poettering on the other hand have a history of hubris and assholeness.
Consider for example that he not only heckled a presenter at a conference. But when the presenter bowed out early he climbed the stage, beer bottle in hand, to grab the microphone.
It would not surprise me of Poettering have never met hardship during his school years (apparently the signing scheme used in journald was based on his brother's doctoral thesis no less) until he hit the net with his projects, and simply do not know how the handle negative feedback.
Poettering is perhaps an asshole, but Torvalds reputation for being so is overhyped to put it mildly.
Never mind that they have faced off (sort of) on camera at least once, with Poettering basically missing the point again and again that not just Torvalds but also other long term kernel devs on the stage was raising.
Never mind that they have faced off (sort of) on camera at least once, with Poettering basically missing the point again and again that not just Torvalds but also other long term kernel devs on the stage was raising.
But you said specifically "...and systemd has broken userspace a lot."
What did you mean by this? It seems like a complete nonsense statement in the context of user space breakage of the form the kernel is responsible for.
The main clash between the kernel maintainers and the systemd maintainers was over systemd reading the kernel argv in an error prone way to trigger debug information. Other than that the interactions seem completely minimal. Linus Torvalds uses systemd at work and at home.
What did you mean by this? It seems like a complete nonsense statement in the context of user space breakage of the form the kernel is responsible for.
The main clash between the kernel maintainers and the systemd maintainers was over systemd reading the kernel argv in an error prone way to trigger debug information. Other than that the interactions seem completely minimal. Linus Torvalds uses systemd at work and at home.
"What did you mean by this? It seems like a complete nonsense statement in the context of user space breakage of the form the kernel is responsible for."
Does it? systemd is the init, the service manager, the interface to D-bus (and kernel devs had a bit of a tussle with the systemd devs about kdbus), the logging interface of most services (possibly including kernel logs), etc. systemd interacts with both the kernel directly (as the system init, as one interface to cgroups and namespaces, etc.) and with users (as everything else it does). I like it, but I understand the Borg accusations.
"The main clash between the kernel maintainers and the systemd maintainers was over systemd reading the kernel argv in an error prone way to trigger debug information."
Searching the LKML for systemd seems to indicate otherwise. It seems like there have been a few scuffles over the years. I don't subscribe to the LKML or read it religiously and haven't for many years, so I'm mostly guessing based on context, but the context seems clear to me.
Again, I ask, if not systemd, then which init is Linus talking about?
Does it? systemd is the init, the service manager, the interface to D-bus (and kernel devs had a bit of a tussle with the systemd devs about kdbus), the logging interface of most services (possibly including kernel logs), etc. systemd interacts with both the kernel directly (as the system init, as one interface to cgroups and namespaces, etc.) and with users (as everything else it does). I like it, but I understand the Borg accusations.
"The main clash between the kernel maintainers and the systemd maintainers was over systemd reading the kernel argv in an error prone way to trigger debug information."
Searching the LKML for systemd seems to indicate otherwise. It seems like there have been a few scuffles over the years. I don't subscribe to the LKML or read it religiously and haven't for many years, so I'm mostly guessing based on context, but the context seems clear to me.
Again, I ask, if not systemd, then which init is Linus talking about?
(Disclaimer: I hate systemd)
The issue isn't him not knowing what systemd is, or not knowing that that is the init system Linus is talking about. He is aware of both.
His issue is with your claim that systemd has broken userspace. You haven't seemed to provide any evidence of this being the case.
The issue isn't him not knowing what systemd is, or not knowing that that is the init system Linus is talking about. He is aware of both.
His issue is with your claim that systemd has broken userspace. You haven't seemed to provide any evidence of this being the case.
We may simply be using different terminology. systemd has had bugs (a lot of them), many of which impacted the system at a high level (being the init and everything else), sometimes due to ineractions with the kernel, sometimes due to interactions with other parts of the system. Perhaps others wouldn't call that "userspace", I dunno. I figure if it affects users trying to run software it's "userspace".
But, I'm happy to take the "broke userspace" assertion back if you don't like the term. Let's just say systemd has had a lot of bugs, sometimes stupid ones, and sometimes stubbornly held on to despite kernel devs or other devs asking for changes. I would hope we're not arguing about whether systemd has had an exciting number of bugs and compatibility issues (I think we can all agree on that, even if we like systemd).
I inferred a bunch from my recollection of how the LKML has talked about systemd in the past. I assumed Linus was talking about systemd and that when he says he doesn't trust it, it was about systemd being sloppy and stubborn about compatibility and fixing bugs. I could be wrong about that.
But, I'm happy to take the "broke userspace" assertion back if you don't like the term. Let's just say systemd has had a lot of bugs, sometimes stupid ones, and sometimes stubbornly held on to despite kernel devs or other devs asking for changes. I would hope we're not arguing about whether systemd has had an exciting number of bugs and compatibility issues (I think we can all agree on that, even if we like systemd).
I inferred a bunch from my recollection of how the LKML has talked about systemd in the past. I assumed Linus was talking about systemd and that when he says he doesn't trust it, it was about systemd being sloppy and stubborn about compatibility and fixing bugs. I could be wrong about that.
Linus is generally very specific when he talks about things breaking userspace - changes to the kernel should not make things that work in userspace stop working.
systemd doesn't really have the power to completely break userspace in the manner Linus refers to, though it certainly has the power to break a system.
(One of my favorites was when a systemd update shut down dhclient but did not restart it, so once dhcp leases expired, servers lost connectivity. It was fun seeing several thousand machines go offline all at once. "Fun.")
systemd doesn't really have the power to completely break userspace in the manner Linus refers to, though it certainly has the power to break a system.
(One of my favorites was when a systemd update shut down dhclient but did not restart it, so once dhcp leases expired, servers lost connectivity. It was fun seeing several thousand machines go offline all at once. "Fun.")
You're right. I should be more careful about language. When talking about kernel developers, they do usually mean the ABI.
But Linus wasn't the one who wrote about breaking userspace here, so Linus' use of that term is irrelevant.
It's a term of art -- one defined by Linus and the kernel team over the past 25+ years. People who have been involved in one way or another with kernel development know what it means, and it makes little sense to redefine it here.
English is defined by usage, and whether or not it make "little sense" to you, if people use it differently and makes it clear they mean it differently, it makes even less sense to try to belabour the point based on a different definition.
Userspace programs that others frequently depend on the behavior of can easily break userspace. Look how many things break when you change ps or ls out with another tool.
systemd changed the way it worked with autofs, and broke userspace. They added a workaround, rather than trying to work with how the kernel already worked. (Which was highly controversial at the time.)[0]
And the systemd opinion on breaking userspace[1] is that compatibility doesn't need to be maintained:
>> The kernel's policy is "don't break userspace" - isn't the init(1) equivalent "don't break the rest of userspace"?
> No it isn't. We need to break things where progress in the base OS is more worth than compatibility.
[0] https://lists.freedesktop.org/archives/systemd-devel/2011-Se...
[1] https://lists.freedesktop.org/archives/systemd-devel/2014-Ja...
And the systemd opinion on breaking userspace[1] is that compatibility doesn't need to be maintained:
>> The kernel's policy is "don't break userspace" - isn't the init(1) equivalent "don't break the rest of userspace"?
> No it isn't. We need to break things where progress in the base OS is more worth than compatibility.
[0] https://lists.freedesktop.org/archives/systemd-devel/2011-Se...
[1] https://lists.freedesktop.org/archives/systemd-devel/2014-Ja...
> How, exactly, has systemd "broken user space"?
userspace was working, systemd got an update, userspace now not working.
userspace was working, systemd got an update, userspace now not working.
systemd hasn't broken userspace, but it regularly breaks programs that make the (bad) decision to use it's D-Bus APIs. If you've ever tried to interact with systemd's TransientUnits you know exactly what I mean.
runc has been broken many, many, many times by systemd.
runc has been broken many, many, many times by systemd.
So when my computer fails to boot following a system update due a change in how fstab is handled, isn't that a broken userspace ?
It's a broken system. I never said systemd doesn't break systems. "Breaking userspace" has a very specific meaning in this context, and it's when a kernel API changes such that an existing program no longer works on the new API. systemd is not part of the kernel so it doesn't dictate kernel APIs.
I agree with your dislike of systemd, I disagree with the term you used.
By your argument, whenever any program used by anything else has a bug, that's breaking userspace -- which defeats the "userspace" qualifier if every breakage is breaking userspace.
I agree with your dislike of systemd, I disagree with the term you used.
By your argument, whenever any program used by anything else has a bug, that's breaking userspace -- which defeats the "userspace" qualifier if every breakage is breaking userspace.
Well, pulseaudio is still pretty crap as far as I'm concerned. After an update last week Spotify won't work anymore and the sound in Firefox is glitchy. I haven't taken the time to investigate what caused that exactly, and I'm not exactly looking forward to it.
Not that I was a huge fan of ALSA either. It always felt a bit over-engineered for my taste. I can understand needing something like that if you want to make professional audio equipment with the Linux kernel but for my desktop use case OSS has always worked just fine for me and it didn't randomly break after an update.
As for systemd, it's bearable and it mostly does what it's supposed to do, but it still feels a bit unnecessary and its security track record is not stellar so far. I prefer the simplicity of the BSD init personally.
Not that I was a huge fan of ALSA either. It always felt a bit over-engineered for my taste. I can understand needing something like that if you want to make professional audio equipment with the Linux kernel but for my desktop use case OSS has always worked just fine for me and it didn't randomly break after an update.
As for systemd, it's bearable and it mostly does what it's supposed to do, but it still feels a bit unnecessary and its security track record is not stellar so far. I prefer the simplicity of the BSD init personally.
Seems to have settled down now(?) but firefox audio was def glitchy for a few releases after for me requiring system restarts to get sound back.
I still hear a friend complain he often has to restart pulse because sound just stops working for him. And IIRC there is still no way to set the maximum amount of audio-buffer (for the end-user, not from the applications; some people prefer the occasional buffer under-run over the higher delay).
Its nothing to do with "release early and often", its gems like this that they refuse to fix over ridiculous hubris.
https://github.com/systemd/systemd/issues/6237
Its going to end up exactly like glibc under Drepper, where distributions are forced to have a mile of patches because obviously broken shit isn't patched because the maintainers are too arrogant to admit fault.
https://github.com/systemd/systemd/issues/6237
Its going to end up exactly like glibc under Drepper, where distributions are forced to have a mile of patches because obviously broken shit isn't patched because the maintainers are too arrogant to admit fault.
Every time I read systemd bug reports I feel like banging my head on my desk.
Does "they refuse to fix" include systemd developer Zbigniew Jędrzejewski-Szmek and xyr proposed fix?
* https://github.com/systemd/systemd/pull/6300
* https://github.com/systemd/systemd/pull/6300
I dont see any signs of "refuse to fix" there. I see a calm and reasonable discussion and an acknowledgement that some things need improving. Perhaps they refused to fix it in exactly the way the reporter wanted, but that's a far cry from arrogant refusal.
Even if we accept their username definition, when a problem is detected (User= fails validation), the system shouldn't run the service as root (ignoring the user's clear intention to run as some specific UID).
The problem isn't the format of the usernames, it's that they detected an error, then ignored that the error happened while doing the opposite of what the user wanted. Failing the unit with an error would have been fine. Alternatively, proceeding with the indicated setuid(2) while warning about an invalid username would is also a sane response.
The problem isn't the format of the usernames, it's that they detected an error, then ignored that the error happened while doing the opposite of what the user wanted. Failing the unit with an error would have been fine. Alternatively, proceeding with the indicated setuid(2) while warning about an invalid username would is also a sane response.
What I saw was poettering spouting garbage about what he thinks is an invalid user name (when in reality, it is not and common tools like useradd don't complain about it).
As the owner for a critical service like systemd (I don't use it, I prefer openRC on gentoo), he should know better.
As the owner for a critical service like systemd (I don't use it, I prefer openRC on gentoo), he should know better.
grrr... your init system should not dictate what a valid username is. Your init system should use whatever users you've configured.
I don't like your name. Therefore you get root.
How on earth did this init system become so prevalent?
I don't like your name. Therefore you get root.
How on earth did this init system become so prevalent?
There was a whole hoo-hah in Debian over what to replace System 5 rc with: upstart, OpenRC, systemd, or something else. It got raised to the Technical Committee, sparked several resignations, went to a vote of the entire Debian Developer membership, and lasted for a long time.
* http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html
The Arch process was rather different:
* https://news.ycombinator.com/item?id=11834348
The Debian people did look at who develops the various systems, but they mainly just measured the developer count and what else was on each bandwagon. (See section 3.3 in Russ Allbery's evaluation, for example.) They didn't make any deeper evaluation extending to things such as the way that bugs got responded to in practice or what design steps people were taking to limit bugs.
Neither process was extensive enough to have spotted a User=0pointer gives superuser rights bug.
* http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html
The Arch process was rather different:
* https://news.ycombinator.com/item?id=11834348
The Debian people did look at who develops the various systems, but they mainly just measured the developer count and what else was on each bandwagon. (See section 3.3 in Russ Allbery's evaluation, for example.) They didn't make any deeper evaluation extending to things such as the way that bugs got responded to in practice or what design steps people were taking to limit bugs.
Neither process was extensive enough to have spotted a User=0pointer gives superuser rights bug.
I was just venting... and you provided a great answer to my rhetorical question - which I found very interesting by the way.
I didn't see Russ' evaluation, but I get the point.
I didn't see Russ' evaluation, but I get the point.
> your init system should not dictate what a valid username is
systemd is a task manager (which happens to manage init along with everything else it can and often cannot). Referring to systemd as an init system is just muddying well-tread waters by people who are lazily misunderstanding the technical issues. The problem with usernames is that there is no standard so schemes are OS specific. It's not really a systemd problem at the core. The systemd problem (because it almost always is badly implemented) is that it uses it's own username validation scheme that defaults to permissive root when the systemd scheme is not matched for configured services. Running on top of heterogeneous environments, you get inconsistent behavior (even when you comply with the OS). This would be like apache spawning handler threads as root if it doesn't like the username it's configured to run as, regardless if the username is valid under OSX and invalid under Fedora. Too bad, username schemes are now dictated by systemd, is Poettering's position.
systemd is a task manager (which happens to manage init along with everything else it can and often cannot). Referring to systemd as an init system is just muddying well-tread waters by people who are lazily misunderstanding the technical issues. The problem with usernames is that there is no standard so schemes are OS specific. It's not really a systemd problem at the core. The systemd problem (because it almost always is badly implemented) is that it uses it's own username validation scheme that defaults to permissive root when the systemd scheme is not matched for configured services. Running on top of heterogeneous environments, you get inconsistent behavior (even when you comply with the OS). This would be like apache spawning handler threads as root if it doesn't like the username it's configured to run as, regardless if the username is valid under OSX and invalid under Fedora. Too bad, username schemes are now dictated by systemd, is Poettering's position.
The problem with usernames is that there is no standard
Yes there is: https://github.com/systemd/systemd/issues/6237#issuecomment-...
Yes there is: https://github.com/systemd/systemd/issues/6237#issuecomment-...
I'll just say that I strongly disagree. Pointing to the IEEE compatibility standard is being misleading. That's part of a standard and is not adequately inclusive to be considered "the standard". OS's that systemd supports do not all follow the POSIX standard. i.e. "not officially certified as POSIX compatible, comply in large part". Practically, this means some are more strict and other less so.
In regard to usernames, I can definitely forgive Poettering's initial failure in design to confusion. His assertion that he is following "the standard" fails on both a practical and logical level.
In regard to usernames, I can definitely forgive Poettering's initial failure in design to confusion. His assertion that he is following "the standard" fails on both a practical and logical level.
I am having a very hard time following your logic. You made an assertion about there being no standard for usernames. I pointed you to some info someone wrote in the relevant issue on Github regarding what POSIX asserts usernames should conform to, with POSIX being generally accepted to be a standard for *nix type OS's. Your response appears to boil down to "But POSIX doesn't count because not all distro's are POSIX certified"
POSIX counts, for POSIX systems. There is no standard for systemd supported systems. The logic is straightforward, like the reality.
> yes, it's a feature that we don't permit invalid user names(...) So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but still: the username is clearly not valid.
> systemd is not the one coming up with the restrictions on user names, and while some distributions are less restrictive, many do enforce the same restrictions as we do. In order to make systemd unit files portable between systems we'll hence enforce something that resembles more the universally accepted set, rather than accept the most liberal set possible.
These are pretty clear "refuse to fix". Though I do agree that this is a poor example to illustrate the point.
> systemd is not the one coming up with the restrictions on user names, and while some distributions are less restrictive, many do enforce the same restrictions as we do. In order to make systemd unit files portable between systems we'll hence enforce something that resembles more the universally accepted set, rather than accept the most liberal set possible.
These are pretty clear "refuse to fix". Though I do agree that this is a poor example to illustrate the point.
I would assume this is about systemd. Personally my experience with it has been great - the occasional screw-ups (they did happen - something related to dbus made all systemctl commands fail until a reboot) were nothing compared to the time I gained not having to worry about prehistoric initscripts
There is a vast gulf between two communities, people who run Ubuntu Beta for fun on their own PC, and people who run 10,000 RHEL boxes in Prod, and both communities tend to talk "at" each other and misunderstand where the other is coming from.
The scenario you describe is something that would make one of the latter community recoil in horror.
There is a vast gulf between two communities, people who run Ubuntu Beta for fun on their own PC, and people who run 10,000 RHEL boxes in Prod, and both communities tend to talk "at" each other and misunderstand where the other is coming from.
The scenario you describe is something that would make one of the latter community recoil in horror.
There's a third, rather small community: the distro-makers, who nearly to a one are—if not in love—at least hold systemd in high regard.
It's easy enough to understand their point of view: run through a Linux From Scratch install. You'll have to write your own init system. You'll be duct-taping a lot of things together, and your solution—while it might be something you're "proud of" in some sense—will definitely be lacking in engineering, no matter how much time you as one individual could ever throw at it.
After the LFS experience—which is essentially the distro creation experience—coming back to regular (pre-systemd) distros made one feel rather different: it was very easy to see how each distro was, at its core, just someone else's duct-taped-together init system with a pile of hacks accumulated on top. There wasn't any real Engineering; there was no shared knowledge-base of best practices for doing this or that. Each distro was a evolutionary Galapagos island.
From the LFS perspective, an init system that exists as its own standalone FOSS project, containing contributions from hundreds of interested parties and battle-tested engineering choices after coming-up-on-a-decade of use in virtually every scenario, is a wonderful thing. systemd is, finally, a reference implementation of an init system "at scale." If you want to build your own init system, you don't have to look at the init systems of 30 different distros to figure out what things each distro just did its own way for no reason, any more (which used to be "most things.") You can just start by looking at "what systemd does", and figure things out from there. Or you can use some systemd components, and some of your own.
It's easy enough to understand their point of view: run through a Linux From Scratch install. You'll have to write your own init system. You'll be duct-taping a lot of things together, and your solution—while it might be something you're "proud of" in some sense—will definitely be lacking in engineering, no matter how much time you as one individual could ever throw at it.
After the LFS experience—which is essentially the distro creation experience—coming back to regular (pre-systemd) distros made one feel rather different: it was very easy to see how each distro was, at its core, just someone else's duct-taped-together init system with a pile of hacks accumulated on top. There wasn't any real Engineering; there was no shared knowledge-base of best practices for doing this or that. Each distro was a evolutionary Galapagos island.
From the LFS perspective, an init system that exists as its own standalone FOSS project, containing contributions from hundreds of interested parties and battle-tested engineering choices after coming-up-on-a-decade of use in virtually every scenario, is a wonderful thing. systemd is, finally, a reference implementation of an init system "at scale." If you want to build your own init system, you don't have to look at the init systems of 30 different distros to figure out what things each distro just did its own way for no reason, any more (which used to be "most things.") You can just start by looking at "what systemd does", and figure things out from there. Or you can use some systemd components, and some of your own.
> There's a third, rather small community: the distro-makers, who nearly to a one are—if not in love—at least hold systemd in high regard.
I work on a distribution (openSUSE) and don't hold systemd in high regard. There are many people who work for distributions and don't feel that way. Of course, the general openSUSE community decided to go with systemd, but it's not fair to claim that everyone who contributes to distributions that use systemd must therefore like systemd.
The reason I don't like systemd is that in my experience, systemd forces you to integrate system management programs (such as container runtimes) with systemd. And when you are forced to integrate, systemd then causes you nothing but issues. cgroups are a perfect example of this. In addition, systemd doesn't obey SIGPWR and as a result LXC has to write special code for systemd -- which is just ludicrous.
I've talked to some other people from other distributions and they feel so strongly against this that it's possible you'll see a new init system in a few years that rectifies the problems with systemd.
> an init system that exists as its own standalone FOSS project, containing contributions from hundreds of interested parties and battle-tested engineering choices after coming-up-on-a-decade of use in virtually every scenario, is a wonderful thing
There are several things wrong with that description of systemd. To be clear, the pre-systemd init systems were also horrible. The original idea of systemd which was a declarative and parallel init system was a good idea. The problem is that systemd has far out-grown being just an init, and it has been shown historically that it is far from "battle-tested engineering" (with the additional note that the maintainers are strongly against people allocating CVEs for their project).
I work on a distribution (openSUSE) and don't hold systemd in high regard. There are many people who work for distributions and don't feel that way. Of course, the general openSUSE community decided to go with systemd, but it's not fair to claim that everyone who contributes to distributions that use systemd must therefore like systemd.
The reason I don't like systemd is that in my experience, systemd forces you to integrate system management programs (such as container runtimes) with systemd. And when you are forced to integrate, systemd then causes you nothing but issues. cgroups are a perfect example of this. In addition, systemd doesn't obey SIGPWR and as a result LXC has to write special code for systemd -- which is just ludicrous.
I've talked to some other people from other distributions and they feel so strongly against this that it's possible you'll see a new init system in a few years that rectifies the problems with systemd.
> an init system that exists as its own standalone FOSS project, containing contributions from hundreds of interested parties and battle-tested engineering choices after coming-up-on-a-decade of use in virtually every scenario, is a wonderful thing
There are several things wrong with that description of systemd. To be clear, the pre-systemd init systems were also horrible. The original idea of systemd which was a declarative and parallel init system was a good idea. The problem is that systemd has far out-grown being just an init, and it has been shown historically that it is far from "battle-tested engineering" (with the additional note that the maintainers are strongly against people allocating CVEs for their project).
Competition for declarative and parallel init systems would be good, but I slightly doubt that it will stay that way. The whole conflict feels very similar to the idea of declarative and dependency based initramfs, where for a long time there was basically only initramfs-tools in debian that had it, with everyone else just using a hard coded and very long shell script. If we like to talk about init shell scripts as something people avoid to touch, its nothing compared to the dark magic and undocumented mess that went on in the initramfs shell script.
Several years ago Red Hat decided they also wanted something like initramfs-tools but which themselves had developed (a remark I recall that the developers made on the mailing list), so they built a new system called dracut that models very close to initramfs-tools, in which Debian's response seems to be: "Great, someone else want to support that complex tangle of dark magic, let's use theirs!", so instead of competition I suspect things will return to a monoculture again. A good thing is that during all this, distributions like openSUSE has also switched over to dracut which hopefully shows a trend that the age of large shell scripts in the boot process seems to be over.
Several years ago Red Hat decided they also wanted something like initramfs-tools but which themselves had developed (a remark I recall that the developers made on the mailing list), so they built a new system called dracut that models very close to initramfs-tools, in which Debian's response seems to be: "Great, someone else want to support that complex tangle of dark magic, let's use theirs!", so instead of competition I suspect things will return to a monoculture again. A good thing is that during all this, distributions like openSUSE has also switched over to dracut which hopefully shows a trend that the age of large shell scripts in the boot process seems to be over.
If one pays attention to SystemD bugs, it is pretty clear that SystemD is sorely lacking in engineering.
> There's a third, rather small community: the distro-makers, who nearly to a one are—if not in love—at least hold systemd in high regard.
I'm a distro-maker (Exherbo) and while we provide the option for systemd I wouldn't say anyone is exactly thrilled by it. Users use a variety of init systems including handrolled ones, and that choice is the users'. But we recognize it as the sensible current default and is too much effort to work against the grain here.
I'm a distro-maker (Exherbo) and while we provide the option for systemd I wouldn't say anyone is exactly thrilled by it. Users use a variety of init systems including handrolled ones, and that choice is the users'. But we recognize it as the sensible current default and is too much effort to work against the grain here.
I'm a distro maker (closed source Linux distribution) and I don't use systemd, as doing so would add significant non-determinism to what is an otherwise deterministic process.
Linux From Scratch has been one of the most stable and problem free systems I have used.
It does take a lot of time, but one is protected from a lot of distribution nonsense.
It does take a lot of time, but one is protected from a lot of distribution nonsense.
RHEL users can countinue to run systemd in production without disrupting the rest of the comunity with an init that goes beyond its scope.
Because the latter community enjoys a hodgepodge of scripts doing arbitrary things instead of a standardized well organized mechanism?
How much time do you think a member of the latter group spend on init scripts?
When I did that job, I would estimate maybe one day a year at most. But core functions just stopping working and no one knows why would have been a very big deal
When I did that job, I would estimate maybe one day a year at most. But core functions just stopping working and no one knows why would have been a very big deal
Perhaps. But then again, the RHEL people really need many of the features SystemD offers. The Ubuntu Beta people can keep running init if they must.
The Ubuntu people, like the Fedora people, used Upstart before they switched to systemd. You make the far too common error of thinking that only systemd and System 5 init/rc exist.
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Upstart had some really nasty gotchas too, but at least was limited in scope. It'll be interesting to see if we ever move from CentOS to FreeBSD to get away from the horror show that is systemd.
If your applications run on FreeBSD I would make the switch, but most originations need better reasons for switching. Have you ever had downtime associated with Systemd or Missed deadlines? Thats the only way I could think of that might justify the switch.
Honest question: I'm not familiar with FreeBSD, what init system does it use and why isn't it a horror?
FreeBSD uses FreeBSD init and Mewburn rc. Mewburn rc is somewhat different to van Smoorenburg rc. It has a huge library of standard shell script functions, and the actual rc files that ship with the operating system, and accompany packages, sometimes boil down to a few shell variable assignments and then an invocation of one of the shell library functions that does everything. This is not universally the case, however, and there are some giant exceptions.
Now read https://news.ycombinator.com/item?id=11550802 and https://news.ycombinator.com/item?id=10357589 . (The mentioned van Smoorenburg rc script has since moved to https://github.com/dun/conman/blob/master/etc/conman.init.in .)
The TrueOS people have replaced Mewburn rc with OpenRC, retaining the FreeBSD init as far as I am aware. I suggested to them back in January 2017 that since OpenRC has s6 integration, they might do well to add s6 to that to gain full service management. I never received a reply. I haven't heard that Laurent Bercot was contacted, either.
* https://news.ycombinator.com/item?id=13458186
* http://www.mail-archive.com/[email protected]/msg...
I personally use the nosh system and service managers on FreeBSD and TrueOS, of course. I released version 1.34 last week.
Now read https://news.ycombinator.com/item?id=11550802 and https://news.ycombinator.com/item?id=10357589 . (The mentioned van Smoorenburg rc script has since moved to https://github.com/dun/conman/blob/master/etc/conman.init.in .)
The TrueOS people have replaced Mewburn rc with OpenRC, retaining the FreeBSD init as far as I am aware. I suggested to them back in January 2017 that since OpenRC has s6 integration, they might do well to add s6 to that to gain full service management. I never received a reply. I haven't heard that Laurent Bercot was contacted, either.
* https://news.ycombinator.com/item?id=13458186
* http://www.mail-archive.com/[email protected]/msg...
I personally use the nosh system and service managers on FreeBSD and TrueOS, of course. I released version 1.34 last week.
The biggest advantage is that its init system is just an init system. Systemd is so far beyond the scope of an init system it's not even funny.
My problem with systemd is that is seems to have a policy (most certainly a history of actions, and that's really the significant thing) of NOT doing the sane thing, then being called out for it, and then having the systemd people defend not doing the right thing.
I can trust someone who makes mistakes. I can't trust someone who refuses to accept that they regularly make mistakes. Nor can I trust their work.
I can trust someone who makes mistakes. I can't trust someone who refuses to accept that they regularly make mistakes. Nor can I trust their work.
> If you are worried about stability then you shouldn't rely on a single machine anyway.
Sorry, this is a complete BS "solution"
You don't keep a broken piece of software running then put more redundancy to make it kinda stable.
Redundancies are for when things break, not for when they're broken from the start
Nobody takes off from a plane with one inoperative engine, both have to be turning, so in case one fails the other one can take over
Sorry, this is a complete BS "solution"
You don't keep a broken piece of software running then put more redundancy to make it kinda stable.
Redundancies are for when things break, not for when they're broken from the start
Nobody takes off from a plane with one inoperative engine, both have to be turning, so in case one fails the other one can take over
Effectively what you are responding to is the ever more prevailing "cloud" mentality, where there is always another instance to spin up in a second if something where to break.
http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...
And while systemd may have started on the desktop (likely to "solve" the speed of repeated bootups when using a laptop "securely") increasingly its development is dictated by this cloud mentality (as is the development of various distros, as someone basically shouted to my virtual face over at LWN).
http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...
And while systemd may have started on the desktop (likely to "solve" the speed of repeated bootups when using a laptop "securely") increasingly its development is dictated by this cloud mentality (as is the development of various distros, as someone basically shouted to my virtual face over at LWN).
They're not really following the philosophy I expect to see a unix-like OS, so my experience also wasn't great. Like turning logs into a binary format, and then later bugging out on it so when you try to read it with their convoluted command (where cat or less was sufficient in the past) it gave errors on its own mess and refused to display anything.
Bugs happen, that's understandable, but simply the fact that they turn logs into a binary format shows their philosophy is different than the one I expect from a unix-like OS.
And almost all distros are following them sadly...
Bugs happen, that's understandable, but simply the fact that they turn logs into a binary format shows their philosophy is different than the one I expect from a unix-like OS.
And almost all distros are following them sadly...
Any reason why we can't have journaldfs?
I could imagine that Linus is also influenced by experiences such as [1][2]. After a couple of issues like that I can imagine that he has his doubts about some of systemd's behavior.
[1]: https://bugs.freedesktop.org/show_bug.cgi?id=76935
[2]: https://lkml.org/lkml/2014/4/2/420
[1]: https://bugs.freedesktop.org/show_bug.cgi?id=76935
[2]: https://lkml.org/lkml/2014/4/2/420
this is all nice when you ignore the tons of bug reports everyone else is getting because you decided to treat your users as testers.
why do you think linus is complaining? because he can't get sound to work on his own box or because kernel invalid bugs are over the roof thanks to bogus init?
why do you think linus is complaining? because he can't get sound to work on his own box or because kernel invalid bugs are over the roof thanks to bogus init?
systemd has a few nice ideas, and it might be alright for whatever your use case is. I'm working on a product which uses it as its init system, and it's an endless source of problems. Its flaws are deep and unfortunately pervasive.
As a user, I would agree, systemd kinda just works and it's nice.
As a sysadmin however, I hate it so much. Not because I have to learn a new system which is nice, but because it breaks so much things. I had to rewrite scripts that just worked for years, I had to do a bit of black magic to make old software behave on newer distribs and it's just so frustrating. I get it that most of these things were not done in the right way but FFS, don't break my production stuff.
As a sysadmin however, I hate it so much. Not because I have to learn a new system which is nice, but because it breaks so much things. I had to rewrite scripts that just worked for years, I had to do a bit of black magic to make old software behave on newer distribs and it's just so frustrating. I get it that most of these things were not done in the right way but FFS, don't break my production stuff.
Oh yes, the init to systemd phase was brutal on arch. So many broken systems :(
Here's something I don't understand... Why do so many people hate systemd but not macOS's launchd [0]? Don't they serve similar purposes? I've been digging into macOS for a few months now, and I'm pretty happy with their defaults.
EDIT: I don't know why I'm being downvoted for asking a genuine question. I'm not a linux expert, so I'd love to hear your criticisms.
[0] http://www.launchd.info
EDIT: I don't know why I'm being downvoted for asking a genuine question. I'm not a linux expert, so I'd love to hear your criticisms.
[0] http://www.launchd.info
The use of non-executing service definition files isn't really the problem with systemd - it's one of the parts I actually like.
The problem is more about the project itself. The scope keeps creeping to consume more and more things. The developers have a "we know better, do it this way, your argument is irrelevant" type attitude to outsiders.
The problem is more about the project itself. The scope keeps creeping to consume more and more things. The developers have a "we know better, do it this way, your argument is irrelevant" type attitude to outsiders.
Indeed your last argument is my beef with systemd as well. I describe it as:
"Systemd is great! But it's an inconsiderate piece of software!"
Meaning it work nice, it does it's job it does it fast. But if you want to things your way, or want to run something not-systemd standard, you are in for some fun.
"Systemd is great! But it's an inconsiderate piece of software!"
Meaning it work nice, it does it's job it does it fast. But if you want to things your way, or want to run something not-systemd standard, you are in for some fun.
I've worked with launchd, and I hate it more than systemd. Most of it is because of launchd's atrocious doc. Note that launchd was rewritten a few versions ago for Reasons [1]. I couldn't find any release notes that highlighted this, and you wouldn't know it from launchd's version number...
Thing is, launchd's developers made a good effort at preserving backwards compatibility, but it's far from perfect. And most online docs (such as launchd.info that you're linking to) is subtly out-of-date. For example, I see no mention of "service-targets": new launchd learned about "bootstrap domains" (huh?), which are namespaces implemented at the Mach (macOS kernel) level. It's not a Unixy thing. Trick question: how do you define a user job that runs in the background even when the user's not logged in? How do you define a user job that runs if the user logged in via SSH (ie not GUI)?
It's late and I'm tired, I can try being more coherent tomorrow. There are some good sources of information hidden out there, but the first few Google responses are woefully obsolete. And fuck Apple's own docs.
[1] I'm not sure what the reasons are, but I suspect for a) merging iOS and macOS functionality and b) tightly integrating it with the kernel's XPC interprocess comms infrastructure (again, for iOS?)
Thing is, launchd's developers made a good effort at preserving backwards compatibility, but it's far from perfect. And most online docs (such as launchd.info that you're linking to) is subtly out-of-date. For example, I see no mention of "service-targets": new launchd learned about "bootstrap domains" (huh?), which are namespaces implemented at the Mach (macOS kernel) level. It's not a Unixy thing. Trick question: how do you define a user job that runs in the background even when the user's not logged in? How do you define a user job that runs if the user logged in via SSH (ie not GUI)?
It's late and I'm tired, I can try being more coherent tomorrow. There are some good sources of information hidden out there, but the first few Google responses are woefully obsolete. And fuck Apple's own docs.
[1] I'm not sure what the reasons are, but I suspect for a) merging iOS and macOS functionality and b) tightly integrating it with the kernel's XPC interprocess comms infrastructure (again, for iOS?)
I'm glad to see I'm not the only one to have this experience.
I've not mucked much with OSX admin, but the times I have, it's been fairly ugly. PLISTs particularly so.
I've not mucked much with OSX admin, but the times I have, it's been fairly ugly. PLISTs particularly so.
Oh god, XML config files where order matters >_< "oh but plutil can convert them to json!" Oh but it does so in-place, so I hope you copied the file before converting it, because launchd certainly can't read JSON plists...
/facepalm
/facepalm
> Most of it is because of launchd's atrocious doc.
Really? I read up on launchd a year or so ago to setup backups and I though the documentation was amazing...Which docs are you referring to?
Really? I read up on launchd a year or so ago to setup backups and I though the documentation was amazing...Which docs are you referring to?
The manpages for launchctl(1), launchd.plist(5), launchd(8), and Apple's online "Daemons and Services Programming Guide" (which has not been consistently updated for the new launchd)
For example, in the launchctl(1) manpage, can you elucidate what they mean for the "bootstrap" subcommand? (caveat: you're not allowed to use "bootstrap" in your definition. That's tautological).
What does "kickstart" mean? (again, tautological definition)
What's the significance of the various "domains"? What's user vs login vs gui domains? What's an "audit" session ID?
How do you reload a service's plist file?
Trick question: how do you kill your GUI by mistyping a common launchctl command? (I don't remember the command offhand, and am unwilling to experiment right now)
What does the LimitLoadToSessionType plist property do? What are the possible values?
etc...
For example, in the launchctl(1) manpage, can you elucidate what they mean for the "bootstrap" subcommand? (caveat: you're not allowed to use "bootstrap" in your definition. That's tautological).
What does "kickstart" mean? (again, tautological definition)
What's the significance of the various "domains"? What's user vs login vs gui domains? What's an "audit" session ID?
How do you reload a service's plist file?
Trick question: how do you kill your GUI by mistyping a common launchctl command? (I don't remember the command offhand, and am unwilling to experiment right now)
What does the LimitLoadToSessionType plist property do? What are the possible values?
etc...
> do you define a user job that runs in the background even when the user's not logged in?
Well, you can't. Only administrators get to define things that run when the user isn't logged in. That's an intentional decision.
> How do you define a user job that runs if the user logged in via SSH
Offhand, I don't think you can do that either, though I haven't researched this particular angle. And it would be surprising to me that SSH'ing into a machine would trigger daemons anyway.
Well, you can't. Only administrators get to define things that run when the user isn't logged in. That's an intentional decision.
> How do you define a user job that runs if the user logged in via SSH
Offhand, I don't think you can do that either, though I haven't researched this particular angle. And it would be surprising to me that SSH'ing into a machine would trigger daemons anyway.
> And it would be surprising to me that SSH'ing into a machine would trigger daemons anyway.
You might want to find out about systemd, then, which does exactly this. (-:
A PAM hook indirectly causes a per-user systemd instance to be created at login and terminated at logout, which triggers all of the per-user daemons that the account has.
If one has a user that is used for lots of little SSH sessions, hundreds of thousands of times a day, the overhead of starting up and tearing down the per-user systemd for each one, not least in terms of the log noise, becomes a serious consideration, and one has to learn the systemd mechanisms for making the user a "lingering" one.
You might want to find out about systemd, then, which does exactly this. (-:
A PAM hook indirectly causes a per-user systemd instance to be created at login and terminated at logout, which triggers all of the per-user daemons that the account has.
If one has a user that is used for lots of little SSH sessions, hundreds of thousands of times a day, the overhead of starting up and tearing down the per-user systemd for each one, not least in terms of the log noise, becomes a serious consideration, and one has to learn the systemd mechanisms for making the user a "lingering" one.
For an OS that is frequently used headless, starting up per-user daemons on SSH makes some amount of sense. macOS is designed to be primarily GUI-driven, rather than primarily used headless, so it makes more sense for macOS to avoid the issue that you describe by not supporting launching per-user daemons on SSH.
I was assuming administrative control of course. How, as the administrator, do you define such user jobs? It's not a permissions issue, its a launchd job configuration issue.
As an administrator, you can place jobs into /Library/LaunchDaemons to run always, or /Library/LaunchAgents to run per-user when a user is logged in.
>> I've worked with launchd, and I hate it more than systemd. Most of it is because of launchd's atrocious doc.
I had to do some provisioning work with NFS and pf and the docs were maddening. I never actually got VirtualBox and NFS to play nicely but once I got a couple little quirks of pf it was pretty reliable.
I had to do some provisioning work with NFS and pf and the docs were maddening. I never actually got VirtualBox and NFS to play nicely but once I got a couple little quirks of pf it was pretty reliable.
> Don't they serve similar purposes?
In theory, yes. In practice, systemd reinvents half of the rest of the system, poorly. Even to the point of shipping a half assed dns resolver and a dhcp client that doesn't even support lease renewal, and when people file bugs the invariable response is to blame the user.
In theory, yes. In practice, systemd reinvents half of the rest of the system, poorly. Even to the point of shipping a half assed dns resolver and a dhcp client that doesn't even support lease renewal, and when people file bugs the invariable response is to blame the user.
ntp client too, which at least one point had hardcoded defaults in the distribution source that gave incorrect time.
I don't even understand how someone could ship that DNS resolver, especially as the default install. It's completely broken on my systems, literally crashing on every other lookup. Nobody online seems to have a fix either, I just had to disable the thing and revert back to the old resolver.
I hate systemd because it's horribly, cancerously invasive, often messing with existing functionality that works well and replacing it with worse substitutes / duplicates.
In recent memory, off the top of my head, it messed with NTP, DNS resolution, Syslog, DHCP, Nohup/Tmux, not to speak of taking over udev so it won't run without it (thanks for eudev).
In recent memory, off the top of my head, it messed with NTP, DNS resolution, Syslog, DHCP, Nohup/Tmux, not to speak of taking over udev so it won't run without it (thanks for eudev).
> Why do so many people hate systemd but not macOS's launchd [0]?
My guess is, it's not as relevant because Mac OS isn't as widely used in servers as Linux.
My guess is, it's not as relevant because Mac OS isn't as widely used in servers as Linux.
Also, MacOS/OSX is one OS with one developer.
Systemd is effectively Freedesktop/Fedora/Gnome dictating how every last Linux distro is supposed to behave. And doing so by invasive dependency chains.
Observe how LFS now have two parallel books. One continuing the one they have maintained from the start, and another dedicated to systemd. This is a good indicator how invasive systemd is in the basic construct of a Linux distro.
Systemd is effectively Freedesktop/Fedora/Gnome dictating how every last Linux distro is supposed to behave. And doing so by invasive dependency chains.
Observe how LFS now have two parallel books. One continuing the one they have maintained from the start, and another dedicated to systemd. This is a good indicator how invasive systemd is in the basic construct of a Linux distro.
I suspect it's because nobody ever really has to touch launchd configurations because Macs aren't commonly used as Internet servers.
Anecdata: I wanted to set up a Mac box as a remote syslog server. It's running, IIRC, rsyslogd, which is to say, remote syslogd.
All you've got to do is tweak the PLIST.
Read the manages. They're out of date.
Looked at the PLIST tools (not my thing). Doesn't seem to be an option.
There used to be, back when PLISTs were actual files you could edit. That's gone away now though, best I can tell.
Got a Linux box up and running, that now accepts remote logs.
All you've got to do is tweak the PLIST.
Read the manages. They're out of date.
Looked at the PLIST tools (not my thing). Doesn't seem to be an option.
There used to be, back when PLISTs were actual files you could edit. That's gone away now though, best I can tell.
Got a Linux box up and running, that now accepts remote logs.
For future reference, you might find it helpful to read "man defaults" and "man PlistBuddy". And its binary is at /usr/libexec/PlistBuddy.
I can't say I blame you, though. Figuring out what all these tools did and what they were for required a fair amount of reading and experimenting on my end.
I can't say I blame you, though. Figuring out what all these tools did and what they were for required a fair amount of reading and experimenting on my end.
Binary plists have been around for ages, in fact they come from NeXT. But most stuff on OSX will still happily interpret XML (and now JSON) based plists just fine if need be. For all your conversion needs there's plutil.
As I said: not my area of expertise. Though the docs I was reading were suggesting that the change from file to binary had occurred after OSX was introduced.
I've been happily using macOS server at home for a few months. It's not a production-ready deployment, but I haven't had any complaints.
Aside from that, using it on my personal laptops has worked surprisingly well. Once I familiarized myself with the CLI tools, I haven't had any issues.
Aside from that, using it on my personal laptops has worked surprisingly well. Once I familiarized myself with the CLI tools, I haven't had any issues.
> I've been happily using macOS server at home for a few months. It's not a production-ready deployment, but I haven't had any complaints.
It's not on AWS. Your use case is just a hobby or one man shop or just one data point. It doesn't necessarily scale well for other use cases.
I think what other people are pointing out is that companies aren't lining up to use it or replacing it over a linux server or window server.
It's not on AWS. Your use case is just a hobby or one man shop or just one data point. It doesn't necessarily scale well for other use cases.
I think what other people are pointing out is that companies aren't lining up to use it or replacing it over a linux server or window server.
For the same reason an airline mechanic doesn't care about the location of the fuel injectors in his car, but cares very much about the location on the engines he works on all day.
I won't claim to speak for everyone here, but there's almost nothing I install third-party that I care about during the startup process (on my laptop). And even if I did, they're generally closed-source apps I can't access the source of anyway. 99% of my day-to-day usage of a laptop is with applications I'm manually starting and stopping.
I care VERY much about services automatically starting properly on a server. 99% of my day-to-day usage of a server is applications that automatically start and stop.
I won't claim to speak for everyone here, but there's almost nothing I install third-party that I care about during the startup process (on my laptop). And even if I did, they're generally closed-source apps I can't access the source of anyway. 99% of my day-to-day usage of a laptop is with applications I'm manually starting and stopping.
I care VERY much about services automatically starting properly on a server. 99% of my day-to-day usage of a server is applications that automatically start and stop.
I don't like both. While I can understand the need for complex configuration on macOS: it runs on laptops, my Linux runs strictly on server, reboots once in few weeks or months and I don't care about boot time (my BIOS boots for 5 minutes, I could care less if Linux will boot for 10 or 60 seconds) at all. Good old init with bash scripts worked wonderfully, was transparent, easy to understand, hack and extend. While I can live with systemd, it's a step in wrong direction.
Not nearly enough engineers care about MacOS at the same emotional level as Linux. People who use Mac usually don't care much about internal architecture but their actual experience while Linux users who are also developers are extremely vocal of every single component inside Linux
Or it could be that MacOS doesn't run on servers, where Things Just Have To Work. MacOS has the luxury of always having a ready pair of hands right there to fiddle with things. The people who care about systemd one way or the other are the people who care for servers.
Look upthread at the 'nohup and logout' "bug". That's not something you're going to encounter on MacOS, because it's not something you do on MacOS.
Look upthread at the 'nohup and logout' "bug". That's not something you're going to encounter on MacOS, because it's not something you do on MacOS.
I think it's more that MacOS is run on end user machines where the defaults are just fine. As long as you don't have to fiddle with it launchd generally stays out of the way. If you start trying to get fancy you quickly find yourself in plist hell and brick walls of "Apple doesn't think this is a valid use case, so it is impossible".
Not sure why you think people don't dislike launchd.
The problem with systemd was that there was potential to be better; the idea is good but the core developers reek of hubris.
Launchd is OSX, and osx has some horrors but that's ok because they're desktop systems and you don't work on fleets of thousands of them usually.
There was a time where Apple were threatening to upstream it to FreeBSD- but aside from that I think the consensus is that launchd is quite horrible too. It's just systemd could have been so much better and not tried to gobble up the entire Linux ecosystem.
The problem with systemd was that there was potential to be better; the idea is good but the core developers reek of hubris.
Launchd is OSX, and osx has some horrors but that's ok because they're desktop systems and you don't work on fleets of thousands of them usually.
There was a time where Apple were threatening to upstream it to FreeBSD- but aside from that I think the consensus is that launchd is quite horrible too. It's just systemd could have been so much better and not tried to gobble up the entire Linux ecosystem.
For me the problem with SystemD is that it seems to be trying to make Linux run like Windows.
If you are running in a generic "This is my machine and I just did the normal install for a regular use case then everything works" it seems great. But the instant you try to do something a little out of the ordinary it becomes a absolute nightmare of opaque message passing interfaces and hours on Google.
A few examples: 1. In the old days you could network boot a machine with a kernel compiled with a couple of flags turned on and an NFS share. SystemD systems can be network booted, but you're going to spend a lot of time poring over obscure forums finding all of the tweaks you need to make, and it will be a lot slower and toss up error messages for things like UUIDs changing on different systems.
2. If you want to have the wireless card change MAC addresses before it connects for slightly improved anonymity at public hotspots, you had better be willing to upgrade to the bleeding edge. NetworkManager broke the existing solutions for doing this and implemented it's own model, but it required a version of wpa_supplicant that was never really released so you had to build it yourself from a snapshot and install it and tell your distro not to update it. The SystemD devs got tired of waiting for the wpa_supplicant devs to release the new version so they moved the functionality into their code. At the same time they pulled in the DNS resolver but broke it so it crashes on literally every other name lookup.
3. NetworkManager pulled in OpenVPN support as an option. It's awesome when it works, but when it dies it refuses to give you any sort of clue as to why the connection didn't work. You just get a generic "it failed" message like in Windows. Not "Authentication Failed", "Cannot connect to Server", or "Clocks unsynchronized", not even a cryptic error code. Every single error results in just a generic message and you have to either hope the logs have something useful or more often you have to fire up Wireshark and inspect the authentication exchange by hand to figure out what is up.
Lord help you if you find yourself with a machine that hangs at boot because some process didn't receive some message it was expecting and now you have to figure out who was supposed to send that message and why they didn't send it. This isn't the old days where you could trace shell scripts to figure out where the problem was, now you have to know the whole thing before you can fix anything.
And don't get me started about moving the syslog into some binary database thing that you can't grep without going through some export process.
If you are running in a generic "This is my machine and I just did the normal install for a regular use case then everything works" it seems great. But the instant you try to do something a little out of the ordinary it becomes a absolute nightmare of opaque message passing interfaces and hours on Google.
A few examples: 1. In the old days you could network boot a machine with a kernel compiled with a couple of flags turned on and an NFS share. SystemD systems can be network booted, but you're going to spend a lot of time poring over obscure forums finding all of the tweaks you need to make, and it will be a lot slower and toss up error messages for things like UUIDs changing on different systems.
2. If you want to have the wireless card change MAC addresses before it connects for slightly improved anonymity at public hotspots, you had better be willing to upgrade to the bleeding edge. NetworkManager broke the existing solutions for doing this and implemented it's own model, but it required a version of wpa_supplicant that was never really released so you had to build it yourself from a snapshot and install it and tell your distro not to update it. The SystemD devs got tired of waiting for the wpa_supplicant devs to release the new version so they moved the functionality into their code. At the same time they pulled in the DNS resolver but broke it so it crashes on literally every other name lookup.
3. NetworkManager pulled in OpenVPN support as an option. It's awesome when it works, but when it dies it refuses to give you any sort of clue as to why the connection didn't work. You just get a generic "it failed" message like in Windows. Not "Authentication Failed", "Cannot connect to Server", or "Clocks unsynchronized", not even a cryptic error code. Every single error results in just a generic message and you have to either hope the logs have something useful or more often you have to fire up Wireshark and inspect the authentication exchange by hand to figure out what is up.
Lord help you if you find yourself with a machine that hangs at boot because some process didn't receive some message it was expecting and now you have to figure out who was supposed to send that message and why they didn't send it. This isn't the old days where you could trace shell scripts to figure out where the problem was, now you have to know the whole thing before you can fix anything.
And don't get me started about moving the syslog into some binary database thing that you can't grep without going through some export process.
Every init system ever invented has been criticized. That's why there are so many of them.
Having worked with inits of BSD, sysv, upstart, systemd, and launchd varieties, I strongly prefer the administrative and debug capabilities of the script-oriented ones.
BSD's choice to drop everything into a single rc file is not particularly elegant, but it can be coerced to do what you want. The sysvinit user interface, frankly, isn't bad:
I'll add that my distro of choice is Debian (or derivatives, which I generally mean here). One thing that I noticed when first switching to Debian, back in the mid 1990s, was that its init scripts were vastly easier to follow than Red Hat's. Debian has a fairly standard structure (/etc/init.d/skeleton is the bare-bones template), and most scripts follow that within some reason. There are a few exceptions -- scripts which initialise things (bootclean, mount, networking) rather than start services, tend not to look like service initialisation scripts, on the inside. On the outside, though, they do.
Further: once configured properly, those scripts don't change. Debian in particular does an extraordinarily good job of extracting out all necessary configuration to an /etc/ configfile (which it then won't touch unless you specifically tell it to).
My experience on MacOS (see elsewhere in this thread) is that stuff which ought be easy isn't. My experience with systemd, to date, hasn't evidenced this, as I am largely using the extant sysvinit scripts. But I've noticed numerous things Wot Used To Work ... do not. And the response from the sysvinit devs, particularly from the top, as well as various sycophants on numerous fora, has been exceedingly disturbing.
Case in point, my single most controversial Reddit comment:
https://www.reddit.com/r/linux/comments/2dvmdn/what_do_you_a...
(No comment on the general tendency of crowdsourced moderation systems to vote for popularity rather than truth.)
BSD's choice to drop everything into a single rc file is not particularly elegant, but it can be coerced to do what you want. The sysvinit user interface, frankly, isn't bad:
/etc/init.d/<service> [start|stop|reload|restart]
/bin/sh -x /etc/init.d/<service> [start|stop|reload|restart]
I'll add that my distro of choice is Debian (or derivatives, which I generally mean here). One thing that I noticed when first switching to Debian, back in the mid 1990s, was that its init scripts were vastly easier to follow than Red Hat's. Debian has a fairly standard structure (/etc/init.d/skeleton is the bare-bones template), and most scripts follow that within some reason. There are a few exceptions -- scripts which initialise things (bootclean, mount, networking) rather than start services, tend not to look like service initialisation scripts, on the inside. On the outside, though, they do.
Further: once configured properly, those scripts don't change. Debian in particular does an extraordinarily good job of extracting out all necessary configuration to an /etc/ configfile (which it then won't touch unless you specifically tell it to).
My experience on MacOS (see elsewhere in this thread) is that stuff which ought be easy isn't. My experience with systemd, to date, hasn't evidenced this, as I am largely using the extant sysvinit scripts. But I've noticed numerous things Wot Used To Work ... do not. And the response from the sysvinit devs, particularly from the top, as well as various sycophants on numerous fora, has been exceedingly disturbing.
Case in point, my single most controversial Reddit comment:
https://www.reddit.com/r/linux/comments/2dvmdn/what_do_you_a...
(No comment on the general tendency of crowdsourced moderation systems to vote for popularity rather than truth.)
> BSD's choice to drop everything into a single rc file
... is a description that is out of date by coming up to 2 decades. Mewburn rc came along at the start of the 21st century.
* http://blog.darknedgy.net/technology/2015/09/05/0/
... is a description that is out of date by coming up to 2 decades. Mewburn rc came along at the start of the 21st century.
* http://blog.darknedgy.net/technology/2015/09/05/0/
I haven't messed with OpenBSD for quite some time, but how I described it is actually how it functioned, as I recall.
That's ... over a decade out of date.
Re-pitching my comment at that specific configuration: it wasn't elegant, but it could be coerced to do what I wanted.
That's ... over a decade out of date.
Re-pitching my comment at that specific configuration: it wasn't elegant, but it could be coerced to do what I wanted.
OpenBSD doesn't work like that, either. The OpenBSD people reinvented Mewburn rc just over six years ago. None of FreeBSD, TrueOS/PC-BSD, FreeNAS, OpenBSD, NetBSD, DragonFly BSD have a single rc file containing everything.
With the sole exception of MirOS BSD as far as I am aware, the world has actually let go of that idea.
With the sole exception of MirOS BSD as far as I am aware, the world has actually let go of that idea.
Noted. But again, this was the process when I did look at it.
Cheers.
Cheers.
Maybe you're thinking of /etc/rc.local, which is a script on *BSD where you could just dump random commands, which would then be executed at startup. Last I checked, this mechanism is still supported, but not really the way to do it.
That too, though the main RC script existed too. Lots of environment variable tests.
My understanding is that interpersonal drama and similar BS has large role in it. Note how often is the anger targetted at main dude behavior. Also some don't like change, react aggressively to it and systemd is change.
There are also technical reasons, but those tend to attract less of pure anger.
There are also technical reasons, but those tend to attract less of pure anger.
> how often is the anger targetted at main dude behavior
That anger comes from somewhere. We don't just go around picking random people to become angry with. Poettering has a lot of influence in core components of Linux (dbus, pulseaudio, systemd) and he's a bad developer. His designs are horrible, his implementations buggy and shoddy and don't fit into the overall architecture of the rest of the system. So, yeah, there's anger towards him and I think it's more than deserved.
> Also some don't like change, react aggressively
We like change just fine if it brings improvements. If not, we don't like those changes. Again, we don't go around hating on random changes.
>There are also technical reasons, but those tend to attract less of pure anger.
All of the anger is caused by technical reasons. Whether it's shoddy programming or shoddy reasoning about technical issues on the systemd developers part. Almost no-one personally knows Poettering or the systemd developers, yet we still think their software sucks.
That anger comes from somewhere. We don't just go around picking random people to become angry with. Poettering has a lot of influence in core components of Linux (dbus, pulseaudio, systemd) and he's a bad developer. His designs are horrible, his implementations buggy and shoddy and don't fit into the overall architecture of the rest of the system. So, yeah, there's anger towards him and I think it's more than deserved.
> Also some don't like change, react aggressively
We like change just fine if it brings improvements. If not, we don't like those changes. Again, we don't go around hating on random changes.
>There are also technical reasons, but those tend to attract less of pure anger.
All of the anger is caused by technical reasons. Whether it's shoddy programming or shoddy reasoning about technical issues on the systemd developers part. Almost no-one personally knows Poettering or the systemd developers, yet we still think their software sucks.
> We don't just go around picking random people to become angry with.
There are all kinds of people and plenty in Linux community do pick up on people merely for not be deferential enough to authority. Or for asking question they find stupid (or don't know answer for). You can get flamed quite easily.
Not all, probably not you, but a lot of people there get quite aggressive quite easily.
> We like change just fine if it brings improvements.
I personally know people who get outrages over changes whenever change happen. Maybe not you, but you are not everybody.
> All of the anger is caused by technical reasons.
No, not all of it. A lot of it is cause by arrogance which is not technical reason. You don't need to know someone personally to get that feeling. A certain amount of the anger has faulty reasoning on itself.
There are all kinds of people and plenty in Linux community do pick up on people merely for not be deferential enough to authority. Or for asking question they find stupid (or don't know answer for). You can get flamed quite easily.
Not all, probably not you, but a lot of people there get quite aggressive quite easily.
> We like change just fine if it brings improvements.
I personally know people who get outrages over changes whenever change happen. Maybe not you, but you are not everybody.
> All of the anger is caused by technical reasons.
No, not all of it. A lot of it is cause by arrogance which is not technical reason. You don't need to know someone personally to get that feeling. A certain amount of the anger has faulty reasoning on itself.
Because the people who know enough to critique a init system generally run linux on all their devices.
I wonder why Poettering chose Kay Sievers to work on systemd in the first place.
I fucking hope not.
Linus is clearly very smart, but user-facing tools is not what he's good at. Git is a perfect example of this.
Mercurial and Git were created ridiculously close to each other, and their main features/use model are quite similar, and yet mercurial is literally years ahead in terms of usability. The results to a given command are 99% of the time, what you would intuitively expect.
Now here's what I would love to see: Linus initiate a fork/rewrite/whatever of the init part of systemd, that keeps the concept of non-executing service definition files. They don't have to be compatible with systemd but that wouldn't necessarily be a bad thing either.
Edit: actually, aiming for compatibility probably means having to reimplement systemd weirdness, so probably is a bad thing as I think about it.
Linus is clearly very smart, but user-facing tools is not what he's good at. Git is a perfect example of this.
Mercurial and Git were created ridiculously close to each other, and their main features/use model are quite similar, and yet mercurial is literally years ahead in terms of usability. The results to a given command are 99% of the time, what you would intuitively expect.
Now here's what I would love to see: Linus initiate a fork/rewrite/whatever of the init part of systemd, that keeps the concept of non-executing service definition files. They don't have to be compatible with systemd but that wouldn't necessarily be a bad thing either.
Edit: actually, aiming for compatibility probably means having to reimplement systemd weirdness, so probably is a bad thing as I think about it.
We detached this subthread from https://news.ycombinator.com/item?id=14733364 and marked it off-topic.
I don't understand how it's off topic? It was a reply to someone asking if Linus would write his own init (because he's unhappy in systemd), and my take that it would be a bad idea because of the usability issues in the last big thing he started.
It's off topic because (a) the subthread became about Git usability, which is not the topic and (b) it's one of those subjects that quickly sucks the oxygen out of other discussions. Not nearly as badly as systemd of course, but still.
It's quite frustrating seeing people complain about Git usability like it's some broadly accepted and objectively bad thing. As frivolous as anecdotes are, I took to Git very smoothly and I found it to operate in a very obvious and explicit fashion, particularly once I'd shifted my mental model from what I was using at the time (primarily SVN.)
Git is a very powerful, flexible, reliable and efficient tool. I'd be over the moon if someone wrote an init system holding similar values.
Git is a very powerful, flexible, reliable and efficient tool. I'd be over the moon if someone wrote an init system holding similar values.
Couldn't agree more here. I picked up git at the same time I was starting out as a professional programmer, and never had any major problems with it at all. In fact I remember it being a breath of fresh air from my previous version control experience, which was banging around with TortoiseSVN on Windows.
I still remember the first time I used "git cherry-pick," I just guessed what it needed from my (then pretty limited) git experience, and it just worked seamlessly. The few little command-line quirks in git (like "checkout" being used to create new branches) are barely worth mentioning.
I still remember the first time I used "git cherry-pick," I just guessed what it needed from my (then pretty limited) git experience, and it just worked seamlessly. The few little command-line quirks in git (like "checkout" being used to create new branches) are barely worth mentioning.
>Couldn't agree more here. I picked up git at the same time I was starting out as a professional programmer, and never had any major problems with it at all.
With all due respect, if you have zero experience with any other CLI solution, are you sure you can evaluate the qualities of git's interface? Nobody said git isn't capable.
With all due respect, if you have zero experience with any other CLI solution, are you sure you can evaluate the qualities of git's interface? Nobody said git isn't capable.
Why not? First-time experience with VCS and git compared to first-time experience with git but multi-year experience with others VCS are both valid experiences that has to be considered.
Nobody is saying Git is unusable, or that it doesn't work, or that it isn't powerful.
We're saying the alternatives are easier to use. You freely admit you haven't used any of the alternatives - you haven't even used SVN from a command line, so you have literally nothing to compare to when using git commands.
We're saying the alternatives are easier to use. You freely admit you haven't used any of the alternatives - you haven't even used SVN from a command line, so you have literally nothing to compare to when using git commands.
Well, I am not saying that nor admitting to not having used anything else. AndrewBissell above did state that though.
My only point being, that while git is not perfect compared to others, even if you don't have experience with an alternative CLI, your experience with just that one CLI can be valuable.
My only point being, that while git is not perfect compared to others, even if you don't have experience with an alternative CLI, your experience with just that one CLI can be valuable.
Apologies, I didn't notice the different username. However I disagree - when the whole point is relative ease of use, having experience in just one is meaningless.
No worries :)
Yeah, on one hand, relative ease of use is important, especially if you're trying to write a tool to replace others. And I'm not saying that is not important. Just that it's important to consider both, not only one.
Compare it to when trying to make a website easier to use. Ok, fine, compare it to other websites too, but your first-timers that have no experience with anything else are important too.
Yeah, on one hand, relative ease of use is important, especially if you're trying to write a tool to replace others. And I'm not saying that is not important. Just that it's important to consider both, not only one.
Compare it to when trying to make a website easier to use. Ok, fine, compare it to other websites too, but your first-timers that have no experience with anything else are important too.
That's the thing: it is broadly accepted as having poor usability compared to other version control tools.
If you haven't had those issues, you're one of the lucky ones.
Edit:
> Git is a very powerful, flexible, reliable and efficient tool.
I didn't say it isn't any of those things. I said it's harder to use than competitors such as mercurial.
If you haven't had those issues, you're one of the lucky ones.
Edit:
> Git is a very powerful, flexible, reliable and efficient tool.
I didn't say it isn't any of those things. I said it's harder to use than competitors such as mercurial.
Do you have a source for this widespread acceptance? I mean I get that version control in general can be hard for new developers to wrap their heads around but I never really had trouble picking up git personally, and the interns at my workplace haven't had any significant trouble either besides needing some coaching in how rebase works.
This comment (from a Hg developer on Lobste.rs [1]) is a good start:
> Furthermore, the proliferation of git wrappers says something. Mercurial has a lot of users too (Facebook), and guess what, they don’t write wrappers for it. They do write aliases and extensions, using hg’s established customisation mechanisms, but they don’t feel like the entire UI is so terrible that it has to be completely replaced by a different UI
Then let's consider this snippet, from the people that literally wrote the book on Git, in the Chapter "Git Internals" [2]:
> You may have skipped to this chapter from a previous chapter, or you may have gotten here after reading the rest of the book — in either case, this is where you’ll go over the inner workings and implementation of Git. I found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to me that it can be confusing and unnecessarily complex for beginners.
If you don't know the internals, you don't really know git. I use git for client work on at least a weekly basis - not necessarily daily. I know enough to use it, and enough to know when I need to check the manual or search for something. I don't know the internals, and it's wrong that we 'need' need to.
[1]: https://lobste.rs/s/klqjwc/two_commits_wrecked_user_experien...
[2]: https://git-scm.com/book/en/v1/Git-Internals
> Furthermore, the proliferation of git wrappers says something. Mercurial has a lot of users too (Facebook), and guess what, they don’t write wrappers for it. They do write aliases and extensions, using hg’s established customisation mechanisms, but they don’t feel like the entire UI is so terrible that it has to be completely replaced by a different UI
Then let's consider this snippet, from the people that literally wrote the book on Git, in the Chapter "Git Internals" [2]:
> You may have skipped to this chapter from a previous chapter, or you may have gotten here after reading the rest of the book — in either case, this is where you’ll go over the inner workings and implementation of Git. I found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to me that it can be confusing and unnecessarily complex for beginners.
If you don't know the internals, you don't really know git. I use git for client work on at least a weekly basis - not necessarily daily. I know enough to use it, and enough to know when I need to check the manual or search for something. I don't know the internals, and it's wrong that we 'need' need to.
[1]: https://lobste.rs/s/klqjwc/two_commits_wrecked_user_experien...
[2]: https://git-scm.com/book/en/v1/Git-Internals
Careful with equating "Facebook is a wildly market-successful product" with "Every engineering practice at Facebook is industry-applicable and should be emulated".
I didn't, the Hg dev simply used Facebook as a very large, well known software shop that uses Mercurial. We could swap out "Facebook" for "Mozilla" or "Nginx Inc." or a number of open source (either community or corporate backed) projects.
We could do the same thing with Git though, so clearly source control scheme is not strongly correlated with actual success of the project -- which makes sense.
That wasn't the point of the comment.
The point was that there are a lot of git "wrappers" created to solve the problem of Git's usability. The same doesn't happen with Mercurial, and it isn't just because of a lack of use, as demonstrated by X, Y, Z prominent/large software companies/projects using it.
The point was that there are a lot of git "wrappers" created to solve the problem of Git's usability. The same doesn't happen with Mercurial, and it isn't just because of a lack of use, as demonstrated by X, Y, Z prominent/large software companies/projects using it.
could you provide specific examples?
The UI has some warts, and a few design choices were made that some people find questionable. You can get used to them (which is probably why most people don't even notice it as a problem), but they're there.
The best survey of Git's quirks that I've seen is, unfortunately, http://stevelosh.com/blog/2013/04/git-koans/
The best survey of Git's quirks that I've seen is, unfortunately, http://stevelosh.com/blog/2013/04/git-koans/
As a not-developer that has to put on a developer hat and learned git and mercurial at about the same time without any prior experience working with cvs/svn/etc outside of checking stuff out from sourceforge, I don't find git to be any more difficult to use than mercurial
As far as I understand Linus was mostly involved in creating the git backend, and this part is actually well designed. It looks like something went wrong during the UI development, maybe they've tried to follow the underlying backend too closely instead of thinking it in terms of how users manage their source code.
Systemd is a steaming turd. However, it's one we have to live with, and there doesn't seem to be anything better on the horizon.
A good book on the subject might make things slightly better. However, it doesn't seem like anyone is interested in writing one :-(
A good book on the subject might make things slightly better. However, it doesn't seem like anyone is interested in writing one :-(
This is taking a quote out of context and trying to start the old usual systemd flamewar. Flagged.
This isn't out of context. It's a direct quote and links to the full content of the email.
Also "If you flag something, please don't also comment that you did."
https://news.ycombinator.com/newsguidelines.html
Also "If you flag something, please don't also comment that you did."
https://news.ycombinator.com/newsguidelines.html
EDIT: Here are links to comments discussing the actual content of his email, in case anyone else came here for that and left wanting.
https://news.ycombinator.com/item?id=14734868
https://news.ycombinator.com/item?id=14733973 -> https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
EDIT: I read all the comments on this post, and I am disgusted to report that (as of this EDIT, nitpickers) the 2 above-linked comments are the sum total of actual replies to the content Linus was trying to discuss. I hope LKML had more self-control than HN.
EDIT: 14733558, it was really excellent of you to try and defuse things, too.