3 ms·

> ...network interfaces that dont change names when you swap hardware... I assume you're talking about udev's "Predictable Network Interface Names". [0] That'

> ...network interfaces that dont change names when you swap hardware... I assume you're talking about udev's "Predictable Network Interface Names". [0] That's a feature of udev, and -IIRC- has been around since shortly after udev's repo got merged into systemd's repo, but quite a bit before it became obvious that the Systemd Cabal wasn't going to put much -if any- particular effort into making it easy for folks to use udev without systemd. While -due to inertia- I do use it on my systems, it doesn't provide value on systems that don't have more than one network interface of a given type. [1] > ...to making it damn easy to file crash bugs... I've been doing exactly this in KDE since... KDE 4.1? 4.2? So, this would be back in the ~2008->2009 time frame. I have fuzzy memories of a crash reporter in KDE 3, but -back then- I didn't build my systems with debugging info or frame pointers, so the backtraces were always useless and -thus- went unsubmitted. > ...to checking what services have failed... rc-status --crashed or rc-status --all --crashed does the same for me on my OpenRC systems. Every sysvrc replacement that's not a toy provides this functionality. > ...to a more secure graphical desktop... I'm very glad that the Wayland folks are making good progress with their work. > Deploying web-services on systemd is so much better... Can you be specific here? There are a whole host of service supervision systems out there of varying quality and feature sets. [0] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ http://www.freedesktop.org/wiki/Software/systemd/Predictable... [1] After all, you can name your single wired ethernet NIC eth0, your single WiFi NIC wlan0, and your single USB-connected cellular radio usb0. That's far easier and more predictable than reading the output of lspci to figure out the name of your NIC. (If you get the urge to point out the cases in which the NIC-physical-path-dependent naming scheme does help, please carefully re-read the 'graph to which this footnote was attached.)

sandGorgon 11y ago
>> Deploying web-services on systemd is so much better... >Can you be specific here? There are a whole host of service supervision systems out there of varying quality and feature sets. True - but that is a good question by itself right ? Why - when you already had sysv and upstart and everything. Supervisord seems to be very popular that is very, very similar to systemd in its working (same concept of unit files, declarative language,etc). If you like supervisord, then systemd is just a short hop away. OpenRC would do the same - but are you claiming that openrc is BETTER than systemd ? Because systemd is making that claim. What I'm failing to understand is how is systemd bad ? it is making my linux machine extremely stable and working with it (creating new unit files) is extremely intuitive. Where is it making everyone's life hard ? the old way of "service nginx restart" still works. "dmesg" still works...
- simoncion 11y ago
  > ...are you claiming that openrc is BETTER than systemd... If I were making that claim, I would have made it. OpenRC's sysvrc replacement is at least as good as systemd's sysvrc replacement. Moreover, I have much more faith in abilities and reasonableness of the OpenRC Cabal than I do those of the Systemd Cabal. > True - but that is a good question by itself right ? Why... I'll ask again. Can you get into specifics about why "[d]eploying web-services on systemd is so much better..."? All I'm getting from you is soundbites and equivocation. > ...[systemd] is making my linux machine extremely stable... In the ~20 years that I've been using Linux, I've never had instability introduced by an init or RC system. What init or RC-induced instability have you observed in your Linux systems? > Supervisord ... [has the] same concept of unit files, declarative language,etc ... Does this mean that that the meaning of the keywords and parameters in supervisord's config files is very close or identical to those in systemd? Or does it just mean that supervisord's configuration files are in .INI format, just like systemd's? If the latter, then who cares? 1) Superficial syntax similarities do not necessarily enhance understanding. In cases where similar keywords mean differing things in two different systems, they can (and often do) cause confusion and misunderstanding. 2) Startup files for services whose startup sequence is the most complex you can handle in a systemd unit file are equally terse and readable in both systemd and OpenRC. [0] If the startup requirements are more complex than this, systemd has to call out to a shell script(!) or other external program. OpenRC (and other sysvrc replacements) that use interpreted startup scripts can bake such functionality right in to the startup script. This means that -in these systems- you only need to ship and maintain one file, rather than two. ;) > Where is [systemd] making everyone's life hard... Systemd is worrisome for several reasons: 1) systemd's scope continues to creep. 2) The Systemd Cabal continues to assert that pretty much every part of systemd is optional. An honest look at the state of systemd and projects like Gnome puts the lie to that statement. 3) Systemd continues to assert that systemd is faster than anything out there. Real-world observation indicates that this means that they've never heard of -say- OpenRC. 4) The Systemd Cabal continues to assert that systemd is modular. They assert that anyone can read their documentation and reimplement any part of systemd. Many people have attempted to do this and found the documentation sorely lacking. 5) The Systemd Cabal aggressively refuses patches that fix breakage that they introduced by changing decades-old behavior for no better reason than "The behavior was legacy and thus broken.". [4] In short, the attitudes of the people in charge of the project are dreadfully worrisome. Having udrepper in charge of glibc was bad enough. Systemd's devs are substantially more bullheaded, and the project itself is angling to swallow almost all of Linux userspace. [0] See Nailer's representative systemd unit file at [1] and my conversion of it to an OpenRC startup script. [2] Also, notice the confusion that one has when one is not already familiar with the keywords contained in a systemd unit file. [3] [1] https://news.ycombinator.com/item?id=10355588 https://news.ycombinator.com/item?id=10355588 [2] https://news.ycombinator.com/item?id=10357010 https://news.ycombinator.com/item?id=10357010 [3] https://news.ycombinator.com/item?id=10356330 https://news.ycombinator.com/item?id=10356330 [4] Their attitude on such things has been summarized as "Fuck your usecase.".

