Earlier quoted context omitted.
Didn't upstart and launchd cover this before systemd?
launchd was for OSX.
Oh, whoops. Wasn't there another Linux init system around the same time?
How to Crash Systemd in One Command
111–120 of 193 posts
Re: How to Crash Systemd in One Command
#112Earlier quoted context omitted.
You refuse to look, and thus have clarity. Dude that is not a good argument. What is not uniform about the previous service handling implementation in debian?
> You refuse to look, and thus have clarity. Dude that is not a good argument. What? Should I have to know everything about systemd to comment on one specific part of it? I don't know about alternative init systems either, all I wrote is that for service management: systemd >> SysV. > What is not uniform about the previous service handling implementation in debian? I can't tell you since I don't use Debian. I can tel…
> systemd >> SysV
Why are you framing the conversation as if these were the only options?
> I don't know about alternative init systems either
Oh, so you are speaking from ignorance. I suggest learning about the alternatives such as OpenRC and the management tools such as daemontools, runit, and s6.
There are many solutions to these problems, although they may not be supported (by default?) in your favorite distro. Judging the Linux ecosystem by the failings of one distro isn't helpful.
Re: How to Crash Systemd in One Command
#113First they came for PID 1, and we were silent. Oh, wait, we weren't. But although I don't miss the rickety init scripts, I've grown more and more worried about stuff like this, enough to ponder replacements (in Go or Python, which seem to be generally acceptable for systems software these days). Ignoring for the moment the usual biases against Python, how feasible/how much support would it be/have to build something…
I've been working at a Docker shop for a while and I have a feeling it will be the future for running services. It makes systemd somewhat irrelevant. There are still a lot of issues I've had with Docker, which I won't go into. It also can't replace everything running on your Linux system. But it's a neat idea and big players use it in production for huge workloads. Now the whole AWS-containers, docker-machine, swarm,…
Nah, systemd is angling to supplant docker for containers.
There is already a great deal of bad blood between the two because of the reworked cgroups management.
And there is also the likes of CoreOS that is basically systemd-the-distro.
Never mind that we have the likes of xdg-app/flatpak that is basically aiming for what you are thinking about, and it is systemd dependent.
Re: How to Crash Systemd in One Command
#114Earlier quoted context omitted.
Mac absolutely can do that, I'm not sure why you think it can't, perhaps it couldn't in the past. I do it almost daily when I come home and plug in my Bose Companion 5 into my Macbook (USB Speakers)
Admittedly, it's been quite some time since I last worked on a Mac. Think 10.6.8 era. It could also have been a borked install as well. But I'm sitting in front of a Win10 install on a Surface 4 Pro, and it can't auto-sink audio.
Mac can do that, but it's also up to the software. Software can either detect when the default audio device changes, or it can grab the device at startup and never change. Google's software, for example, has demonstrated the latter behavior in the past for me (specifically, Google Hangouts has had a tendency to not notice if I plug in headphones+mic and continues to use the built-in mic instead).
Re: How to Crash Systemd in One Command
#115Earlier quoted context omitted.
I strongly disagree. I didn't need anyone to "show up" to replace my init system in production across several thousand servers, and the way systemd "won" that battle wrt Debian was, to be polite, controversial, political and extremely divisive. They sure as heck didn't win because "they showed up and no one else did". They showed up and RedHat's money showed up with them. I hold no animus towards the systemd project'…
> I hold no animus towards the systemd project's goals or aspirations, but I have yet to hear a compelling reason for systemd to be shipping in it's current state. I am, in a way, reminded reminded of PulseAudio. I kept PA of my desktop and laptop for years, having heard about PA being a complex nightmare to configure and make work that caused audio to break. Eventually, there was an application I needed to use that…
Best i can tell, Poettering cooked up PA back when ALSAs dmix was something you manually enabled on cheap soundchips.
Frankly i think it would have gone nowhere if Canonical didn't decide they needed to copy Windows' "one volume slider pr program" thingy that was introduced in Windows 7 or there about.
Note btw that these days Poettering is no longer involved with PA development.
BTW, the main goal of systemd seems to be to create a single baseline for desktop Linux in code rather than spec.
It is a "continuation" of the -kit mentality that spawned within Freedesktop (or frankly within Fedora, at it seems said distro is basically the Petrie dish for anything under the Freedesktop umbrella).
Re: How to Crash Systemd in One Command
#116Earlier quoted context omitted.
> I hold no animus towards the systemd project's goals or aspirations, but I have yet to hear a compelling reason for systemd to be shipping in it's current state. I am, in a way, reminded reminded of PulseAudio. I kept PA of my desktop and laptop for years, having heard about PA being a complex nightmare to configure and make work that caused audio to break. Eventually, there was an application I needed to use that…
PulseAudio took ages to get to a stable and reliable state. There are still warts (try and make your machine act as a bluetooth audio receiver. It's horribly ugly.) systemd wasn't reliable or fit for purpose for servers when it got shoehorned in to everything. When it comes to production servers you need stable and reliable. Not new and shiny. You're ideally rarely having anything happen on the server other than "run…
Sadly there are two definitions of server floating around these days.
There is the classical "box in the corner sending and receiving data over the network".
And then there is the new "bunch of software in a container in the cloud somewhere".
And with the latter definition, stable and reliable seems to be of lesser importance in the eyes of the faithful. This because they can just fire off a new instance of the container if the existing one falls over (Uptime by machinegun as i like to think of it).
http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...
Re: How to Crash Systemd in One Command
#117This article got me wondering if maybe the NSA or similar has somebody on the inside of the systemd project that is helping the project along. Systemd has replaced a lot of init systems in the linux ecosystem and the general development practices of the project is leaving a huge footprint of code that might be exploited. If they aren't involved, I'm sure they probably know a few different exploits for the system alre…
If you want to go down that rabbit hole, see:
https://igurublog.wordpress.com/2014/02/17/biography-of-a-cy...
Re: How to Crash Systemd in One Command
#118Earlier quoted context omitted.
> I hold no animus towards the systemd project's goals or aspirations, but I have yet to hear a compelling reason for systemd to be shipping in it's current state. I am, in a way, reminded reminded of PulseAudio. I kept PA of my desktop and laptop for years, having heard about PA being a complex nightmare to configure and make work that caused audio to break. Eventually, there was an application I needed to use that…
With PulseAudio, I have 1 singular feature that makes most people wow: When I plug in any new audio device, whatever I'm playing/recording automatically sinks to the most recent device. Seamlessly. So if I'm on mail.google.com and a GVoice call comes in, I can take the call, and during the call, plug in my USB headset. It just works. Mac can't do that. Windows can't do that. Linux/PulseAudio can. And that kicks ass.
USB headsets are a technological abomination.
You are talking about a headset welded to a soundcard, that you then insert into a data bus each time you want to use it.
Re: How to Crash Systemd in One Command
#119Re: How to Crash Systemd in One Command
#120Earlier quoted context omitted.
It's baffling to see people insist that that's the UNIX philosophy when the UNIX philosophy has always been about monolithic kernels over microkernels, so "do one thing" is out the window, and about worse-is-better over do-the-right-thing ( https://www.dreamsongs.com/RiseOfWorseIsBetter.html ), so "do it well" is out the window. And the userspace tools don't follow this either. Quoting http://prog21.dadgum.com/139.ht…
The Unix philosophy is most applicable in user space. It's a philosophy not a law. I didn't say Systemd was bad just that it doesn't observe the Unix philosophy. Crashing an init process is a very bad thing, is it not? Wouldn't less surface area be a better approach?
Yes, I argued in another comment that it would be a good idea to split systemd into two processes, where PID 1 does nothing other than reap children, send info to PID 2 actual systemd, and restart PID 2 if needed. But it seems to make sense for PID 2 to be as monolithic as systemd currently is (which is not very monolithic; udev, journald, D-Bus, etc. are separate daemons).