Debian Moves Closer To Voting On Proposals Over Init System Diversity

[archsway]

starshipeleven

Someone linked to the Minix-originated Linux project in the last post on this subject.

A usenet post and tarball on a ftp site? What about mailing list, bug tracker and git server.

Might be great, but it looks like a hobby project of a single guy.

Don't take me wrong, I wouldn't mind seeing a distro built around it and taking it for a spin, but eeeh as it is it does not inspire much confidence as-is.

I don't understand what is hard to do in a kernel. It's plain text files that are standardized and easy to parse for anything.

More niche stuff none really cares about. I don't even know if it still ships the BSD packages at all.

[waxhead]

Getting something like systemd onto the BSD:s would be incredibly great. There are a few applications that I maintain where I have just held off porting it to FreeBSD due to not wanting to have to deal with their init.

Bingo, I admit to not knowing the details, but at the same time I would think that a lot of systemd functionality could simply be ignored which would make the implementation easier. E.g. for most things slices (cgroups) that takes care of memory constraints and resource limits, i bet it could be mostly ignored and things would work just fine for most programs anyway.

[Antartica]

Take a look at https://embexus.com/2017/05/16/embed...ot-techniques/
Administrators running servers would tell how systemd made their life much easier with only the use of units. It turned out that major of issues related to systemd are mainly specific to distribution implementation, in this case Debian.

Note: This changes the topic slightly, from [one-duty] server usage, to general embedded systems. Hope you don't mind.

Thanks a lot for the link, the techniques shown there are very helpful (although some are specific to yocto/openembedded and not applicable for debian). One thing I don't "get" is why they are launching the init process after the application, as in my experience it is common to not need the init process and doing so makes the just launched app sluggish for some seconds. Launching the app instead of the init process is sufficient to make the embedded system "boot faster".

But the thing is that in the article they show the systemd solution and just afterwards they recommend to avoid that solution and use the launch the app before the init system method, becoming init-system-independent.

In my experience no-init (init is a script that launches the app) or inittab is the fastest, followed by systemd, and in last last place is rc.d script for systvinit. In fact, one of the advantages of sysvinit is that inittab comes "free" with it, and you have one of the fastest methods available for embedded systems.

IMHO they're selling the advantages of systemd wrongly. The real advantage of systemd is a more modern approach for dynamic systems (hot-plug of devices, services that start/stop, etc), but the launch speed is not a really strong point of it (although it is certainly better than sysvinit rc.d scripts, of course).

[anarki2]

If the result of this GR is that Debian stops support non-systemd inits, this will mean the immediate death of Devuan. No need to wait for two years then.

If Devuan's support for alternative init systems relied on Debian's support for alternative init systems, then I really don't understand the whole point of their project altogether.

It's like MATE's manifesto: "we exist because we hate GNOME 3". That pretty much sums up Devuan too. They were born out of hate and bitterness, and not much else. There's no real problem to solve. Their talent (if any) should be spent elsewhere.

[finalzone]

Ironically, I don't mind much systemd for desktop usage, but I really don't stand it for [one-duty] server usage. Mind you, I'm mostly on embedded with an aim to kept at minimum the running processes and a systemd distro is a lot harder to prun.

Take a look at https://embexus.com/2017/05/16/embed...ot-techniques/
Administrators running servers would tell how systemd made their life much easier with only the use of units. It turned out that major of issues related to systemd are mainly specific to distribution implementation, in this case Debian.

[F.Ultra]

I think Debian should only support systemd especially since we got projects such as Devuan. For me systemd solves more problems than it creates for both desktop and server use, and the biggest issue in my point of view is that the BSD world don't have a systemd equivalent and that is where the manpower should be spent instead of discussion whether to continue to support non-systemd use cases.

Getting something like systemd onto the BSD:s would be incredibly great. There are a few applications that I maintain where I have just held off porting it to FreeBSD due to not wanting to have to deal with their init.

[F.Ultra]

Looks like it's time for another rant.

Reminds me of a small anecdote. Some 2 or 3 years ago a guy walked in to one of the local pizzerias where I live while I was waiting for mine to be delivered. He spent 10+ minutes looking over the long long chart of the different pizzas (they have like 100+ variants) until he grew mad as hell, shouted his frustrations out loud and walked out the door again.

Also reminds me of Kitchen Nightmares and Hotel Hell where Gordon Ramsay very often reduces the original owners huge menus down to just a small list.

[Terrablit]

Looks like it's time for another rant.

I was locked down. It is widely accepted that consumers want choices and enjoy of choices.

Actually, the end-user benefit of choice is a common fallacy. Consumers always claim to want choice, true. But it's been shown that consumers are actually less satisfied as the number of choices grows. They get subconsciously hung up on the opportunity cost, wondering if their choice is the "best" choice. They always feel like they're missing out on something. And when none of the choices matches exactly what they think they want, they get even less satisfied because it feels like all of the options are bad. This is economics 101. But, given how far removed most FOSS and linux enthusiasts are from even the idea of economics and having to pay for a lifestyle, it's not surprising that you don't seem to understand.

This is easily seen in the amount of time people spend tweaking and trying out new things in their distro (or different distros). At the beginning, it's fun and new. Then it takes a lot of resources and it's not fun. Most people who have a hobby of tweaking or optimizing eventually pare it down to a very limited category of things. Like rebuilding one car, renovating a house, or one application workflow.

After a while, it's a chore to evaluate all the options, so people just go with whatever they're comfortable with or whatever seems the best fit at the time. Later on, they avoid re-engaging in consumer selection. This can also be seen in tech circles. Administrators will choose the applications they know how to work with, even if they're not the best, simply because they don't want to evaluate again. Everybody kvetching about change and talking about the Unix philosophy fall into this category. It's been demonstrably proven that the Unix philosophy isn't the best user experience at all. It's arguable that it might have been back in the 1970s. But certainly not anymore. It's just flexible enough to not be the worst experience, since you can still get things done by duct taping a blow torch to your chainsaw when all else fails.

Similarly, developers will choose the libraries and APIs they know rather than the best ones. And they don't constantly look for new options. Instead, they settle into complacency based on the productivity trade-off of an arbitrary point in time.

Linux is about choice

So, no, Linux is not about choice. Life is not about choice. And please everyone fuck off with that silly idea. The only choices I want to make are choices that influence my personal happiness. Choices should be restricted to things that matter. There shouldn't be an available choice unless there's sufficient ROI for the cognitive load generated by having to make a decision. Imagine a visual novel where every click is a choice. Even banal ones like whether you say the plot dialogue line or not. That'd be the worst game ever. You'd have no time to engage the story.

The idea that everyone needs to have different options for basic operating system plumbing is the dumbest idea that ever shat itself out. Operating system plumbing should be as invisible as possible. Nobody needs to see and interact with every inch of the pipes in the bathroom. You only care about the sink, shower, and toilet. And you certainly don't want to manually push the shit through every inch of the pipes.

That's a major goal behind most distros moving to systemd. It's tackling *all* the problems, and it's reducing even maintainer exposure to init internals. There's hiccups, yes. Just like there were with the previous "solution". But eventually almost no one's going to need to dick around with this bullshit that's plagued us for 3 decades and we'll all be a lot happier.

[tuxd3v]

Let the religion begin on init methodology. 30+ posts on dogma alone. Meanwhile most desktop Linux users don't really care.

I think that you still haven't understood, that this question is not about the desktop( were debian as a small representation ), but instead in the Server...

[RealNC]

Heh, SJWs are using their own weapons against themselves. "Diversity". How could you possibly vote against that?

I love it.