Devuan “ASCII” 2.0 Release Candidate is now available

Post by vbernat » Thu, May 10, 2018, 5:30 PM UTC

hedora wrote: post #59

tialaramex wrote: post #45

Earlier quoted context omitted.

It's your basic grand conspiracy theory setup. You see a bunch of sensible features that don't add up to any particular larger plan, they see a sprawling plot by innumerable enemies to destroy a status quo that never actually existed outside their imagination. It is amusing to me that they call themselves "Veteran Unix Administrators" because an operating system needs _software engineers_ or at the very least _hacker…

Back in the old days, insmod and modprobe were synchronous. If you wanted concurrency during boot, you could use fork/join to get it (using the & line suffix and “join” command in bash, for instance). In the brave new world, all kernel events are published over some wonky bus thing, so you need to write a daemon that listens for hardware events and replicates the kernel’s current state of the world in dram, and also…

Post by jhkaghjkga » Thu, May 10, 2018, 6:40 PM UTC

sverige wrote: post #63

irl_ wrote: post #41

Earlier quoted context omitted.

Debian doesn't actually have anything against sysvinit or OpenRC. Those are just not the defaults. Both sysvinit and OpenRC are available in Debian. It probably would be easier to have a non-systemd system were the Devuan developers to upstream their packaging and patches to Debian. As Devuan has a stated goal of not using systemd though, I would guess they take the easy route of not maintaining systemd compatibility…

From 2014-06-11 systemd news: > * The support for SysV and LSB init scripts has been removed from the systemd daemon itself. Instead, it is now implemented as a generator that creates native systemd units from these scripts when needed. This enables us to remove a substantial amount of legacy code from PID 1, following the fact that many distributions only ship a very small number of LSB/SysV init scripts nowadays. A…

Post by JdeBP » Thu, May 10, 2018, 8:24 PM UTC

jhkaghjkga wrote: post #47

tialaramex wrote: post #45

Earlier quoted context omitted.

It's your basic grand conspiracy theory setup. You see a bunch of sensible features that don't add up to any particular larger plan, they see a sprawling plot by innumerable enemies to destroy a status quo that never actually existed outside their imagination. It is amusing to me that they call themselves "Veteran Unix Administrators" because an operating system needs _software engineers_ or at the very least _hacker…

The main driver behind the initial fork isn't even a sysadmin, but an art student who initiated Devuan as part of an art project and his PhD thesis: https://pearl.plymouth.ac.uk/handle/10026.1/11101 As a fun fact the thesis is released under a Creative Commons license, but states "no quotation from the thesis and no information derived from it may be published without the author's prior consent". Forbidding quotation…

Post by JdeBP » Thu, May 10, 2018, 8:52 PM UTC

tannhaeuser wrote: post #24

craftyguy wrote: post #10

Earlier quoted context omitted.

see newnewpdro's comment. I just built a headless armv7h system (using Arch Linux ARM) with 1GB of RAM, and after being up for 3 days running nginx, ssh, and some other bare services, the total RAM usage, for all applications, is 70-100MB. Systemd is complex, but it really doesn't seem to add a lot of resource drain for the power it give you... I'm happy with that tradeoff.

Out of curiosity, to start nginx and sshd you need like 2 lines of shell code in a BSDish rc.conf - one for starting each service. Why do you think systemd bringing in 10s and 100s of megabytes of black magic binary code is a trade-off worth making, especially on a non-desktop without a need for reacting on up/down events of network interfaces?

    % wc -l /usr/local/etc/rc.d/nginx /etc/rc.d/sshd
         136 /usr/local/etc/rc.d/nginx
          87 /etc/rc.d/sshd
         223 total
    % 

    % wc -l /etc/rc.subr 
        2090 /etc/rc.subr
    % 

Post by JdeBP » Thu, May 10, 2018, 9:00 PM UTC

dozzie wrote: post #35

pmden wrote: post #32

Earlier quoted context omitted.

Systemd isn't one component, so you'd be mistaken assuming everything in the systemd project is necessary to start a service. But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. As for why someone would make that 'trade-off' - I much prefer being able to add "Restart=on-failure" than using daemontools, and I…

> I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. My guess: because the "another application" that parses nginx_enable=YES is a (rc) shell script instead of an ELF blob, so you can track its execution.