Debian Moves Closer To Voting On Proposals Over Init System Diversity

[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.

[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).

[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.

[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.

[starshipeleven]

starshipeleven



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.

Ah ok I see what you did.

No you are posting bullshit. What was ok 20 years ago is not OK now as the world has changed since then. Every half-assed hobby project TODAY has a github or gitlab repo with issues and PR support or even a self-hosted minimal git server and a basic mailing list.
Failing to do so will mostly get the "eeeh I'll pass" reaction from most.

Also a kernel is not "plain text files that are standardized and easy to parse for anything." That's configuration files, a kernel is supposed to be a binary.

[NotMine999]

In my experience I find that systemd still has lots of room for improvement.

Just last night I was experimenting with the installation of various lightweight Linux distributions on an older mini PC that uses 4GB of RAM and an Intel D2550 CPU.

The intent is to load up to a simple windowed desktop state. My preference for lightweight desktop environments is LXDE & LxQt over XFCE based solely on my own past experiences. The ultimate use of these mini PC machines will be a fully automated (no human intervention necessary) display system that runs in a web browser interface.

The distributions that used systemd had the slowest boot times on this hardware compared to distributions that used sysvinit. systemd would take 60 to 70 seconds to load to a LXDE desktop login.

And I'm not vaping here. The boot time results for the systemd versions come straight from the "systemd-analyze blame" command and point straight to a systemd service loading & failing.

Every systemd-based distribution experienced issues loading a service "systemd-random-seed" or something worded like that it. That service never loaded; always showed "failed" when I typed the "systemctl" command by itself. That hanging service also caused the SSH service to "take forever" to load.

The sysvinit-based distributions would load to a LxQt desktop login prompt in 15 seconds. SSH was available by the time the login prompt was displayed.

So which style of init do you think I would choose for this older mini PC? I'll give you 2 guesses...

[NotMine999]

Looks like it's time for another rant.

Ahh..the Phoronix moment. When a Phoronix forum thread turns into a whining Slashdot rant.

[NotMine999]

No you are posting bullshit. What was ok 20 years ago is not OK now as the world has changed since then. Every half-assed hobby project TODAY has a github or gitlab repo with issues and PR support or even a self-hosted minimal git server and a basic mailing list.
Failing to do so will mostly get the "eeeh I'll pass" reaction from most.

Oh how quaint. The snobby "whatever is old I don't care about" attitude.

Over 25 years ago I worked with scientists from the labs of a telecommunications company on technology displays that utilized the WWW as it was back then. Skilled webpage authors knew and understood the ins & outs of WWW coding as it was back then. Webpages were written in whatever helpful and handy text editor that was available on the target platform. The typical servers in those days were using Sun hardware, so using vi or emacs to edit webpage code was not uncommon.

As George Santayana once said:“Those who cannot remember the past, are condemned to repeat it.”

https://www.goodreads.com/quotes/634544-those-who-cannot-remember-the-past-are-condemned-to-repeat

Also a kernel is not "plain text files that are standardized and easy to parse for anything." That's configuration files, a kernel is supposed to be a binary.

Ah ok I see what you did. So you would be in favor of a proprietary binary-only blob of kernel where you have no privilege to inspect the source code. Got it.

[starshipeleven]

The snobby "whatever is old I don't care about" attitude.

Wrong, it's about acting like you live in the same decade as everyone else.

This is 2019, if you want your project to actually be seen and adopted by potential users and form a decent community to receive contributions you have to do like we do in 2019.

I'm using fucking github (i.e. git VCS, bugtracker and contribution management) for a bunch of utility bash scripts and a rEFInd theme. It took me 10 minutes to do so.

This guy's idea of opensource software development in 2019 is posting a tarball of plain source that is NOT kept with a VCS on a static site that was written with a text editor?

And I'm supposed to trust this guy that is still clearly partying like it's 1999 to write a critical system component like an init system?

Over 25 years ago

was a very different world

Ah ok I see what you did.

Kernels are always executable binaries. CPU does not execute ascii text

So you would be in favor of a proprietary binary-only blob of kernel

No

[moilami]

Looks like it's time for another rant.



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.



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.

I don't buy that. It is the same kind of talk what was quite common in 15 years ago how technology is bad because people are depressed. Had the technology been removed and people moved back in time 500 years most of the people would had cried out loud their momma.

While phenomenons you described exist the conclusions of the reasons behind them are invalid. If choice would be removed and you were back to Ford Model A, with about 2 variations of each gadget, people would be hell annoyed about that there is no choice because one size does really not fit all. But the good thing would be that enormous economical boom would happen when people would start up companies to satisfy the demand of choice in markets.

Just because some try to buy happiness by consumerism, and are doomed to fail no matter what they buy, does not mean that the reason for their bad feelings is overwhelming choice, making even their attempts to buy happiness hard. They are the problem themselves, the choice is not the problem.

Life is about choices right away when you can make them. It is a sequence of choices.