The spreading of systemd continues, now actively pushed by themselves unto other projects, like tmux:
"With systemd 230 we switched to a default in which user processes started as part of a login session are terminated when the session exists (KillUserProcesses=yes).
[...] Unfortunately this means starting tmux in the usual way is not effective, because it will be killed upon logout."
It seems methods already in use (daemon, nohup) are not good for them, so handling of processes after logout has to change at their request and as how they say. They don't even engange into a discussion about the general issue, but just pop up with the "solution". And what's the "reason" all this started rolling? dbus & GNOME coders can't do a clean logout so it must be handled for them.
Just a "concidence" systemd came to the rescue and every other project like screen or wget will require changes too, or new shims like a nohup will need to be coded just in case you want to use with a non changed program. Users can probably burn all the now obsolete UNIX books. The systemd configuration becomes more like a fake option, as if you don't use it you run into the poorly programmed apps for the time being, and if they ever get fixed, the new policy has been forced into more targets.
Seen at lobsters 1 & 2 where some BSD people look pissed at best. Red Hat, please, just fork and do you own thing, leaving the rest of us in peace. Debian et al, wake up before RH signed RPMs become a hard dependency.
Related Stories
System adminsitrator Chris Siebenmann has found Modern versions of systemd can cause an unmount storm during shutdowns:
One of my discoveries about Ubuntu 20.04 is that my test machine can trigger the kernel's out of memory killing during shutdown. My test virtual machine has 4 GB of RAM and 1 GB of swap, but it also has 347 NFS[*] mounts, and after some investigation, what appears to be happening is that in the 20.04 version of systemd (systemd 245 plus whatever changes Ubuntu has made), systemd now seems to try to run umount for all of those filesystems all at once (which also starts a umount.nfs process for each one). On 20.04, this is apparently enough to OOM[**] my test machine.
[...] Unfortunately, so far I haven't found a way to control this in systemd. There appears to be no way to set limits on how many unmounts systemd will try to do at once (or in general how many units it will try to stop at once, even if that requires running programs). Nor can we readily modify the mount units, because all of our NFS mounts are done through shell scripts by directly calling
mount; they don't exist in/etc/fstabor as actual.mountunits.
[*] NFS: Network File System
[**] OOM Out of memory.
We've been here before and there is certainly more where that came from.
Previously:
(2020) Linux Home Directory Management is About to Undergo Major Change
(2019) System Down: A systemd-journald Exploit
(2017) Savaged by Systemd
(2017) Linux systemd Gives Root Privileges to Invalid Usernames
(2016) Systemd Crashing Bug
(2015) tmux Coders Asked to Add Special Code for systemd
(2016) SystemD Mounts EFI pseudo-fs RW, Facilitates Permanently Bricking Laptops, Closes Bug Invalid
(2015) A Technical Critique of Systemd
(2014) Devuan Developers Can Be Reached Via vua@debianfork.org
(2014) Systemd-resolved Subject to Cache Poisoning
(Score: 2, Touché) by Anonymous Coward on Monday May 30 2016, @06:49AM
SystemD can have its own fork of tmux, what's the problem? Everybody loves forks. Top coders all have GitHub profiles full of completely unmodified forks of trendy repos just to make themselves look like they contribute when they don't. Tapping that fork button is the most important skill of coding.
Just fork the forking thing and shut the fork up about it already.
Right, so then you have a tmux-systemd package and it depends on systemd and tmux conflicts with it, what's the forking problem? This is the normal way things happen with Linux crap.
(Score: -1, Flamebait) by fnj on Monday May 30 2016, @06:53AM
You really are a brain damaged idiot.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:57AM
Those were the days! When fucking LINUX needed its own LIBC because GNU wasn't good enough for fucking LINUX. Remember how fucking LINUX forced GNU to change LIBC for fucking LINUX?
You whiny hypocrites.
(Score: 4, Interesting) by Anonymous Coward on Monday May 30 2016, @07:02AM
Quote copied from Wikipedia because fucking asshole hypocrite dumbshits can't be expected to follow a link.
Fork "Linux libc"
In the early 1990s, the developers of the Linux kernel forked glibc. Their fork, called "Linux libc", was maintained separately for years and released versions 2 through 5.
When FSF released glibc 2.0 in January 1997, it had much more complete POSIX standards compliance, better internationalisation and multilingual function, IPv6 capability, 64-bit data access, facilities for multithreaded applications, future version compatibility, and the code was more portable. At this point, the Linux kernel developers discontinued their fork and returned to using FSF's glibc.
The last used version of Linux libc used the internal name (soname) libc.so.5. Following on from this, glibc 2.x on Linux uses the soname libc.so.6 (Alpha and IA64 architectures now use libc.so.6.1, instead). The *.so file name is often abbreviated as libc6 (for example in the package name in Debian) following the normal conventions for libraries.
According to Richard Stallman, the changes that had been made in Linux libc could not be merged back into glibc because the authorship status of that code was unclear and the GNU project is quite strict about recording copyright and authors.
(Score: 5, Insightful) by jimshatt on Monday May 30 2016, @10:36AM
It seems to me that the Linux forked libc because they thought they needed it, then later realized that was a mistake and returned to the better unforked version.
This is how it should work. If the changes you (think you) need are not generic enough to be in the upstream version, you fork the code. If that turns out to be a mistake, at least you haven't polluted upstream. And this is EXACTLY why the systemd integration into tmux should be in a fork. So that when the nightmare is over (if ever) we can kill the fork and enjoy the purity of upstream tmux.
(Score: 1, Interesting) by Anonymous Coward on Monday May 30 2016, @08:09PM
GNU, due to a combination of issues getting ahold of standards, questionable developer decisions, and forging ahead in a new field, fell behind in the development of glibc and gcc during the early to mid 90s. As a result of this glibc was lacking in a lot of POSIX conformancy as was gcc in regards to c and c++ standards (via the seperate package, at the time, g++).
The long and the short of it is that the linux libc4/5 lead to GNU getting off their asses and polishing up their turd (glibc) enough for linux to jump back to the original version rather than continuing to maintain their fork (which due to 'need it now' syndrome had ended up as a legally questionable mass of source code all stiched together as a not actually even close to conformant libc, defeating the original purpose of forking it anyhow.) egcs acted the same way for gcc during the 96-98 period cumulating in the gcc 2.95 releases, which eventually got broken again by redhat as the gcc-2.96 release and by debian as the gcc-2.95.4 release (which was never AFAIK a real gnu version number, having jumped to 3 for what was to become the gnu-98 support. But ended up as one of the clusterfucks of ABI breakage we've had until today thanks to Redhat rushing things with the 2.96 release which helped lead to 3.0-3.3 ABIs all being slightly broken. And the expectation that most/all C++ code has to be compiled with the same compiler.)
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:13PM
Well, thank fuck that now C99 is enough for anybody.
(Score: 1, Touché) by Anonymous Coward on Monday May 30 2016, @08:00AM
(Score: 5, Insightful) by MadTinfoilHatter on Monday May 30 2016, @08:24AM
Just fork the forking thing and shut the fork up about it already.
They don't want to - that would mean extra work. Why would you do that when you can just tell the developers:
Nice software you got there... It would be a shame if it stopped working due to something we did in our "init-system". So you'd better bend over and add some code that... streamlines it with ours, you know, so nobody has to get hurt...
Seriously, systemd is a cancer that grows uncontrollably and infects everything it touches.
(Score: 3, Insightful) by Anonymous Coward on Monday May 30 2016, @02:47PM
RedHat the new Microsoft.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @03:44PM
Don't you mean DebHat?
(Score: 3, Insightful) by digitalaudiorock on Monday May 30 2016, @03:16PM
I'd say it's much more insidious than that...the more stuff they can make dependent on their shit the better right? After all, that's pretty much what started all this...that inexcusable, malicious systemd dependency in Gnome. This way they can bail out Gnome stupidity with an even more stupid fix, and further entrench themselves in the Linux landscape...all part of the plan. This won't get tolerated forever though...it's getting so bad that something's got to give.
(Score: 2, Disagree) by pvanhoof on Monday May 30 2016, @05:25PM
The systemd dev doesn't make shit depend on them. Other projects make their shit depend on systemd. That means that systemd provides a service to those projects. Something they don't want to invent themselves. I'm guessing it has something todo with uniformity on building applications that interop with other services and other applications. D-Bus was a first step almost a decade ago. We all had our own motherf. stupid IPC systems. It was pure hell. The debates where childish and stupid. Now most projects use D-Bus and all is quite good.
Same now. We all have our own motherf. stupid cruft and crap to deal with containers and other services. A lot of softwares are being written with D-Bus just to get service activation, while they shouldn't be activated by D-Bus only. Think NetworkManager & co. Developers don't want to care about having twenty different ways to do simple stuff.
Maybe in future systemd will be replaced by something else more innovative. But by the time systemd will be ready; at least it will have pioneered an API. Hopefully that won't have to be redone too many times.
(Score: 2) by http on Monday May 30 2016, @06:02PM
Systemd is both mechanism and policy.
I browse at -1 when I have mod points. It's unsettling.
(Score: 2, Disagree) by pvanhoof on Monday May 30 2016, @06:54PM
The policy and crafting of an API around it, is precisely what developers want and need. They don't want twenty different ways of interacting with containers and services. And they definitely don't want to write goddamned hundreds of fscking scripts that suck the blood out of veins.
Instead, they want to package policy in clear and well defined configuration. Then they want to make-distcheck that. Then distributions will install it and will provide clear and well defined overrides. You know, like almost every modern package and system does. Even ld.so.conf has support for something like /etc/ld.so.conf.d.
This /etc/init.d/ stuff, stinks.
No. fucking. scripts.
(Score: 2) by Geotti on Monday May 30 2016, @10:27PM
This /etc/init.d/ stuff, stinks.
[puts on sysadmin head]
Fuck you!
(Score: 2) by Geotti on Monday May 30 2016, @10:29PM
s/head/hat/
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @09:55AM
No, the original was much better.
Swapping head spaces every so often is healthy exercise
(Score: 3, Insightful) by Anonymous Coward on Tuesday May 31 2016, @09:52AM
Errr no. I do not want any of that.
Perhaps you could ask me what I want next time instead of speaking for me.
(Score: 2) by sjames on Tuesday May 31 2016, @05:31PM
No. Policy is to be determined by the sysadmin. APIs are supposed to be the interface to the mechanism by which policy is implemented. That mechanism needs to be policy neutral.
This was figured out a long time ago and it works well. Mechanism setting policy is broken by design.
(Score: 3, Funny) by TheGratefulNet on Monday May 30 2016, @08:50PM
Systemd is both mechanism and policy.
yeah... and soon it will include such roles as being a floor wax as well as a desert topping!
"It is now safe to switch off your computer."
(Score: 1, Insightful) by Anonymous Coward on Monday May 30 2016, @06:07PM
Yank consolekit, introduce logind. Merge udev with systemd. Turn upower/powerkit into a wrapper around logind (yes, these days logind is the actual process that suspends your laptop when you close the lid).
https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html [freedesktop.org]
(Score: 1) by pvanhoof on Monday May 30 2016, @06:59PM
You need to add the relevant context before quoting somebody, especially Michael Biebl. He's one of the best packagers on this planet. As one of the maintainers of Tracker I saw him endlessly pushing for upstream (that's us) fixing their shit. If one guy has anything to say about all this, to me, it's Michael Biebl. To Michael, I listen. Because of respect.
Here is the important piece of context you should think about not once, but each and everytime you decide to write whatever on systemd:
" ... so that they stop supporting deviating solutions for these things where there's really no point at all in doing so."
(Score: 0) by Anonymous Coward on Monday May 30 2016, @07:11PM
Err, the email is from Poettering, responding the Biebl raising a issue with how systemd changes would interact with debian sysv back in 2010. It is Poettering that is stating quite clearly that systemd intends to make it bothersome for distros do things in any other way than the systemd way.
(Score: 2, Insightful) by pvanhoof on Monday May 30 2016, @08:18PM
Sure, but Michael also isn't disagreeing with it. Two developers talking to each other. Nodding.
No reason for you to take things out of context for. Also. Read the entire mailing list and conversation.
Out of context,is out of clue. The conversation is and has been going on for years now. Listen. Stop your ideology. And listen.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @08:44PM
Not sure who is the ideologue here...
(Score: 2, Interesting) by pvanhoof on Monday May 30 2016, @09:12PM
Yes. Fair enough. I understand that I'm a systemd 'fan'. But I did do my part of the work, evaluation. I investigated it and I have experience.
I do understand the criticism and I do understand the so called "UNIX philosophy". Ok. Still. Some things of systemd are good.
I am one of the nodding software developers. I have criticism. But I also nod to Lennart's (and other's) idea's.
I say: go ahead Lennart (and others): do. it. (and they are doing it -- which is a good thing).
They can be sure that we'll review. We'll scrutinize. Hard. We won't review shit that isn't done. That nobody does. We won't review ideas from bitchers and whiners.
Your code, or go away.
(Score: 1, Insightful) by Anonymous Coward on Tuesday May 31 2016, @10:15AM
Sigh.
See. Therein lies the problem.
So-called? Really? Likely this philosophy is older than you. The least you could do is show some respect.
Look, you write like you are part of the systemd crew, or are on their bandwagon, in the thick of the glorious revolution. I invite you to step outside and join us in the ditches at the coalface. Yes, the work can be messy. It can smell. Oh can it reek. It can be fun. But by whatever deity or whatever binds your sanity together I strongly suggest you never say these things in an actual work place in front of people who have to wake up at 3am in the morning and fix whatever system screwup occured.
You think scripts are nasty. Sigh. Have you had a job maintaining hundreds of servers across sites spanning cities? Have you ever encountered just even one of the omfg what the heck caused this type of problem with managers standing around talking about uptime and money? Do you have two decades experience administrating servers and applications? Can you appreciate a well configured environment that you walk away from at 6pm knowing that at 8am it will be running fine just like it was when you left?
Because it does not sound like it.
Consider this. The next time someone expresses a dislike of systemd it may not be solely due to their philosophy. It may be because in the hard cold world we inhabit anything that makes life worse is not worth suffering through. Like being woken up at 3am.
Perhaps you have this type of experience and simply enjoy pain. I certainly do not. Nor does any admin I know, even the bastards. Something all good admins have in common is the driving need for the system to be up and available. If you cannot see this or seriously disagree then perhaps you are in the wrong profession.
OTOH feel free to learn this the hard way. Get a job as a linux sysadmin for a large company. Have your say. Make your opinion heard. See what happens.
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @11:24AM
Fucking fans. Spectators. Free to say anything they like. Never actually get dirty.
A long post which could better have been: Get off my lawn!
(Score: 3, Insightful) by sjames on Tuesday May 31 2016, @05:58PM
There may be some nice features to systemd, but the price is orders of magnitude too high. There are just too many ways to get the same value without the abominable hairball. And certainly without using the abominable hairball as a coercive tool to keep competing ideas out.
I'm guessing by bitchers and whiners, you mean anyone who declined the cool aid.
Have a look at tmux and the well established existing mechanism and API for terminating user processes on logoff. Now USE IT. Tell Gnome to fix their code rather than screwing everyone else over so they can paper over their bugs.
Funny, they have been shown the code and still aren't interested. Guess I was right about the cool aid thing.
(Score: 2) by sjames on Tuesday May 31 2016, @05:28PM
Other projects end up depending on systemd when they will otherwise be broken by systemd. In much the same way as businesses voluntarily join the neighborhood protection organization sponsored by the local wise guys.
The vast majority of this crud has been from freedesktop.org, the same people who decided to evicerate Gnome.
I'm glad to hear that tmux won't be going along with this.
As for dbus, it's a miserable and overcomplex mechanism that also needs to go away or at least get properly documented.
(Score: 1) by pvanhoof on Monday May 30 2016, @05:14PM
Why does that flow only in the direction you seem to want? If tmux wants to work together with systemd, then why isn't that fine? Why don't you fork to have a system that has no systemd? Because frankly if you don't do it, then that means that you don't care enough. The rest of the world can simply ignore you. And they do.
If you care enough to fix something (so that it doesn't depend on systemd): then do it.
You see those words there? Do. It.
Stop bitching and do. it.
(Score: 2) by Scruffy Beard 2 on Monday May 30 2016, @06:03PM
Systemd is the project asking everybody to overturn 30 years of practice, not the other way around.
(Score: 1) by pvanhoof on Monday May 30 2016, @06:42PM
Then just don't use it. Fork the projects which you want to follow your vision, and maintain the fork. Do better than the current maintainers and everybody will follow your fork. Git allows you to do this. Stop whining. And do it. Prove yourself and us and the rest of the world how great your vision is. Write and maintain the code. Or be ignored.
I just realize that, again, I'm wasting too much of my time on this and on explaining this to people who don't do but only bitch and whine. Plenty of ideas to maintain and code. Really.
Write and maintain the code. Or be ignored.
(Score: 3, Insightful) by Zz9zZ on Monday May 30 2016, @07:44PM
My my you suffer from the general myopia that exists in the coding community. All opinions you disagree with are swept under the rug by saying "fork it yourself or shut up!"
I understand your point, and it can be frustrating to have people complain and request features when they aren't paying you for the work. However, this debate about sysd is valid and should be talked about it. Obviously few people have the necessary skills and/or time to create their own forks, but even if you ignore that you can't escape from the fact that sysd is becoming a hard dependency for all of linux and is counter to the unix design.
Since you're an amazing coder, perhaps you should stop all the whining and time wasting by making the fork yourself. If its so straight forward why don't you do it to shut up all the whiners? No? We have to be subjected to your asinine commentary that doesn't contribute a single thing to the discussion? Got it...
~Tilting at windmills~
(Score: 1, Troll) by pvanhoof on Monday May 30 2016, @08:02PM
I'm not an amazing coder and yet I've considered this. If I'd (still) be a self-proclaimed amazing coder, I wouldn't understand how I couldn't be right. But now at least I do understand that I'm probably not right. However. I found no major flaws in the ideas behind systemd. I'm also not afraid of systemd's devs taking a bit of mindshare on how a typical Linux system ought to be. A little bit of benevolent dictatorship is good here. I don't want to decide because I know people like Lennart (I explicitly write "like", because I understand that he's not the only one) probably investigated this much better than I could ever do.
Just like how I sort of trust people like Linus to take care of my kernel. And you have guys who put 70ties storage disks on their heads singing songs munching hairs and playing with their feet at conferences who care about some editor which I never used. And they are probably good at it, too.
Now if you don't trust those gurus, just visit some other store in the bazaar. Or visit another bazaar? Help that owner to make his magic fantastic. Maybe someday you'll get your own store. Most retire early.
(Score: 4, Informative) by Zz9zZ on Monday May 30 2016, @09:26PM
Again with the "if you don't like it piss off" attitude. The problem is that sysd is becoming a huge package replacing all mid level functionality. With the kernel there is one source and devs can create software to work with it. With sysd there is now another layer to support and it happens to break existing software.
The crux of your argument is making fun of people who don't like sysd and telling them to find their own playground. Munching hairs and playing with their feet, editor wars? Sheesh, relying on cliches....
I am not one of the older linux people so your jabs flew wide, but they underline your stance. You side with the arrogant younger generation of coders who think they can solve all the problems they see but have little experience to understand the broader picture and long term consequences. The same crowd that spouts "fork it and shut up." So far I have seen almost zero arguments for what sysd is good for except for removing init scripts. While that seems like a good idea, taking over userspace, network, login, sudo, and god knows what else at the same time seems like a bad idea.
Your "solutions" to my complaints are like saying "Don't like living in the US? Well too bad, stop complaining or move somewhere else!" Seriously person, that ideology belongs in a closed environment like microsoft or apple. If someone wants to contribute to FOSS then they should realize they are part of a community. Benevolent dictatorship can work, and the kernel is a good place for it, but adding another layer on top of the kernel? A layer which has even more hooks into user space s a bad idea when those hooks affect the rest of the ecosystem without good workarounds. "But fork it!" Ehhh go fork yourself, but first do a clean rebuild from the "empathy" branch. Might want to look into the "understanding and wisdom" api, see if there are any useful bits you can use.
~Tilting at windmills~
(Score: 1) by pvanhoof on Monday May 30 2016, @09:59PM
Hello Zz9zZ. I'm a realist autist. That means I investigate. I do dig the manual of the box of legos. I did read Lennart's code. I even understand that it's by far not just Lennart's code. I recognize Lennart's code because I also sniffed PulseAudio's code. I somehow feel what is his. Yes, Lennart's style is there. His style is btw quite good. So I'm glad for the systemd project that Lennart is there. Because he has good taste.
Few software developers have good taste.
I actually also recognize Richard's code. The guy who munches hairs and plays with his feet to develop EMacs, and gcc. And yes, a huge amount of GNU tools. I kinda like his code, too. He's making good smells. He has a nice store in our bazaar. I frequently visit his store. But I also frequently visit Lennart's. I prefer Lennart's taste.
We too have a sense of taste. You can pick us based on our tastes. All of the top guys have a taste.
Lennart is a top guy. Find his taste. Either enjoy it, or hate it. But take it for its merits. His code is good. Highest quality. His mind is to the point. He's rarely political. Usually technical. I met him a few times, but still I have a great amount of trust in Lennart.
That's because I know he can be evil.
(Score: 2) by Zz9zZ on Monday May 30 2016, @11:22PM
Yes you have opinions, good for you. If it was left at that, choice between a or b, then I'd be alright with this whole debacle. However, it is not a choice because systemd got rammed down everyone's throats and is working on being a hard dependency if you want to use Linux. Thankfully there are forks, and I can only hope they are enough to keep the ecosystem open so that future software does not have to rely on systemd.
You need to reevaluate your world view, you have a great amount of trust because you know he can be evil? It is 100% possible to create a technically better system that enables more shady ulterior motives. If you were truly a realist you would consider the possible negative outcomes, but I suspect you are similar to others I have met and will maintain your position until provided with incontrovertible facts. Personally I find it tiresome because it is very similar to debating with a person of faith. Nothing can be said to change the person's mind, or even alter the viewpoint slightly. Sadly, the "realist" perspective is often very narrow because we are imperfect human beings. If you throw out everything that isn't 100% verifiable then you are left with a smaller subset of information. Perhaps this sounds reasonable, but the human brain is quite good at inferring from incomplete data, so the realist approach loses that flexibility in return for the misguided comfort of absolutes.
Maybe it will all turn out alright, but personally I don't like merging all system tools into one behemoth and I see it as an end run to eventually dominate and control the Linux ecosystem. Time will tell, but I will push back on the architectural decisions I disagree with. If sysd hadn't taken over all distros and then started getting its fingers on functionality way outside the init system's purview; then I would happily let it do its thing without complaint. Or if at the leas it was actually a more modular system where anyone could write replacements and tie back into the api. Ostensibly this was supposed to be how it worked, but that hasn't quite worked out.
~Tilting at windmills~
(Score: 1, Troll) by pvanhoof on Tuesday May 31 2016, @10:21AM
To change my world view it would help if the debate around systemd wasn't one big ad hominem against Lennart. Just skipping the entries that are 99% about Lennart is or would be a daytime job. I specifically said that about that he can be evil as a sarcasm. But look oh look. The word Lennart falls and everybody is up in arms. As if he's the only developer behind systemd, as if the technical merits aren't what is important.
Your criticism of systemd becoming a behemoth is what should be debated, yes. But not whether you like or dislike Lennart. However - systemd as a project, might be a sort of in a monorepo (just like most BSDs are developed). But by itself it's quite modularly done: multiple processes, multiple binaries and you can enable and disable compilation and installation of them. That doesn't sound to me like a behemoth or monolithic design. The choice of storing a large set of components and tools in a single repository is indeed something I don't lilke myself.
I don't think it will last very long like that. I think that eventually the project will split up into multiple smaller ones. But time will tell.
(Score: 2) by Scruffy Beard 2 on Tuesday May 31 2016, @07:28PM
When the same name keeps coming up in software that simply makes your system work better when removed, you start to treat any new code by the person with suspicion.
I have "fixed" glitchy audio by removing pulseaudio. I have seen IPv6 auto-configuration "just work" without network- manager, but not with.
I don't think the init part of systemd has actually bitten me in the ass yet; but I do find auto-mounting drives under the permissions of the currently active user annoying.
(Score: 2) by Zz9zZ on Tuesday May 31 2016, @09:55PM
Thanks for a good reply :) Being human there will always be some who turn to personal attacks for one reason or another. I've read numerous complaints about Torvalds and Poettering, so its just something that happens when a person gets enough visibility.
I hope you're right and sysd gets pared down, but I won't hold my breath.
~Tilting at windmills~
(Score: 4, Informative) by sjames on Tuesday May 31 2016, @06:24PM
So where is this hard proof that systemd is better. I have looked it over and found it to be a bad idea. It COULD have been implemented in a way that respected the existing APIs and did not introduce crazy dependencies. But that would mean giving up coercive takeover. Apparently, playing nice with others got the heave ho early on.
You hate scripts? Look under the rug and you'll find hundreds of 'no really, it's not a script' files for systemd. To top it off, they use the logical equivalent of the 'comefrom' control structure. Yes, comefrom was a CS joke, but systemd uses it for real.
It seems to me you took systemd on faith and now insist on hard evidence to bend from that position. You've blinded yourself.
What does systemd ACTUALLY do that hasn't already been done quietly and cooperatively?
(Score: 2) by tangomargarine on Wednesday June 01 2016, @01:55PM
To be fair, try-catches are basically comefroms.
Of course, if somebody relied on try-catches for large portions of their control flow it would probably give me pause, too.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by sjames on Wednesday June 01 2016, @05:21PM
Actually, try-catch is more of a conditional goto explicitly declared over a block of code. Comefrom is an unconditional jump in the global scope that is declared nowhere near where the jump will happen.
Try-catch can be used well or poorly (too often poorly). There is no good case for comefrom. A classic example in BASIC:
(Score: 1, Informative) by Anonymous Coward on Tuesday May 31 2016, @02:22PM
Yeah, systemd people invade the Linux playground, force their own rules upon it, and when people complain, tell them to shut up or find their own playground. Completely ignoring that this is their own playground that is just getting forcefully taken away from them.
It is systemd people who need to find their own playground.
(Score: 3, Insightful) by Scruffy Beard 2 on Monday May 30 2016, @07:45PM
I refer you to this +3 insightful [soylentnews.org] comment.
My point was simply that the systemd developers should be doing the forking if their code does not work with anything else.
My near-term solution is to use FreeBSD until the whole thing (hopefully) blows over. I will probably keep a few Linux machines though (like my systemd free Android)
(Score: 1) by pvanhoof on Monday May 30 2016, @10:24PM
The systemd developers should do exactly and precisely what they want to do. And absolutely nothing more. If the BSD guys want a form of systemd, then it's up to them to make a systembsd. Or a bsdsystemd. Or b-system-d. Or my fucking god how much I wouldn't care about the recursive acronym that they'd come up with (actually, I would. For the laughs).
Just like Devuan. I just don't care about the ideology: make it good. Make it worth. Prove yourself. Be the best code. And then I will care.
Oh and if you as a user want to use FreeBSD: men. That's fantastic for you. I'm so happy for you. Waw. Great. You have freedom. Good that we provide you with it. Now if you want to influence those systems: you better get yourself ready to make the fucking best. Because imagine the shit you see here on soylentnews and slashdot: you'll get all of it. From the nitwits. Constantly. And you better have some arguments. You better be right. Meanwhile, you better be an experimenter who can be wrong at the same time. You better figure out how that can be.
You better be. It's fucking hard over here.
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @04:57AM
only retards want anything to do with systemd, go preach to systemd conf or the assholes at redhat and debian
(Score: 2) by sjames on Tuesday May 31 2016, @06:09PM
Don't make it a nearly impossible to rip out hairball so that people who don't want it CAN just not use it. Do you thing Devuan just wanted to take a long time to get to Beta? No, it's because that's how hard it was to just don't use systemd now that the dirty hairball is in place.
How about if you like it so much, spend a year forking a distro to make Potterix?
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @08:41PM
I think it is because the Devuan "developers" are quite a lot of talk and very little doing. In addition it is done by people who have never worked on a distribution before.
(Score: 3, Insightful) by Bot on Tuesday May 31 2016, @04:07AM
Are you seriously implying that switching to a new default that break things to fix a buggy behavior in an entirely different piece of software is OK?
I would not let such philosophy near a fork of solitaire, and you are OK with it affecting the service manager.
Systemd appreciation is for another thread, not this one. Trust me.
Account abandoned.
(Score: 3, Informative) by tangomargarine on Tuesday May 31 2016, @02:09PM
In a sane world, YOU make a fork when you have the new hotness that it will take everybody else a lot of work to implement, you don't ask everyone else to do YOUR work to make all their existing stuff that already works interface with your shit that breaks everything.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 5, Funny) by zeigerpuppy on Monday May 30 2016, @08:43AM
I prefer to spoon my code
(Score: 0) by Anonymous Coward on Monday May 30 2016, @12:15PM
That's my battle cry...Spoooon!
(Score: 2) by fido_dogstoyevsky on Tuesday May 31 2016, @12:58AM
I prefer to spoon my code
Then you still haven't realised the truth [c2.com].
It's NOT a conspiracy... it's a plot.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @08:48AM
Just fork the forking thing and shut the fork up about it already.
Um, I think the word you're looking for is smurf, not fork.
Just smurf the smurfing thing and shut the smurf up about it already.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @05:12PM
TBH, as a github user, I fork repos when I want to save a copy or mess with the source code. Often I get into the code and decide it's too messy to work with and give up, without deleting the repo.
Pressing fork can also be just for saving the current version or whatever.
(Score: 0) by Anonymous Coward on Sunday June 05 2016, @05:34AM
Top coders don't use github or any of those sites.
Just a regular git repo on their own computer and maybe... maybe... push to some server somewhere once in awhile, if they are feeling generous with the public.
Otherwise a tar.gz from time to time and that is that.
As is tradition.
(Score: 5, Insightful) by canopic jug on Monday May 30 2016, @07:26AM
Debian et al, wake up before RH signed RPMs become a hard dependency.
Three points on that:
Too late for Debian. Nearly all the Developers that know what's going on have left. Many ended up at Devuan [devuan.org] which just released a beta [devuan.org]. The combined torrent for Devuan-beta is huge, but just select pieces can be downloaded instead of the whole thing.
The Developers at Devuan are making very good progress, but have a very tough row to hoe. As you can see from the links in the summary, systemd is working its hooks in all over the place. tmux probably won't bend over, but many other packages have. So far it's been two steps forward and one step back as Devuan straightens out one package only to find a new one infected. However, they are making headway. Perhaps by then, many of the Debian derivatives will have seen through Poettering and Red Hat.
Red Hat likes and aims for the complexity [blogspot.ru]. Their more extreme ideas won't work if they go it alone, so they infect as many other distros as they can. More complexity means fewer can support their own work environments and more will have to sign contracts with Red Hat. Also, some of Red Hat's major customers benefit from the bugs that come with the added complexity.
Money is not free speech. Elections should not be auctions.
(Score: 5, Informative) by coolgopher on Monday May 30 2016, @08:20AM
You can also download the ~200MB netinst ISO, dd it to a USB stick, boot off that and install directly from the net, downloading only what packages you need as you go along. Did that over the weekend, worked well.
(Score: 3, Interesting) by RamiK on Monday May 30 2016, @08:23AM
With all due respect, the Debian's development model failed long before systemd. Ubuntu's malignant growth opened the way to Red Hat's influence in the first place and it wasn't external forces that made it happen.
20 years ago this kind of dependence on a strict hierarchy of trust-worthy maintainers was necessary. Nowadays, you have Arch, NixOS and GuixSD all allowing an open and wider contribution base while putting the developer's choices at the forefront. The latter two even solve the technical problems of *nix distributions while they're at it. And GuixSD actually gets rids of systemd in favor of Shepherd.
Honestly, this is like the carriage drivers union fighting city hall over who gets to clean the manure, while automobiles are available in the market. It's a throwback to ancient practices that were born due to the technical constraints of the time. It's 2016. We can fork packages. We can maintain forked packages of different version in our repositories. We can install different versions side-by-side of everything. And yet, here we are, fighting about who picks up the manure... Absurd.
compiling...
(Score: 3, Informative) by zeigerpuppy on Monday May 30 2016, @11:50AM
Not quite. Package management is non trivial and standards really help.
We're only in a bad situation because the wrong standard got up and compromised the unix philosophy at the same time.
I've also given Devuan a try on some VMs that needed upgrades from Debian Wheezy. So far it's been mixed. Some went well but the hooks of systemd can be deep and I had to ZFS rollback a couple of times (luckily that's fast!)
(Score: 2) by Unixnut on Monday May 30 2016, @12:51PM
That works on the pretext that Devuan does not become large enough to be self sustaining. If Debian does go down to "SystemD or the highway" model, and if enough people want to avoid SystemD, I can imagine that Devuan gets big enough to keep on going without Debian.
(Score: 1, Interesting) by Anonymous Coward on Monday May 30 2016, @03:41PM
Yeah, I expect Linux to essentially hard-fork into two separate operating systems you could call Linux-done-right and Poetterix.
(Score: 4, Interesting) by srobert on Monday May 30 2016, @03:59PM
If Linux were "done right" it would be FreeBSD.
(Score: 2) by Unixnut on Monday May 30 2016, @07:14PM
So... GNU/Linux, and SystemD/Linux :)
I would be fine with that personally, along with Android/Linux, and the other versions. That was there is no more confusion over what is "Linux" and which way is right, etc...
Let each version exist, name it clearly but with a way of distinguishing between them (including that they are not interoperable with each other), and everyone can move on. It is like a repeat of the Unix Fragmentation in the 70s-80s, but with all source code GPLed, so if enough people want to put in the coding effort, you can port apps and other bits between them.
My main concern is that SystemD/Linux will start depending on binary blobs, which may break things in future. As long as the Kernel stays core to all 3 OSes, then binary blobs like the Nvidia Drivers will work on all of them, so a win win for all.
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @06:40AM
Is this concern based on anything related to reality?
Or is it just you making random stuff up?
(Score: 3, Informative) by cubancigar11 on Monday May 30 2016, @01:44PM
For all that rosy eyed promises of heaven, NixOS by defaults uses systemd.
WHAT... A.. WASTE.... OF MY... TIME!!!!!
(Score: 2) by Bot on Monday May 30 2016, @03:07PM
Then try guix which doesn't use systemd. I tried installing guix as a separate package manager on a systemd less distro, but I had to give up because it started pulling a lot of packages. All the packages compiled fine till I had to reset, though.
Guix and IIRC void linux can be installed as package managers alongside your existing distro.
Account abandoned.
(Score: 2, Troll) by RamiK on Monday May 30 2016, @09:48PM
Nix can be installed side-to-side too. People even install it on Macs for some reason.
But please take my original post in it's context. I was criticizing the enterprise of forking Debian into a separate, systemd free distro as pointless since the underlying system is antiquated and socially relies on strict hierarchies that aren't conducive to health development models. My purpose was to argue for taking part, or forking Guix or Nix for the purpose of non-free packages on a modern systemd distro. I didn't argue for choices you can install right now.
However, in the realm of actual choices to use right now for end-users as an alternative to systemd that has firmwares and such, use arch [systemd-free.org] or just stick to slackware. Guix is still beta and pulls lots of package sources since they didn't stabilize a release for hydra (the build servers) to focus on compiling so it's impractical unless you're an active developer.
Incidentally, it's why I ignored the other response. I'm very argumentative by nature and usually make a flame war out of anything really, but I won't be bothered responding to axioms begging the question that I didn't even hint on.
Also, as a fair disclosure (of sorts), I have no issues with systemd. I've wrote units for it. I've run it in Debian while I'm running it now in NixOS. I even packaged stuff for it on a couple of distros. On the side, I'm doing some Guix stuff in a VM because I want to see a Debian-Ubuntu relationship evolve around a GuixSD-YetToBe package channel that stabilizes backports and packages non-free kernels and firmwares. I feel this will be the healthiest thing for the linux ecosystem right now since it will make sure all the work naturally flows back into the free base, as opposed to how things are now where free packaging is done after the fact.
As such, when I see work put into new Debian fork, it really pains me. If people are too lazy to figure out how to pull it off in Nix or Guix, just stick to using and packaging for Arch. There's no winning with forking Debian. You'll either fail to get a user-base, or succeed and end-up reliving all the conflicts we've had in Debian in the past since that's what that kind of design does.
compiling...
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @07:01PM
noone has hurt you, stop acting. what pain do you feel? you are free to do what you want as long others do. noone is giving pain to each other.
this is a passive aggressive attitude to say you are right and others are wrong
fucking systemd shiller
(Score: 2) by fnj on Monday May 30 2016, @10:39AM
Realistically, devuan, like ubuntu, is no more than a parasite on debian. They couldn't exist without debian. They can't CONTINUE to exist unless debian continues to exist. And in the case of devuan, debian controls whether it can continue to exist without systemd at all. If debian throws in with forces which promote systemd to grow malignant tentacles into every crevice, it could easily become prohibitive for devuan to keep it untangled.
(Score: 2) by Bot on Monday May 30 2016, @03:28PM
Devuan probably can't free all systemd dependent stuff, but as long as it lets people run a fairly complete stack without systemd, it is good.
I have been twice through the non mainstream crowd, first blackisting windows for MacOs, then dumping OSX for Linux. It paid off both times, in the long run.
Account abandoned.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @03:02PM
What about Upstart?
I was surprised no mention of Ubuntu's former init daemon replacement here. [devuan.org]
(Score: 3, Interesting) by JNCF on Monday May 30 2016, @04:54PM
The relevant excerpt from OP's link about Red Hat aiming for complexity (emphasis original, to show questions):
Do you think the Red Hat model would apply equally well to other areas of software?
Red Hat's model works because of the complexity of the technology we work with. An operating platform has a lot of moving parts, and customers are willing to pay to be insulated from that complexity.
I don't think you can take one finite element - like Apache - and make a business out of it [using our model]. You need product complexity.
I'm amazed how open they are about this obvious incentive that their business model creates. It seems like the sort of thing you wouldn't want to shout from the rooftops, if you were in the business of making open source software more complex than necessary. They don't say that they make anything more complex than necessary, but they spell out a motive quite clearly.
(Score: 1) by pvanhoof on Monday May 30 2016, @07:21PM
Men, it must be pure slavery for the poor Devuan developers to do git clone repo.git and then use git log to find the commit ids of commits related to systemd. Then do git checkout -b devuan and then revert all the commits related to systemd. Then run dpkg-buildpackage. Poor poor Devuan "developers"! The horror they have to endure is for me, as actual mantainer of some in-Debian packaged softwares, unthinkable. They actually have to do the slave-work that we maintainers have to do every single f. week, once.
To think that if they'd rewrite the revert patches with some #ifdefs, that we maintainers would reject their contributions and tell them to abstract it a bit must be pure hell.
Imagine that we fucking maintainers would ask them to, if they see a program-init.c, that they'd make a program-init.h with some abstractionitis and then have a program-init-systemd.c implementation and a program-init-openrc.c implementation. And then maybe we'd consider it (if they also patch configure.ac or the program.pro or the CMakeLists.txt file in the root of the sources a bit, and follow our semantic-versioning guidelines).
Can you imagine the pure hell they have to go through? It's so horrible! I know. It's what the guys who are actually working on systemd packaging do, all the times.
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @05:56AM
They refuse to fix the bastille-linux perl and TK scripts, as they don't like the person suggesting it.
They pooh-pooh the idea of hardening scripts alltogether.
(Score: 2) by Bot on Tuesday May 31 2016, @10:05AM
If you don't like devuan, then help out antix, or make its fatter cousin mxlinux more systemd independent. Or look at what mr. Knoppix is doing [youtube.com]
Account abandoned.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:14PM
Well, Devuan certainly managed to release an impressive 4.5 GB netinst image :D (Yes, their "DVD image" doesn't actually use the contents of the DVD.)
Did they manage anything of note besides that?
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:54PM
You must live in a parallel reality...
(Score: 5, Informative) by Marand on Monday May 30 2016, @07:42AM
Don't worry, it's just part of RedHat's gentle push [freedesktop.org] to make all distributions uniform by making it as hard as possible to not do things their way. Why not just roll over and let them do what's best for you?
The good news:
1) Your distro of choice may decide it's a stupid fucking default (because it is) and change it back to KillUserProcesses=no
2) If they don't, you can still set it yourself in logind.conf
3) Some distros still allow the use of alternate init systems. Debian still has sysvinit-core, for example, along with openrc, minit, upstart, runit, and probably more. I think Ubuntu users are screwed, though, because Canonical purged sysv init and most (all?) other init systems years ago to "encourage" upstart adoption. Sucks for Ubuntu users I guess, but that's what they get.
The bad news:
This will probably bite you on the ass eventually. If not now, then later, because it's another "gentle push" to make everyone do things their way or gtfo. If not this, then something else will.
At least the tmux dev didn't roll over and accept the idea of adding libsystemd and/or pam as a hard dependency, and politely told them to go do shit the right way instead of trying to push tmux into doing things the systemd way. I'm not against alternate inits, but they should at least attempt to work with the existing infrastructure (SIGHUP exists for a reason, for example) instead of demanding every process be modified to accommodate. Especially when it's a dumb fucking hack job "fix" like this.
(Score: 2) by canopic jug on Monday May 30 2016, @07:54AM
Money is not free speech. Elections should not be auctions.
(Score: 3, Interesting) by Marand on Monday May 30 2016, @08:28AM
Because in this case, the discussion is about systemd's process management portion, e.g. the init system. Yes, systemd-the-project is an entire BSD-esque "core operating system" stack, but this is actually relevant to the init portion. Granted, it's about how it's overreaching and fucking up established methods of dealing with processes, daemons, etc., but it still fits.
Though, now I'm curious if the logind portion can still misbehave with regard to this setting, even without the init portion running... I'll have to test that later. So far I've tolerated the logind portion because it's been fairly inoffensive, but if it starts fucking with my processes even without the init installed, it'll probably end up purged along with the systemd init.
(Score: 1, Informative) by Anonymous Coward on Monday May 30 2016, @03:48PM
No, it's not. The init system should not be concerned with user logins/session management.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @04:29PM
Its not, directly, but it is the one part of the systemd stack that is in charge of managing cgroups.
When you log into say Gnome on a systemd distro, Gnome talks to logind, that talks to systemd-pid1, that then wraps that login in a cgroup.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @04:33PM
sysv init has handled starting login daemons since forever.
xdm/lightdm wiggled inbetween. but imho it actuyally *is* init's task to start login daemons
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:25PM
You are confusing bootup with login.
No, init do not start login "daemons". That is done by the shell via a config file read on launch.
All init does is set up the ttys and make sure login (its and actual program) runs on them.
Login is in turn in charge of making sure the username and password matches, and then fire up the shell specified in for that user. Init could not give a flying fuck what is going on during all this, unless something happens and it gets handed a orphan process by the kernel.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @07:09PM
Here's what a Gentoo inittab looks like:
It really looks like init is starting agetty (text console login) in addition to xdm (actually lxdm for me but could be kdm etc).
(Score: 0) by Anonymous Coward on Monday May 30 2016, @07:13PM
Ah i see, we are calling anything that is running in the background for daemons now.
Not really any more helpful than calling everything a service.
(Score: 2) by sjames on Tuesday May 31 2016, @06:41PM
Yes, it starts them, but that's the end of the relationship. They are not expected/required to make call backs.
If a login wants to do anything with cgroups, it should just ask the kernel itself.
(Score: 2) by Marand on Tuesday May 31 2016, @03:50AM
Follow up:
Looks like logind will still screw with processes even without the init part running, so if you have systemd-logind running at all -- a lot of desktop stuff requires it now thanks to systemd's creeping nature -- you'll need to change /etc/systemd/logind.conf as mentioned in my above comment. That, or switch to a window manager that doesn't use any of it, which should still be possible in Debian.
So, you still have to watch out for this specific issue even with an alternate init, but the general point still stands: it's fixable, hopefully your distro of choice will revert to the sane option, and if your distro hasn't completely eliminated non-systemd inits, you can swap to another init and then purge the other systemd parts if you desire.
I've had my issues with the init part, which is why I don't use it, but I gave the other portions of it a chance; so far, this is the first time the non-init parts have caused any real issue for me. It's definitely worrying but at least it's still adjustable. Heh.
(Score: 2) by chromas on Monday May 30 2016, @07:54AM
Wouldn't this be the perfect use case for systemd's socket activation buttmagic?
(Score: 5, Insightful) by Anonymous Coward on Monday May 30 2016, @08:06AM
Why not fix what is broken? dbus and Gnome? I usually am called a troll here for my opinions on linux. But that just seems backwards. Why fix something that is not broken, break a bunch of other stuff. Why not go after the real bug? Am I missing something?
(Score: 5, Insightful) by Aiwendil on Monday May 30 2016, @09:05AM
Because that would be the sane way of doing things, and if they where sane they would also start splitting systemd into a herd of systemd deamons that could easily be interchanged with other software of similar capabilities..
Akin to the old way of "do one thing but do it well"..
Or put another way - once you start doing stuff the easy way it is hard to let go of that habit.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:23PM
Or put another way - once you start doing stuff the easy way it is hard to let go of that habit.
This habit started with Linux which is a Kernel that did kernels the easy (monolithic) way. The GNU/Linux project has been slated for a huge entropy gathering cluster fsck and downhill careen ever since... and systemd is just the biggest boulder rolling down that slope.
Posted from my systemd-less Slackware slackstation. [youtube.com]
(Score: 2) by Aiwendil on Tuesday May 31 2016, @07:09AM
I kinda agree with that, however the GNU tools are pretty portable in the other hand - so one have to give linux some credit for trying to limit its influence on the programs that depends on the system it provides.. (ie - the linux-people are aware that if they brake anything its their responsibility to provide compability layers)
(Score: 2) by tangomargarine on Tuesday May 31 2016, @01:54PM
So point to a major operating system in widespread use that uses a microkernel.
You can't? Whoops!
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by Aiwendil on Tuesday May 31 2016, @06:05PM
How about Symbian? (The pre-let's-get-shafted-by-microsoft OS used in nokia phones)
Considering the durability of old nokia-phones I'd be surprised if there wasn't a few million of them still around.
(Score: 2) by tangomargarine on Tuesday May 31 2016, @06:46PM
Not exactly my definition of a "major operating system." In the same ballpark perhaps.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by Aiwendil on Tuesday May 31 2016, @08:45PM
(btw, noticied symbian still was used in some phones released in 2014)
Well, let's take a bigger player then - QNX (forgot about it in my previous post)...
(Score: 2) by tangomargarine on Tuesday May 31 2016, @09:43PM
QNX was one of the first commercially successful microkernel operating systems[citation needed] and is used in a variety of devices including cars[2] and mobile phones.
QNX offers a license for non-commercial and academic users.[4]
The BlackBerry PlayBook tablet computer designed by BlackBerry uses a version of QNX as the primary operating system. Devices from BlackBerry running the BlackBerry 10 operating system are also based on QNX.
Getting a little closer...
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by Aiwendil on Tuesday May 31 2016, @10:02PM
Just how many units do you want? QNX isn't uncommon in embedded systems (everything from TVs to robo-vacs, to home automation to nuclear power plants to modern cars, to aeroplanes to space shuttles).. heck, I wouldn't be surprised if there are more QNX systems than MacOS X running..
(Score: 2) by tangomargarine on Tuesday May 31 2016, @10:23PM
I'm not talking about number of units, but what the units are. Obviously for embedded stuff it's probably going to be microkernels. It's like being surprised that I use a 12-ounce cup to get a drink of water instead of a 5-gallon drum.
Okay, power plants and aircraft are fair enough. I'm just musing out loud here :)
While I've got you here, is there supposed to be some meaning to double-periods? I'm aware of ellipses but not doubles.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by Aiwendil on Tuesday May 31 2016, @11:06PM
I see more embedded systems than desktops a normal month and consider the desktops to be the oddball - but if you restrict it to the user-interactive things you still have the entertainment systems in cars, heartmonitors in medical, control interface of trainsystems, control interfaces of automated manufacturing plants, check-in systems in mass-transit.. or put anothrer way - it's normally one of QNX, WinCE or Windows Embedded* you are interacting with as soon as you are at a non-desktop[conventional], non-tablet in a non-consumer setting and have a graphical interface.
* = Windows Embedded is hybrid kernel.
The double periods are just a bad habit of mine, I use it in my drafts whenever I consider an argument to not be completed but completing it would require me to be overly verbosive. Mainly tend to forget to remove them while typing from the smartphone.
(Score: 2) by LoRdTAW on Tuesday May 31 2016, @08:33PM
Who said it has to be a microkernel? See Plan 9: http://foswiki.cs.uu.nl/foswiki/pub/Swa/CourseLiterature/arch-F.pdf [cs.uu.nl]
(Score: 2) by tangomargarine on Tuesday May 31 2016, @09:38PM
Well if you're bitching about any OS being monolithic, microkernel is the only other thing, really. It's not like you're going to complain about Linux being monolithic as a reason why it should be rewritten in Java or relicensed BSD or something...
As I recall from a bit of reading, Plan 9 From Bell Labs was basically the "more UNIX than UNIX" OS?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Monday May 30 2016, @09:29AM
I usually am called a troll here for my opinions on linux.
I have never seen Anonymous Coward called a troll for views on linux. Unless you are in fact he of the hirsute peds. Log in, oh gentle user, so that you may be properly flamed with directed fire, instead of calling down upon us all a deluge of scorn and fire. Just because we, too, are AC. Who is Spartacus? Why does Spartacus use systemd?
(Score: 1, Touché) by Anonymous Coward on Monday May 30 2016, @08:09AM
If you're going to use stupid crap like that you might as well get the industry standard crap. And at the rate things are going it might actually run better and be more stable/reliable than this rube goldberg stuff.
Windows 7 isn't going to get phased out anytime soon, the Large Enterprises aren't switching to Windows 10. They only just switched to Windows 7 (or are still migrating).
That way you can spend more time and resources using your apps rather than dicking about with your OS. Which is supposed to be the whole frigging point of having an OS.
(Score: 2, Informative) by Scruffy Beard 2 on Monday May 30 2016, @09:02AM
I suspect this is a troll, so I will mostly respond with a stock answer:
When Free Software Isn't (Practically) Superior [gnu.org]
That, and for mere peons, Microsoft is resorting to dirty tricks [soylentnews.org] in order to install Windows 10. Between that and telemetry, MIcrosoft is now openly hostile to their (non corporate) user-base. The average user is now replacing the QA department, which does not bode well for stability.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:11PM
Well if the Windows 7 marketshare _increases_ vs Windows 10, that might convince Microsoft they're heading in the wrong direction.
You may laugh, but they did backpedal a bit after the Metro UI thing, and they did respond to the Vista complaints.
Any signs of backpedalling for systemd?
It seems every time Microsoft screws up (Vista, Metro etc) the Desktop Linux people sabotage their own stuff to make it even less attractive (pulseaudio, Unity, systemd etc). If you don't think Desktop Linux stuff was getting bad during those times, then explain why there was so much significant forking? e.g Linux Mint/Cinnamon, MATE etc.
(Score: -1, Redundant) by Anonymous Coward on Monday May 30 2016, @08:15AM
ftw
(Score: 5, Insightful) by sjames on Monday May 30 2016, @08:32AM
Kill systemd with fire.
I have no desire to run Potterix.
(Score: 2, Funny) by Anonymous Coward on Monday May 30 2016, @08:56AM
I have no desire to run Potterix.
Now, come on. I hear that J.K Rowling is working on a Harry Potterix distro. Doesn't that sound like good fun?
(Score: 2) by TheGratefulNet on Monday May 30 2016, @09:05PM
I could care less if it were JK FlipFlop writing Transistorix5v; I would still hate system-d.
"It is now safe to switch off your computer."
(Score: 0) by Anonymous Coward on Monday May 30 2016, @09:02AM
How can we cut his funding? That is the ONLY way.
(Score: 3, Interesting) by Scruffy Beard 2 on Monday May 30 2016, @09:08AM
Make a distro that becomes popular simply because it blacklists all software written by him?
I would not be surprised if such a system turns out to work better than the systemd/pulseaudio mess.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @09:53AM
I would not be surprised if such a system turns out to work better than the systemd/pulseaudio mess.
Since you mentioned "pulseaudio" I just have to weigh in and say
SLACKWARE! NO!!! WHY!!!!!!!!!!!!!?????????
(Score: 5, Interesting) by linuxrocks123 on Monday May 30 2016, @10:29AM
"WHY!": Because BlueZ doesn't support ALSA for Bluetooth audio anymore.
"NO!": I wrote the "Removing PulseAudio Completely" section of this wiki page which details how to remove it without getting dynamic loader errors when running anything that uses audio: http://docs.slackware.com/howtos:multimedia:pulseaudio_non-default [slackware.com]
You're welcome :)
The software is "apulse", which I didn't write, and the nice thing about the approach I document there is that, in theory, you should still be able to use software that requires PulseAudio, maybe even including BlueZ, but apulse was written just to make Skype work and so any other PulseAudio software might or might not actually work with apulse. The concept is really nice, though: apulse provides a fake "libpulse.so" that exactly mimics the PulseAudio API but just translates the API calls to ALSA instead of spawning a daemon and throwing shit everywhere like the real PulseAudio library does.
(Score: 2) by bitstream on Monday May 30 2016, @12:57PM
In what way does PulseAudio throw shit everywhere?
Btw, How does one arrange sound device over IP without PulseAudio?
(Score: 1, Interesting) by Anonymous Coward on Monday May 30 2016, @01:26PM
I don't think I've had the need outside of audio streaming like shoutcast. I suppose it'd be possible to write network-capable sinks and hook them into asound.conf. Then again, I'm also looking forward to Wayland (without systemd) because I have no need to display GUI programs remotely. ssh works fine for doing admin stuff on my servers.
I don't know what GP meant by throwing shit everywhere. The one time I used PulseAudio in the bad old days before ALSA's dmix made things just work I absolutely could not eliminate a 1 second delay from even local audio. Somebody, either here or on the old site, explained the potential problem to me recently, but I never looked into it. I just switched back to ESD, noted that network transparency for audio was a neat trick, and went on with life.
I believe JACK will do network transparency as well. JACK is good enough and low-latency enough to turn my desktop into an effects box for my guitar, but I never played around with its networking support.
Now, if I had infinite free time, I probably could write you a network transparency sink for ALSA. The other one I've been wanting to write is a sink that allows dynamically switching its audio sink on the fly so I can switch between headphones and speakers without pausing whatever's playing whatever and switching each application over to a different sink. I'm guessing neither of those exist because there's simply not a big need for either.
(Score: 2) by bitstream on Monday May 30 2016, @01:42PM
I suspect the inherent problem is that of packetization and thus as a consequence latency. Interprocess communication is affected by scheduler and so on. An open file handle can usually handle byte-by-byte usage but a network connection would likely become a mess in such scenario. Perhaps if the (network) connection where handled by the kernel and the pathway consist of circuit connections like in ATM, perhaps then it could work without serious issues.
I simple suspect anyone trying network audio, even internally within a computer will be fighting the basic architecture and thus all approaches will be tainted in some way.
(Score: 2) by Scruffy Beard 2 on Monday May 30 2016, @04:21PM
I believe that JACK does network audio first, then if you want to hear the output, you remix it for your soundcard's clock.
The packetization would have a mostly predictable latency because the bandwidth used it predictable. As for scheduling latency, JACK wants to run with the "Real-time" process priority. The Debain configuration script warns that can cause crashes if you are low on memory (I left that disabled).
I never did get it to work across the network: multicast failed for some reason I never had the time to trouble-shoot.
(Score: 2) by sjames on Monday May 30 2016, @09:07PM
Some professional audio distribution systems use raw ethernet packets in order to reduce overhead and latency. They also use real time scheduling.
If the network audio has a long duration, you also run in to problems with sample clock disagreement. You have to have at least a small buffer so you can drop or duplicate samples to sweep that under the rug without it being human audible or risking under/overflow..
(Score: 2) by Marand on Monday May 30 2016, @08:57PM
I believe JACK will do network transparency as well. JACK is good enough and low-latency enough to turn my desktop into an effects box for my guitar, but I never played around with its networking support.
It will, and it works great, but at the requirement of more configuration and manual effort. Biggest problem is lack of JACK-aware programs, so you have to route ALSA through JACK and then back through ALSA via configuration wizardry to transport general system audio. Once it's working, you link the audio to network output on one system and link network input to speaker output on other and it's done. The linking can be automated once you get it sorted out, of course, like any other patchbay setup.
Bandwidth use seemed higher than pulse, though, it still generally works fine, even over wifi. Only exception was this one old router that crashed and rebooted any time I tried, but that was a router problem; it would overheat because it was shit.
JACK gives more control and better latency/quality, but Pulseaudio wins at making the process more idiotproof, assuming PA works at all for you. (It tends to have issues on my system for some reason. Fine on laptop though.)
(Score: 2) by sjames on Monday May 30 2016, @09:10PM
I killed pulseaudio for a variety of reasons. Often it just didn't work, but even when it did work, it was too jittery to keep it synced with video well enough for even casual viewing.
(Score: 2) by Marand on Monday May 30 2016, @11:45PM
My problem is excessive cpu use and unnecessarily high audio latency (local audio, not network). The latter will never improve because it's just not a goal with pulse; they've said before to not use it if latency is a concern. So I tend to not use it on systems where it matters, though the laptop gets a pass because I don't care there as long as the cpu issue doesn't crop up.
(Score: 2) by VLM on Tuesday May 31 2016, @12:15PM
because I have no need to display GUI programs remotely. ssh works fine for doing admin stuff on my servers.
The only exception I'm unfortunately personally aware of is mythtv-backends can only be configured via a slow painful agonizing GUI. My backend is headless and physically far away from my frontends, which sounds pretty funny out of context. Anyway life is pretty easy when you can configure the backend by networked X while standing in front of a frontend.
I've used RDP at work and to a lesser extent, at home, for headless systems that need a GUI. Pretty cool to have the same dev environment on an ipad or an android tablet or my phone or any other computer. I'll probably rig something up on the mythtv-backend so it thinks its using X locally but I'm actually talking to it over the network. In the end that would be nicer as I could mess with the backend config using one of the kids ipads while testing on the frontend.
Something I kind of like is a tricked out emacs with all the addons connected to via whatever RDP screen is nearby. Its a nice flexible development environment. It means I'm developing on a giant machine of essentially infinite resources with all the speed you'd expect yet my laptop doesn't get warm and the battery lasts quite awhile because all its really doing is shoveling from network to screen.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @07:33PM
Well, this might be good, thanks for the response.
Still, as someone who never uses bluetooth (and is always sadly disappointed when we try for whatever reason), it strikes me as odd that we'd crack open the gates just to let some additional systemd-influenced sound bullshit behind the walls.
Especially for an OS that has done so well in the past at avoiding all this weird freedesktop/gnome b.s.
(Score: 2) by digitalaudiorock on Monday May 30 2016, @03:06PM
+1000. I've never been happier to be a Gentoo / openrc user reading this crap.
The fact that you can "configure" systemd so as to not do this is menaingless to me. The whole thing just continues to prove that the reigns of Linux have been handed to clueless fucking idiots.
A huge part of good software design comes down to dirt simple common sense...for example, knowing what the fuck it is you're actually trying to do. That's the sort of thing that keeps you from designing shit that has bizarre "you kill me then I'll kill you", chicken before the egg, catch-22s built into it...which seems to be where this BS came from. There just are no words any more.
(Score: 2) by Bot on Monday May 30 2016, @10:01PM
> Kill systemd with fire.
# kill -FIRE 1
bash: kill: FIRE: invalid signal specification
I am afraid you cannot do that, Dave.
Account abandoned.
(Score: 5, Insightful) by jimshatt on Monday May 30 2016, @10:46AM
(Score: 3, Insightful) by Bot on Monday May 30 2016, @02:58PM
Poettering might be talented or dumb. It does not matter. He is paid by RH, RH and other distro incorporate his stuff. The responsibility is not his, it is of RH and the other systemd based, or should I say dependent, distros.
Back to topic I am not surprised. Systemd is meant to assimilate, it is assimilating.
From a theoretical point of view, the launched program that has to accomodate the launcher program is an abomination, not to the unix way, but to everybody minus INTERCAL programmers.
Account abandoned.
(Score: 3, Interesting) by fido_dogstoyevsky on Tuesday May 31 2016, @01:13AM
Poettering might be talented or dumb. It does not matter. He is paid by RH, RH and other distro incorporate his stuff. The responsibility is not his, it is of RH and the other systemd based, or should I say dependent, distros.
...so LP is just following orders.
the launched program that has to accomodate the launcher program is an abomination
+1000
It's NOT a conspiracy... it's a plot.
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @02:08AM
Just like Adolf Eichmann.
(Score: 2, Disagree) by SemperOSS on Monday May 30 2016, @10:48AM
Personally, I would not take it as an affront if somebody pointed out to me that by changing my code a little it would be able to support some systemd feature. I would mull it over, talk to my peers and make a decision whether to ignore it or not ... but causing an outbreak of systemd-bashing, I don't think so.
If systemd did not give you a choice, I could understand the sentiment, but it does. You can disable it at compile time (not an option for most, I know) or by making one little change of your setup.
So, why so serious?
Think about the early cars: No locks, you just opened the door and jumped in. Then suddenly somebody had the gall to put a lock on your car. I mean, what a pretentious idiot could come up with such an idea? Make a fuzz, shout from the top of the roofs, call on divine intervention ...
... Or just don't lock your door.
The choice is yours — and you actually have a choice!
All the same, I'm still going to hold on to Sys V init for as long as I can, systemd or not!
I don't need a signature to draw attention to myself.
Maybe I should add a sarcasm warning now and again?
(Score: 3, Interesting) by bitstream on Monday May 30 2016, @01:01PM
systemd just complicates matters. There are more productive things to do than to chase down how the system handles processes at logout. And on the macro scale it's about Red Hat trying to monetize free-open software. They need some serious negative feedback on this.
(Score: 3, Insightful) by Anonymous Coward on Monday May 30 2016, @02:08PM
I've been pretty ambivalent so far about SystemD, probably because I don't have the server management chops others have, but this decision here and in particular the reasons for it are very troubling. As another poster said, if the problem is that certain processes aren't cleaning up after themselves at logout, then fix that code. It comes off like SystemD is enabling bad coding.
(Score: 1) by kramulous on Monday May 30 2016, @11:56PM
I'm pretty much the same as you. I will add that when it came to having a program of mine run as a daemon, systemd was extremely useful and did the job well.
I don't think that it is enabling bad coding, more that it is cleaning up after bad code. God knows there is enough of that shit out in the wild.
(Score: 5, Interesting) by kurenai.tsubasa on Monday May 30 2016, @02:42PM
Personally I've been tepid about systemd. I've been meaning to throw it in a VM to play around with it since it looks like it's here to stay. I mean, if I ever got a Linux admin job, it probably wouldn't go over well if I said on day 1, “Tear it all down and install Gentoo!” For my personal stuff, Gentoo has worked well, and I'm glad they went with OpenRC. That way I don't need to learn the systemd equivalent of /etc/init.d/$service stop/start/restart/etc. :)
As far as dependencies, I have Weston (Wayland reference compositor) built and running just fine without systemd. Same goes for Enlightenment E20. I just added -systemd to my package.use and also a section in package.mask (labeled # Lennart Poettering) to be sure that masks systemd, PulseAudio, and NetworkManager.
(An aside: I've had problems with both PulseAudio and NetworkManager. Neither will just work, and when there are things like ALSA that just work or wpa-supplicant that just works after editing a simple config file, I simply have no need for PulseAudio or NetworkManager. User-friendly is in the eye of the beholder. When I'm the user, user-friendly includes editing a config file every now and then instead of bumbling around in a GUI trying to hunt down the option I want. Or in NetworkManager's case, taking whatever I do in the GUI as a mere suggestion and doing whatever it wants to do regardless.)
However, if systemd is breaking things like screen and tmux, that's a red flag for me. I'm used to being able to do stuff like starting a screen session in X, detaching it to log out, then logging back in on a console and re-attaching it. It's handy when I'm futzing around with Wayland.
So to run with your car analogy, it would be as though somebody wanted to put a lock on my car (that already has a lock) that sometimes wouldn't lock or unlock unless I shut my car completely off and started it back up. Then I'd discover that it just magically locks itself whenever it feels like instead of predictably doing so at 3 mph. When I report the problem, the person who wanted me to have this new kind of lock refuses to fix it and instead blames the rest of the door assembly! I'll keep my existing locks, thanks.
So basically, if screen in particular is broken by systemd, which TFA seems to indicate, systemd would break a use-case for me. It's also suspicious that the reason it's breaking tmux (and screen), at least according to TFS, is because Gnome can't clean up after itself. The whole thing just smells bad.
I mean, I brought up Wayland because I'm looking forward to it becoming mainstream or at least better supported. I wouldn't expect anybody to switch over to using it 100% right now. Nvidia claims support now but apparently they have a disagreement about some part of Wayland's API—fair enough since Wayland is the newcomer and it's good to see Nvidia's willingness to support it. Things are getting ironed out, but once support is there, I will be switching over from X11. I'm not afraid to do new things when they make sense, and everything I've read about Wayland makes a good deal of sense. Naturally it would, because it's the Xorg developers themselves who are now saying that the cruft runs so deep that even Xorg isn't cutting it. (Not to mention I remember how much of an improvement Xorg was over XFree86.) Hence, they came up with Wayland.
systemd on the other hand seems to be the brainchild of somebody who's already created two wonky, half-working packages, PulseAudio and NetworkManager, that at least seem to be trying to address a deficiency somewhere. With init systems, first there was upstart, which always seemed wonky to me, and now systemd. The whole thing seems like a solution in search of a problem, or at least a solution to problems that were caused by a single desktop environment I don't even use, Gnome. I'm also suspicious about just why we need an init system to handle Gnome's user sessions.
PulseAudio and NetworkManager at least are easy enough to tear out of Ubuntu-based distros. With systemd metastasizing across the entire base system (and let's be fair: systemd is modular if one takes a look), it's not looking very easy to pull that one out by the roots. When it causes problems with software like screen, given that so many distros have switched over to it, I think that's a practical enough concern to sound the alarm. Granted, this isn't as serious as when systemd was parsing the kernel command line and vomiting all over klog, but it's a clear pattern. Everything that systemd breaks is just somebody else's fault. I have a feeling that we don't hear so often about Wayland because there's no push yet to replace Xorg, and the developers aren't arrogant enough to demand that say Audacious change the way it works because gtk+'s Wayland support for whatever reason is putting the visualizer at the bottom in its own window instead of where it's supposed to be.
Even in that specific example with Audacious, I have a feeling that the visualizer is getting its own window under Wayland because the Audacious developers had to work around something wonky with X11. When it comes to screen and tmux, I don't see why something as simple as a trusty old daemonize needs to be broken. If I start a process, I intend for that process to keep running until it's done or I send it sighup. systemd is treading on thin ice by breaking that.
But essentially you're right. As a Gentoo user, I haven't had to give two shits about systemd. Yet.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @04:49PM
I hate to say this, but pulseaudio got better once the idiot poettering moved on from it. Network manager though is a piece of crap.
I use pulseaudio because i use steam on linux and many games need it for audio. apulse doesn't cut it and I have moved on from desiring to fiddle with a system wide asound or user asound file every time i want to do something different. Play games, put this in the asound file. Listen to music, have this instead.
Poettering may be an idiot, but linux DID need a better audio manager on top of alsa drivers. When he moved on to the 'next shiny thing' others made it at least palatable. I'll keep using pulseaudio until it becomes hard linked to systemD, then i'll jump ship to whatever fork is created by similar minded people.
Also just to point out a few years ago I would have sided with you, then I was forced with a choice. Keep having to do this, eat up more of my limited time after work and find myself limited even more in what games i can and can't play. Or just bite the bullet and use it. Turns out others made it better after he left and I was just being stubborn.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:10PM
There is apparently a way to make pulseaudio just a passthrough, without having it hog the alsa /dev files.
https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device [archlinux.org]
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @12:49AM
Ah yes, one of the many hacks i tried that didn't work.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @09:30PM
Oh, holy crap, YES! The hours I wasted on that POS when I didn't know better.
(Score: 1) by SemperOSS on Tuesday May 31 2016, @04:11PM
Your comment is well put and I agree with you on most of the points, but that said, it is actually somewhat off topic (as almost all other comments are whenever a specific systemd problem is mentioned). In this case, we should just be discussing whether other projects should cater for the new behaviour in systemd to kill all processes when a user logs out, or not, not systemd as a whole.
And yes, the two issues can and should be separated.
Whether systemd is fit for purpose or the wrong solution to a non-problem is not what this is about. Whether Poettering screwed up PulseAudio and NetworkManager or not is not what this is about (He did!) Whether systemd breaks applications like screen or tmux is not entirely what this is about either. (Although systemd does not necessarily break them as you can turn off the offending behaviour and have a system that works — in that respect, at least — just as it did before. A fact that seems to be completely overlooked in this discussion.)
What this is about is whether the systemd team should or should not make other projects aware that they would have to make changes to make their programs work correctly with this systemd feature enabled.
Another spin-off discussion could be whether the changed behaviour is actually an improvement or not. That discussion would be pertinent and something we probably could learn from.
I don't need a signature to draw attention to myself.
Maybe I should add a sarcasm warning now and again?
(Score: 2) by Bot on Tuesday May 31 2016, @04:31AM
You do not take into account that systemd is linux specific, and in a state of flux.
Why on earth should a free software dev complicate or fork his project to accommodate this? would you?
RH should fork it themselves instead of having unpaid volunteer time devoted to build castles on their sand.
Account abandoned.
(Score: 1) by SemperOSS on Tuesday May 31 2016, @03:52PM
In fact, I said that the developers should consider the possibility and either accepting it or rejecting it for inclusion in their project. The change may break some functionality but if you cannot live with that, disable the change, no reason to moan about it just because it is a pet hate project.
And just so you know, I have no connection to Poettering or systemd. In fact I try to avoid it as best I can, but please give the people some credit for not just forcing this change upon the unsuspecting world.
I don't need a signature to draw attention to myself.
Maybe I should add a sarcasm warning now and again?
(Score: 0) by Anonymous Coward on Monday May 30 2016, @01:12PM
We do not care what you want to do.
We do not care how yo want to work.
We do not care about your prior choices.
We a MicroS... strike that... We are Linux with SystemD That is with "D", as in "We are DEVIL in the details or the lack of)"
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:00PM
What is semi scary is systemd's/redhat way of doing things is making MS look nice.
MS windows actually has a fairly NICE system service startup system. I have used and coded it for years. This systemd junk on the other hand you break someone elses code and system and then expect them to fix it for you? That is not going to fly. Most people are going to look to off load the idiot who is changing things for the sake of change.
If there is a bug in dbus/gnome FIX THOSE dont pick dumb default startup items to fix a boundary condition.
Its pulseaudio all over again.
(Score: -1, Troll) by Anonymous Coward on Monday May 30 2016, @06:44PM
So use devuan or one of the other forks, and quit whining. Problem solved
(Score: 0) by Anonymous Coward on Monday May 30 2016, @01:53PM
SysD is one.
(Score: 2) by Bot on Monday May 30 2016, @03:18PM
Juan Pablo Daniel @jpdborgna 15h15 hours ago
"Systemd is pretty much a nonsensical nonsolution to an imaginary nonproblem." #systemd--
Nailed it.
Markus Lindenberg @moreentropy 18h18 hours ago
I'm tired of #systemd hate. It's not about how Unix was conceived 25 years ago but how I want my services to be run in 2016.
Great troll or average systemd user? Difficult to tell.
Account abandoned.
(Score: 1, Insightful) by Anonymous Coward on Monday May 30 2016, @03:56PM
Nobody would care if they had forked Linux and created Poetterix, just as Google did with Android. The problem is that this is forced on users who definitely don't want it. Offering more choice is good. Eliminating choice because "we know better" is bad.
(Score: 2) by Zz9zZ on Monday May 30 2016, @11:28PM
This is the rationale that seems to be beyond the sysd supporters... Leave the user with choice!
~Tilting at windmills~
(Score: 1, Informative) by Anonymous Coward on Monday May 30 2016, @06:44PM
1) For years, many people had to fix audio on Linux by removing Pulse Audio.
2) My instant messenger did not work because avahi-daemon interfered with DNS on the corporate network, which happened to use .local. I turned that service off and things just worked.
3) After rebooting, my Ethernet adapter would not acquire an address. I turned NM_CONTROLLED to no, and it just worked.
All 3 of these issues came from one person's software design. Excluding obscure hardware support, MySQL, and these 3 issues, my Linux experience would be very pleasant. systemd is clearly more defective by design then all 3 of these put together, so putting it on my system is literally insane (doing the same thing over and over again and expecting different results).
(Score: 0) by Anonymous Coward on Monday May 30 2016, @03:59PM
user processes started as part of a login session are terminated when the session [exits]
Sorry but, what the fuck is a session? I thought my login prompt just checks my password before setting uid/gid/env/workingdir and execing my shell? What if I don't have dbus? I don't understand any of this, what's going on here?
(Score: 2) by Scruffy Beard 2 on Monday May 30 2016, @04:44PM
Sorry but, what the fuck is a session? I thought my login prompt just checks my password before setting uid/gid/env/workingdir and execing my shell? What if I don't have dbus? I don't understand any of this, what's going on here?
Good question. As far as I can tell, they are trying to emulate the (useful) Windows XP "switch user" functionality.
A saw a video a while ago where the behaviour of changing permissions to things like the audio device (upon login) was being criticized. Pottering interrupted the presenter. explaining that there was no other way to provide accessibility features than to run things like pulse audio before the user even logs in. My google-fu fails me at the moment.
(Score: 2, Informative) by Anonymous Coward on Monday May 30 2016, @06:31PM
Sounds like Datenwolf's presentation on unix cruft.
https://www.youtube.com/watch?v=ZTdUmlGxVo0 [youtube.com]
Note that it is perhaps the only presentation during a Linux related conference where the presenter have been continually interrupted by someone in the audience making "corrections", never mind having said "correcter" step up on stage at the end.
And yes, one of their goals is trying to create a multiseat setup out of a desktop PC. This by grouping various hardware (keyboard, mouse, screen, possibly more) and then tying that group to a user based on the keyboard used for logging in.
They are effectively trying to recreate physical terminals from multiple independent hardware attached to a single computer.
(Score: 2) by Arik on Tuesday May 31 2016, @04:10AM
The man is such a jackass. I honestly can't understand why he wasn't simply banned from every meeting and email list of any importance a decade or more ago.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @05:21PM
Because he works for RedHat and they have all the money. There probably isn't a single Linux related conference that RedHat doesn't sponsor to get their name on it. If conferences banned their employees, that sweet, sweet cash would dry up. But you can be sure that his boss at RedHat told him to calm down because he has been better of late. Nobody wants customers leaving and going somewhere else due to the behavior of a single employee, regardless of who it is.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:21PM
Session is an abstract concept that group processes.
The Linux kernel actually have a notion of sessions internally, but it is largely transparent to most users.
In essence a CLI session would be the login process (what runs on every TTY) that then spawns a shell process once you successfully log in. Then anything you run via that shell is part of the same session, unless special commands or programs are used that effectively move one or more processes to its own session.
A session effectively ends when the shell process at the root of the tree exits, as then every child process is given the HUP signal, and should exit.
Similarly, a X session ends when the X server (keep in mind that in X terminology server and client is reversed) exits.
What you have is systemd creating its own notion of what is a session, and not giving a damn about what the kernel thinks.
(Score: 3, Informative) by Unixnut on Monday May 30 2016, @07:26PM
" In essence a CLI session would be the login process (what runs on every TTY) that then spawns a shell process once you successfully log in. Then anything you run via that shell is part of the same session, unless special commands or programs are used that effectively move one or more processes to its own session. "
So... sounds like what you are talking about are called "Process groups". A staple of Unix for decades. Why rename it to "Sessions"? Unless the goal here is to deliberately confuse and complicate things, I just don't see the point.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @05:18PM
Sessions and process groups have both existed for decades and are not the same thing. Sessions track all processes underneath a particular login. Process groups are all processes under a leader process. An example is if you run cat on a large file and it is piped into gzip. Sending a keyboard interrupt will be sent to all processes in the program group that is in the foreground (cat and gzip), but it is not sent to any groups in the background, nor the shell. However, on log out, all processes in the same session are sent the hang-up signal, regardless of whether they are in a foreground or background process group. For a better illustration, run the ps command on a running system with at least two logins and one background process running and list the processes with all the ID fields enabled (and there are a few, PPID, PGID, SID, etc.).
(Score: 0) by Anonymous Coward on Monday May 30 2016, @04:09PM
And you thought Microsoft is the deadly nemesis. Nope, it's the enemy within, Redhat, that will destroy Linux.
(Score: 1, Insightful) by Anonymous Coward on Monday May 30 2016, @07:38PM
Oh sure, SystemD totally sucks. (That's settled science at this point.)
But guess what, so do these other great innovations (mostly brought to you, it would seem, by RedHat):
xinetd
policykit
gnome
anaconda
dbus
avahi
SELinux
Apparmor
dhcpcd (or dhclient, depending on your perspective)
...and probably about 300 other "improvements" I can't think of right now.
The battle for Linux is long over. SystemD is just the final nailing of the coffin.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @11:51PM
You forgot all the "kits." Total amateur hour. Gimme a break, are all Linux devs in eighth grade?
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @02:17AM
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @01:01PM
SELinux was not originally Red Hat's, but the NSA's creature. It seems that the NSA didn't take that opportunity to hide a back door in there somewhere though.
OH YES because there's no way they'd want try--or even be able--to do that.
Return to your homes, there is nothing to see here. Just another spy organization writing free software because it's fun
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @01:23PM
Originally done by interns to test out a hardening technique they felt could make linux 'military grade'. I forget if they had already had another unix version of it prior to that, but it certainly wasn't an 'NSA' project in the traditional sense.
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @05:11AM
Told you so.
--MikeeUSA
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @05:15AM
Check it out at devuan.org
(Score: 2) by termigator on Tuesday May 31 2016, @03:13PM
I run background processes all the time at the user level (e.g. ssh-agent, delegate). This kind of change will break the ability for users to run processes in the background that persist after one logouts. Definitely seems arrogant to require all programs to explicitly be changed to support a use-case that *nix systems have allowed for decades.
The behavior pushed by systemd is what Windows does, and it is a PITA. Only way to stay persistent in Windows is to run as a Windows service, which is not possible for non-admin users.
Auto-killing user processes on logout should NOT be the default.
(Score: 0, Troll) by SemperOSS on Tuesday May 31 2016, @04:18PM
What peeves me in this discussion is the fact that most comments seem to ignore the fact that the offending behaviour of systemd can be turned off once and for all.
If your system needs users to run background processes, disable the feature and let them.
Easy as that.
Why so much talk about a feature that can easily be disabled? I don't know about you, but every time I install a new Linux system — no matter what distro — I have to tweak it to my preferences and this would be such a tweak, if I actually used systemd. (I don't.)
I don't need a signature to draw attention to myself.
Maybe I should add a sarcasm warning now and again?
(Score: 2) by termigator on Tuesday May 31 2016, @05:53PM
For those that want the feature, then they can *explicitly* enable it. My complaint is changing the default behavior, a behavior that has existed for decades on *nix-type operating systems.