Earlier quoted context omitted.
Do you count signals as inter-process communication? I'd argue they are, and the init system definitely needs to cleanly shut down the system (using signals, at least). What degree of inter-process communication is acceptable, then?
Not OP, but I would consider SIGTERM as IPC, but SIGKILL as not really IPC (since the target can't respond to it). Traditional RC does a SIGTERM to everything, and then waits a bit and then does a SIGKILL to everything. This means that if the SIGTERM failed to be handled properly, progress is still made.
Why Did ArchLinux Embrace Systemd? (2016)
121–130 of 132 posts
Re: Why Did ArchLinux Embrace Systemd? (2016)
#122Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only…
Before using SystemD for the first time, I also wondered if there is any grain of truth in what its opponents said about SystemD. However, after trying SystemD for one week, I became convinced that the designers of SystemD are incompetent, so they cannot be trusted with a component of such importance for a computer. I am normally a Gentoo user, but a few years ago I wanted to install Linux in a hurry on a small compu…
Re: Why Did ArchLinux Embrace Systemd? (2016)
#123Ah, systemd. It's one of those things where I'm glad it exists, but I hate it. I'm glad it exists because more open source is good, and diversity of implementations is good. I hate it because it complicates my machine's startup process, and my life, unnecessarily, and puts a lot of shit in pid 1 that shouldn't be there. I don't want it to become a hard dependency of my entire software stack. (Same with PulseAudio, he…
As someone who's been slowly picking their way along the narrow crooked path towards free software / tinfoilhattery / unixbeardedness for the past several years, I'm interested to know which browser you use. I assume given context that Safari and IE are right out. Chromium and variants are probably out? If Firefox and variants are out (not sure if all of them have the pulse dependency, because honestly your comment w…
Re: Why Did ArchLinux Embrace Systemd? (2016)
#124Earlier quoted context omitted.
Because Linux and MacOS targets different roles.
Could you elaborate more? My use case is very similar between the two, and I don't mean workstation operation.
Re: Why Did ArchLinux Embrace Systemd? (2016)
#125Ah, systemd. It's one of those things where I'm glad it exists, but I hate it. I'm glad it exists because more open source is good, and diversity of implementations is good. I hate it because it complicates my machine's startup process, and my life, unnecessarily, and puts a lot of shit in pid 1 that shouldn't be there. I don't want it to become a hard dependency of my entire software stack. (Same with PulseAudio, he…
As someone who's been slowly picking their way along the narrow crooked path towards free software / tinfoilhattery / unixbeardedness for the past several years, I'm interested to know which browser you use. I assume given context that Safari and IE are right out. Chromium and variants are probably out? If Firefox and variants are out (not sure if all of them have the pulse dependency, because honestly your comment w…
So if Chromium is out, then so is qute.
Re: Why Did ArchLinux Embrace Systemd? (2016)
#126Earlier quoted context omitted.
As someone who's been slowly picking their way along the narrow crooked path towards free software / tinfoilhattery / unixbeardedness for the past several years, I'm interested to know which browser you use. I assume given context that Safari and IE are right out. Chromium and variants are probably out? If Firefox and variants are out (not sure if all of them have the pulse dependency, because honestly your comment w…
Qutebrowser is QtWebEngine underneath. (which is Chromium). So if Chromium is out, then so is qute.
Re: Why Did ArchLinux Embrace Systemd? (2016)
#127Earlier quoted context omitted.
Not OP, but I would consider SIGTERM as IPC, but SIGKILL as not really IPC (since the target can't respond to it). Traditional RC does a SIGTERM to everything, and then waits a bit and then does a SIGKILL to everything. This means that if the SIGTERM failed to be handled properly, progress is still made.
systemd does that too. The problem is that the default wait time is insanely long (I think it is something like 5 minutes). My biggest complaint with systemd is the same as my biggest complaint with tmux: many of the defualt configurations are very strange.
Weird as in 3 minutes after someone SSHd into my workstation, X11 restarted. Until I tracked it down to a default systemd configuration I thought I was going insane.
Beyond the default configuration, which is somewhat defensible as NIS is probably not a typical case, it really bothers me that if someone else's login process has issues, everybody's logins get killed.
Re: Why Did ArchLinux Embrace Systemd? (2016)
#128Earlier quoted context omitted.
You know, everyone says this but every server I worked on (several thousands) which used sysvinit I cant remember any issues with startups that couldn't easily be scripted around. I still dont understand what issues are fixed with systemd and I am aware of many it has created.
I am not convinced every sysadmin could ‘easily’ script around init issues on the servers they manage, but I’ll give you that. The real issue isn’t with servers, it’s with desktop systems and laptops. When users plug in a USB sound card or plug their laptop into a dock, they don’t want to (and likely couldn’t) “easily script around” that; they expect an audio device, network connection, video card to be created witho…
Also you seem to be conflating dealing with devices with initialization of the system. Dealing with such devices has insofar as I'm aware always been handled by c code in and out of the kernel whereas at one time initialization of services and orchestration of components was handled by a scripting language.
This is to say that a bash script may have brought up different components and services but that c code that makes up the component is in charge of actually managing said device.
Its obviously feasible for both c (or any other language) code and orchestration of start up and shut down of services to be buggy but its not equally easy for end users to fix their own problems in all cases.
Ideally bugs get reported to those who are most capable and the underlying code is corrected however if said labor isn't paid to work on their project hours to do so may be in short supply and it may frequently fall on users to lend a hand.
This is a numbers game. If you have 10000 users and 10 of them are qualified to solve such problems you may be lucky to get the help of 1 to submit patches or post a solution to a problem on a forums for others to use before the upstream problem is fixed.
If 100 are qualified you are 10x as likely to find help to solve a problem. I have on many occasions come across a solution months or years before an official upstream solution came into being. You are suggesting that most sysadmins might find it challenging to solve their own problems. They don't always have to. Merely having comprehensible user friendly systems make it more likely that one of their fellows can help them do so and more likely that such solutions travel both laterally between users and hopefully upstream solving the problem for all.
Re: Why Did ArchLinux Embrace Systemd? (2016)
#129Earlier quoted context omitted.
As someone who's been slowly picking their way along the narrow crooked path towards free software / tinfoilhattery / unixbeardedness for the past several years, I'm interested to know which browser you use. I assume given context that Safari and IE are right out. Chromium and variants are probably out? If Firefox and variants are out (not sure if all of them have the pulse dependency, because honestly your comment w…
Currently? PaleMoon. It doesn't have a Pulse dependency and it works with every site I throw at it. We'll see if that holds up.
https://www.howtogeek.com/335712/update-why-you-shouldnt-use...
Re: Why Did ArchLinux Embrace Systemd? (2016)
#130I wish this kind of opinion would've been spread more widely within the Arch universe (wiki / IRC) so outsiders can understand what we actually gained from switching to systemd. It still feels like many people hate systemd but the reasons that are presented all sound totally valid from a programmers' perspective.
These reasons are valid; I think the main reason so many people hate systemd is how all-encompasing it has become. Prior to systemd, the lack of a standard init/rc/service monitoring system meant that you could pick and choose 3 different solutions for those 3 problems. systemd is pushing for unifying not just those 3, but other systems too (gummiboot, consolekit, udev). As more software becomes designed to work just…