Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devuan “ASCII” 2.0 Release Candidate is now available

dev1galaxy.org

Post reply on HN
Print view View original

31–40 of 74 posts

Re: Devuan “ASCII” 2.0 Release Candidate is now available

#31

Post by jhkaghjkga »

sanxiyn wrote: post #26
jdoss wrote: post #25

Earlier quoted context omitted.

What exact need?

A need to run Debian system without systemd.

That need is already fulfilled by Debian? Just install sysvinit. (edit:) Also consider that if Debian would stop supporting sysvinit, a distribution adding support for it again would be a real effort compared to just installing a different init system by default.

Some desktop environments might want systemd-logind+systemd-shim, but that's really not different from installing systemd-elogind in Devuan...

Re: Devuan “ASCII” 2.0 Release Candidate is now available

#32

Post by pmden »

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?

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 don't have the luxury of working with one single distribution and remember the faff involved with initscripts differing between CentOS and Debian.

My reasons aside, I'd think a more sensible question would be "why would you actively avoid using the init system that's shipping by default on what constitutes at least 90% of the Linux server market when you're using Linux?". I don't think eyes equate to quality and stability, but I do think Red Hat, and SUSE, and Canonical and Oracle selling server solutions using it will.

Re: Devuan “ASCII” 2.0 Release Candidate is now available

#33

Post by danpalmer »

hedora wrote: post #8

I’ve been running the beta on my desktop. In this release, they have also established sane defaults for a wider range of window managers and desktop environments. The rough edges I’ve hit can all be attributed to systemd brain damage (like the fact that the linux kernel no longer has a working, synchronous, “probe the network cards and create a logical interface for each one” primitive). My only beef with devuan is t…

(Obligatory, this is honestly not trolling, but...)

> For me, this, plus pre-systemd levels of stability and debuggability is a winning combination.

As a developer who uses a Mac every day, and has experience with Linux only at a distance, administrating servers a little, using Ansible, debugging the odd production failure...

I actually find it easier to debug a system using systemd. I'm not sure why this is. Some ideas I have are:

- It could be that I never learnt the old way?

- I find the config files easier to grok than the scripts, and I don't think I've ever had an issue with systemd itself, so never needed to go further down that path than the config files.

- I find it a bit more consistent between different parts of the system.

Re: Devuan “ASCII” 2.0 Release Candidate is now available

#34

Post by dozzie »

vbernat wrote: post #22
sverige wrote: post #18

Earlier quoted context omitted.

I have yet to hear the argument that convinces me sysvinit (or openrc or runit) was "no longer suitable." In need of updating and revision? Sure. So broken that a completely new init that swallowed up a bunch of other processes and services was the best answer? Hardly. Systemd was initially sold as providing faster boot times. Objections to its cancerous spread to other services beyond init were dismissed without pro…

> Systemd was initially sold as providing faster boot times. Systemd was not about speed. Speed is a side-effect of correctly handling ordering. See http://0pointer.de/blog/projects/the-biggest-myths .

Ah yes, systemd did promise the correct handling of start ordering (i.e. socket activation). Though this never happened in practice, you still need to manually specify dependencies in unit files, barring the very few daemons.

Re: Devuan “ASCII” 2.0 Release Candidate is now available

#35

Post by dozzie »

pmden wrote: post #32
tannhaeuser wrote: post #24

Earlier quoted context omitted.

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?

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.

Re: Devuan “ASCII” 2.0 Release Candidate is now available

#38

Post by alxlaz »

danpalmer wrote: post #33
hedora wrote: post #8

I’ve been running the beta on my desktop. In this release, they have also established sane defaults for a wider range of window managers and desktop environments. The rough edges I’ve hit can all be attributed to systemd brain damage (like the fact that the linux kernel no longer has a working, synchronous, “probe the network cards and create a logical interface for each one” primitive). My only beef with devuan is t…

(Obligatory, this is honestly not trolling, but...) > For me, this, plus pre-systemd levels of stability and debuggability is a winning combination. As a developer who uses a Mac every day, and has experience with Linux only at a distance, administrating servers a little, using Ansible, debugging the odd production failure... I actually find it easier to debug a system using systemd. I'm not sure why this is. Some id…

> I don't think I've ever had an issue with systemd itself

You've been very lucky :-).

My favourite gem, which I haven't been able to figure out by the time I'd finally decided I've had enough and ditched the damn thing, was not being able to reboot my computer if I had some filesystems mounted over the network. It irked me considerably, because I was running a rolling-release distro at the time and I rebooted fairly often.

(Edit: to be clear -- I'm sure there are tons of valid use cases that systemd serves much better than any other init system. I know a lot of very knowledgeable people who use it. My computers just don't seem to have those use cases :-) )

Re: Devuan “ASCII” 2.0 Release Candidate is now available

#40

Post by badsectoracula »

self_awareness wrote: post #28

Don't want to troll or anything, just a question from curiosity: don't you think that massive popularity of systemd is a result of a massive demand for software like systemd?

As i understand it, systemd provides some functionality that some people wanted, but not everyone was happy with how this functionality was implemented and/or provided (which included people who didn't need tht functionality in the first place) and others were annoyed by how it was pushed/promoted and became a dependency on some popular projects (e.g. Gnome) without a technical necessity for being so, feeling like it was forced on people who didn't wanted it but also making it harder to use other init systems (this is especially important since, as i already wrote, the provided functionality is desired by some people and could be provided in a better way by another init system).

(note that with functionality here i do not refer to specific APIs or interfaces, but higher level functionality like "i want to be able to do XXX when YYY happens")

Post reply on HN