Announcement

Collapse
No announcement yet.

Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • k1e0x
    replied
    Originally posted by Templar82 View Post

    I will use BSD before I use systemd
    I already did do that 6 years ago.. I love it. It works better.

    And to those that claim FreeBSD will eventually implement their own version of systemd. (Benno Rice) You need to understand that BSD does not have the same mindset as Linux. (RedHat/IBM's mindset really as Linux is just a kernel and that is what they care about.)

    BSD cares a lot more about the Unix philosophy because.. well.. it's Unix. If FreeBSD did get a new Init system, that is all it would be. Also.. OpenRC a strong competitor to systemd already runs and is used on FreeBSD in TrueOS and FreeNAS so it seems logical that if they move to a new init, it will be OpenRC and not like systemd.

    Use BSD, it's basically Linux that is easier to customize and has a lot of cool features Linux does not.

    Leave a comment:


  • cb88
    replied
    Originally posted by andyprough View Post

    If you want to use a Debian-based system with no systemd and with alsa instead of pulseaudio, I would recommend antiX. Only difference is in order to start Firefox with sound you need to invoke it with the apulse cli utility: $ apulse firefox

    Firefox ESR works with alsa without having to use apulse, as does Waterfox. Alternatively, you can do what I do and compile firefox with alsa support.
    I do this on Gentoo... but yeah, I may give MX Linux a try... I have downloaded antiX in the past... many moons ago.

    Leave a comment:


  • Templar82
    replied
    Originally posted by jacob View Post
    No-one seems to whine for "choice" between 10 system call ABIs,
    If we were forced to replace our current working ones with a fragile bloated one you would probably see that.

    Leave a comment:


  • jacob
    replied
    Originally posted by audir8 View Post

    This can be cgroup-utils, syslog, cron, etc.. in many cases the user/developer api for these services is same even with different implementations. The average user doesn't care about any of this, they care about what udev/networkmanager/pulseaudio/xrandr can do for them. Make that functionality consistent with decent fallbacks over rolling or monolithic upgrades and there would be less distro hopping and more Linux adoption in general. You can have a same-looking networkmanager almost anywhere and it works! More of that please.

    The user/dev experience with systemd is worse in some cases (wtf does masking a service need to exist?), and marginally better in others (logging). If you want to make an improvement, you can do it with better APIs all around. There is no need for a user or developer to use most of the functionality in the systemd repo if they just want to deploy a service. Interfacing with the Linux system in general is a much bigger problem, and cgroups is about the last place I would start. Do you know what would be the first? f*&^ing temperatures and cooling!
    I think a more fundamental problem is that the systems you mention (cron etc...) follow the "everything is a text file" concept which was perfectly fine... in the 1970s where computers were static, centralised, had a full time sysadmin and the concept of third-party user applications didn't exist. But today we need a clean break from that and move to an era where everything is an API instead. Cron for example has no API at all. With cron there is no way whatsoever the developer of an application (I'm specifically saying DEVELOPER, not the admin!) can say "I need this function to run every 6 hours" for example to update F/X rates and be sure that it's indeed going to happen as required. Note also the deliberate use of the word function as opposed to shell script. Plus the sacrosanct "choice" means that whatever clunky and inadequate ersatz the developer will implement to work around this stupid limitation, it may not (and probably will not) work anyway for totally arbitrary and unpredictable reasons.

    Put another way, Linux was born out of Unix which was a sysadmin's OS. It's imperative that it becomes a developer's OS instead.

    Leave a comment:


  • audir8
    replied
    Originally posted by jacob View Post

    ...Because the Linux community must learn the value of having ONE TRUE WAY of doing things if it ever wants to reach any noticeable relevance as a desktop OS.
    This can be cgroup-utils, syslog, cron, etc.. in many cases the user/developer api for these services is same even with different implementations. The average user doesn't care about any of this, they care about what udev/networkmanager/pulseaudio/xrandr can do for them. Make that functionality consistent with decent fallbacks over rolling or monolithic upgrades and there would be less distro hopping and more Linux adoption in general. You can have a same-looking networkmanager almost anywhere and it works! More of that please.

    The user/dev experience with systemd is worse in some cases (wtf does masking a service need to exist?), and marginally better in others (logging). If you want to make an improvement, you can do it with better APIs all around. There is no need for a user or developer to use most of the functionality in the systemd repo if they just want to deploy a service. Interfacing with the Linux system in general is a much bigger problem, and cgroups is about the last place I would start. Do you know what would be the first? f*&^ing temperatures and cooling!
    Last edited by audir8; 19 September 2019, 01:12 AM.

    Leave a comment:


  • spstarr
    replied
    Originally posted by andyprough View Post

    Again, Linux is not an OS. There are a huge number of projects using the Linux kernel for which systemd is not an option, and would make no sense whatsoever.
    Yep, Linux is the kernel only. We're not a BSD where the kernel and userspace are together the 'OS'. I sometimes wonder if that was a mistake when GNU/Linux was starting to be pulled together early on, if Linux had the core set of userspace libraries/utilities under one common project with the kernel.

    Though, even today, GNU libc can be compiled to match a subset of kernels to support new syscalls etc, its still not uniform though.

    Last edited by spstarr; 19 September 2019, 12:55 AM.

    Leave a comment:


  • andyprough
    replied
    Originally posted by jacob View Post

    For the most part systemd makes things work better, but as controversial as that opinion may be, I would say we would need (something like) systemd EVEN IF it was worse than the existing solutions. Why? Because the Linux community must learn the value of having ONE TRUE WAY of doing things if it ever wants to reach any noticeable relevance as a desktop OS.
    Again, Linux is not an OS. There are a huge number of projects using the Linux kernel for which systemd is not an option, and would make no sense whatsoever.

    Leave a comment:


  • andyprough
    replied
    Originally posted by jacob View Post
    Ok at the risk of feeding the trolls... what's with this fetish of what they call "init" systems? No-one seems to whine for "choice" between 10 incompatible and broken system call ABIs, why should the event, configuration and services manager be any different? Besides, Linux has IMHO a very pressing and urgent need for de-unixifcation and systemd is probably a very good place to start.
    Linux is not an OS, it's just a kernel. So, what you are describing that you want is available on some distros, not on others. There is nothing unifying about systemd, other than that it makes it that much easier to distro hop from one systemd distro to another. It certainly does nothing to unify all GNU/Linux distros into one common experience.

    Leave a comment:


  • andyprough
    replied
    Originally posted by cb88 View Post

    Unfortunately the problem is... systemd has a goal of making itself a hard dependency all over the place to drive out alternatives through brute force. Same as pulseaudio... it's super annoying to setup a non pulseaudio desktop for no valid reason. However puseaudio worms it's way into software and then later native audio support is dropped for example with Firefox.

    If systemd was a launchd alike... hey that'd be great and we could use that but it isn't it's a monster be all and end all project that nobody should want.
    If you want to use a Debian-based system with no systemd and with alsa instead of pulseaudio, I would recommend antiX. Only difference is in order to start Firefox with sound you need to invoke it with the apulse cli utility: $ apulse firefox

    Firefox ESR works with alsa without having to use apulse, as does Waterfox. Alternatively, you can do what I do and compile firefox with alsa support.

    Leave a comment:


  • spstarr
    replied
    The thing is, all those whining about systemd need to understand, that the old sysvinit scripting just does *NOT* scale anymore. I need cloud-init, I need containers, I need this, I need to know if this specific SSD disk UUID is available, I need this... OpenRC might be the closest, but if it was going to be the better init system why did Debian not default to OpenRC instead? We know Fedora/RHEL was forced to use systemd given the alignment of Red Hat knowing about systemd and its goals.

    Nobody has yet given a reason why OpenRC should be used over systemd and, given some the complexities I've had that systemd solved, why having to write shell scripts to implement user privileges (sudo anyone?) makes any sense?

    Systemd's unit 'ini' formatting is ok, I can live with it, but what it *does* give me is a consistant front-end interface to any shell scripts/executables I need to run - while not having to manage user privileges in scripts themselves or having to probe udev or whatever to find out of a device exists. Or without me having write all those systemd units just to manage dependencies for finding resources.

    Systemd wraps those up so I can expect them to be there.

    I remember the horrors with sysvinit and having to manage hacky init scripts with initramfs, all the race conditions that, just that one time the init script hung the whole boot up... at least in systemd if there's going to be a hang its going to drop into an SOS state for me to look at why.

    I don't want to go back to those days, and until someone takes some of the good ideas with systemd and or marries them with OpenRC that hides all the low level detection/discovery/recovery of resources/events, I don't want to hear any complaining.
    Last edited by spstarr; 19 September 2019, 12:27 AM.

    Leave a comment:

Working...
X