sandGorgon 11y ago

>> Deploying web-services on systemd is so much better... >Can you be specific here? There are a whole host of service supervision systems out there of varying quality and feature sets. True - but that is a good question by itself right ? Why - when you already had sysv and upstart and everything. Supervisord seems to be very popular that is very, very similar to systemd in its working (same concept of unit files, declarative language,etc). If you like supervisord, then systemd is just a short hop away. OpenRC would do the same - but are you claiming that openrc is BETTER than systemd ? Because systemd is making that claim. What I'm failing to understand is how is systemd bad ? it is making my linux machine extremely stable and working with it (creating new unit files) is extremely intuitive. Where is it making everyone's life hard ? the old way of "service nginx restart" still works. "dmesg" still works...

simoncion 11y ago
> ...are you claiming that openrc is BETTER than systemd... If I were making that claim, I would have made it. OpenRC's sysvrc replacement is at least as good as systemd's sysvrc replacement. Moreover, I have much more faith in abilities and reasonableness of the OpenRC Cabal than I do those of the Systemd Cabal. > True - but that is a good question by itself right ? Why... I'll ask again. Can you get into specifics about why "[d]eploying web-services on systemd is so much better..."? All I'm getting from you is soundbites and equivocation. > ...[systemd] is making my linux machine extremely stable... In the ~20 years that I've been using Linux, I've never had instability introduced by an init or RC system. What init or RC-induced instability have you observed in your Linux systems? > Supervisord ... [has the] same concept of unit files, declarative language,etc ... Does this mean that that the meaning of the keywords and parameters in supervisord's config files is very close or identical to those in systemd? Or does it just mean that supervisord's configuration files are in .INI format, just like systemd's? If the latter, then who cares? 1) Superficial syntax similarities do not necessarily enhance understanding. In cases where similar keywords mean differing things in two different systems, they can (and often do) cause confusion and misunderstanding. 2) Startup files for services whose startup sequence is the most complex you can handle in a systemd unit file are equally terse and readable in both systemd and OpenRC. [0] If the startup requirements are more complex than this, systemd has to call out to a shell script(!) or other external program. OpenRC (and other sysvrc replacements) that use interpreted startup scripts can bake such functionality right in to the startup script. This means that -in these systems- you only need to ship and maintain one file, rather than two. ;) > Where is [systemd] making everyone's life hard... Systemd is worrisome for several reasons: 1) systemd's scope continues to creep. 2) The Systemd Cabal continues to assert that pretty much every part of systemd is optional. An honest look at the state of systemd and projects like Gnome puts the lie to that statement. 3) Systemd continues to assert that systemd is faster than anything out there. Real-world observation indicates that this means that they've never heard of -say- OpenRC. 4) The Systemd Cabal continues to assert that systemd is modular. They assert that anyone can read their documentation and reimplement any part of systemd. Many people have attempted to do this and found the documentation sorely lacking. 5) The Systemd Cabal aggressively refuses patches that fix breakage that they introduced by changing decades-old behavior for no better reason than "The behavior was legacy and thus broken.". [4] In short, the attitudes of the people in charge of the project are dreadfully worrisome. Having udrepper in charge of glibc was bad enough. Systemd's devs are substantially more bullheaded, and the project itself is angling to swallow almost all of Linux userspace. [0] See Nailer's representative systemd unit file at [1] and my conversion of it to an OpenRC startup script. [2] Also, notice the confusion that one has when one is not already familiar with the keywords contained in a systemd unit file. [3] [1] https://news.ycombinator.com/item?id=10355588 https://news.ycombinator.com/item?id=10355588 [2] https://news.ycombinator.com/item?id=10357010 https://news.ycombinator.com/item?id=10357010 [3] https://news.ycombinator.com/item?id=10356330 https://news.ycombinator.com/item?id=10356330 [4] Their attitude on such things has been summarized as "Fuck your usecase.".