Announcement

Collapse
No announcement yet.

Debian Developers Take To Voting Over Init System Diversity

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

  • intelfx
    replied
    Originally posted by tuxd3v View Post
    Like you see, having different opinions doesn't hurt.
    In case I was too vague, that was an invitation to share a proof of your claim.

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by intelfx View Post
    I'm not using either distribution. But I doubt the accuracy of your statement.
    Like you see, having different opinions doesn't hurt.
    Maybe diversity won't kill you too..
    You should experiment.. and maybe you will find out that what somebody told you here on phoronix after all..is true.

    Leave a comment:


  • intelfx
    replied
    Originally posted by tuxd3v View Post

    That should be why Debian, in a minimal install, takes lots of Ram compared with Devuan right?
    I'm not using either distribution. But I doubt the accuracy of your statement.

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by intelfx View Post
    So, no, there are no use-cases when "a simple init like init.d or supervisord" will suffice. In one case they are already several orders of magnitude too heavy, and in the other case they are not enough.
    That should be why Debian, in a minimal install, takes lots of Ram compared with Devuan right?

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by microcode View Post
    There is no good reason to impose the cost of maintaining non-systemd init scripts on every Debian package maintainer, to satisfy a group of people who appear to have few or no valid practical concerns.
    Can you please clarify that statement?

    Leave a comment:


  • intelfx
    replied
    Originally posted by phoronix_anon View Post

    Isn't it needlessly costly to increase the size of containers by many megabytes when a simple init like init.d or supervisord provide identical functionality with smaller attack surface and footprint? Every byte should be audited in a container especially during development when pushing and pulling remote repos.
    You appear to be talking in slogans and catch-words, which is not a terribly productive way to lead a discussion.

    Leaving aside nitpicks like neither init.d nor supervisord being actual inits, I will attempt to explain where you are wrong, again.

    Docker-style containers do not use any of the traditional init systems at all (not systemd, not upstart, not sysvinit, not openrc, not runit nor anything else from the list that's up for discussion in Debian today). Most of the time, the application process itself is PID 1. Otherwise (in a very minor share of cases), if the application in container is badly written and can't be bothered to reap its own children, a stub init process like tini may be involved — nobody is talking about these.

    LXC-style containers, on the other hand, are what you may call "thin VMs", complete with multiple processes running at once and everything else you expect from a GNU/Linux installation, requiring supervision, activation, logging and sometimes interactive control, so "a simple init like init.d or supervisord" won't be providing identical functionality. Anyways, the question of "which init to use in a full-fledged [Debian] GNU/Linux installation" has long been decided in favor of systemd.

    So, no, there are no use-cases when "a simple init like init.d or supervisord" will suffice. In one case they are already several orders of magnitude too heavy, and in the other case they are not enough.
    Last edited by intelfx; 12-07-2019, 02:08 AM.

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by 144Hz View Post
    Choice 1: F: Focus on systemd
    Bye Init Freedom!
    Next to that will be :
    Choice 1:F Focus in Chome Browser
    Bye Browsers Freedom

    Leave a comment:


  • phoronix_anon
    replied
    Originally posted by intelfx View Post

    Docker-style containers do not use an init system in the traditional sense.

    LXC-style containers are not different from a normal system.

    Therefore, yes: whenever an init system is used at all, it should be systemd.
    Isn't it needlessly costly to increase the size of containers by many megabytes when a simple init like init.d or supervisord provide identical functionality with smaller attack surface and footprint? Every byte should be audited in a container especially during development when pushing and pulling remote repos.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by monraaf
    removed post
    No that not the case. I am a old school hard core unix admin.

    Originally posted by monraaf
    Every old timers know that systemD does everything wrong on all possible way, it should've never been invented, it solves nothing. Linux is not windows98 that it require constant rebooting, you never reboot a linux box period, removed post
    Ok this nobrianer must never used Solaris OS with SMF at some point. Because you would know that the way systemd is doing things is SMF like not Windows like. Systemd does not doing everything wrong. Does everything kind of different to what us hard core unix admins were kind of use. Please note I said kind of different if you had SMF experience and a few other Unix OS experiences what systemd is doing is not that odd.

    So this paragraph proves you are not a hardcore unix admin because you got this wrong. With systemd you really should not be talking about windows if you are you really don't know the topic.

    Originally posted by monraaf
    roll back to the original sysVinit
    No its a no brainer that sysvinit need to die. To be truthful the sysvinit Linux is using is a person idea of clone of the sysv real init not designed to work with the Linux kernel. So sysvinit on Linux not designed to deal with the fact Linux kernel recycles PID numbers same thing exists in most of the init systems before openrc or systemd. . There are many CVE numbers linked to the fact Linux kernel recycles PID numbers this has lead to the development of pidfd. So sysvinit is a disaster zone and all other init systems on Linux that do service management that have not been designed to deal with the pid recycling.

    sysvinit the old one is no longer maintained. Its not picking up the new features like cgroups and pidfd. Freebsd has something like pidfd and its why freebsd service management is many times better than Linux with sysvinit.

    If you wanted to back something like sysvinit that long term stands a chance of working it would be openrc. Openrc has optional cgroup support and will have pidfd usage support so at least this option will work without having CVE numbers issued against it for creating security flaws.
    Last edited by tildearrow; 12-07-2019, 01:55 PM.

    Leave a comment:


  • intelfx
    replied
    Originally posted by phoronix_anon View Post

    Do you think systemd should be the only init available for containers? Do you want to see people stop using Debian-based images to build containers?
    Docker-style containers do not use an init system in the traditional sense.

    LXC-style containers are not different from a normal system.

    Therefore, yes: whenever an init system is used at all, it should be systemd.

    Leave a comment:

Working...
X