Devuan 1.0 Officially Released - Letting Debian Live Without Systemd

[oiaohm]

I am even worse anti-redhat/gnome person. Users do not need to know how redhat shitty software like networkmanager, pulseaudio, gnome3, systemd works or are designed. Systemd is problematic, all other shitty software you can change to better, but not systemd.

It is possible to change out systemd if it was not Devuan would not exist. Its possible to run normal debian using openrc if you are willing to go teeth pulling to-do it.

There has been a problem that pre-dated systemd. Before systemd every time you would swap to some other init system other than sysvinit you would find yourself on very under-worn path with gremlins waiting to get you. Systemd has in a large way taken the sysvinit place as the top init system and being in the weeds when using a init system that is not the common default init system is the same as it always was.

I do agree with the cannot change to better problem. Most init systems are worse designs for Linux kernel compatibility than what systemd is or in need of work due to incomplete stattus. Its a little hard to change to better when completing solutions are crap based around invalid design ideas or lack or man power to be completed properly.

POSIX standard was design for application portability not for designing quality init systems. For single source init system to be run everywhere and function properly is really go back to the drawing board and design a new OS abstraction layer for init systems.

Basically its about time people over init systems take off the rose colored glasses and notice that lack of ability to effectively change init systems has been with us since 1993 with Linux with BSD and Unix way older. Being stuck with the OS provide init system if you want everything to work right is a Unix thing.

Systemd merging a lot of the support packages into 1 project did not change that those project were under manned and only tested if they worked correctly with 1 if lucky 2 init systems.

Maybe we can get somewhere if we stop blaming systemd and start waking up it a systemic failures to support multi init systems that are no were near new. Its really no harder to write a new init system now than what it was before systemd. Do a init system properly is the hard bit.

Redhat power in some of these core parts come from the simple reason in a lot of cases Redhat are the only major parity funding the developers in the area. This is another systemic failure developers deserve to eat we cannot really blame them for being bias to those putting food on their table.

Really someone should write a list of systemic failures the Linux world is suffering from and start attempt to have things happen that address them.

[cj.wijtmans]

Shock horror systemd will work with mdev and with dbus and journald missing. Systemd is in fact modular. Embedded developers have proven that without question.

Monolithic claim against systemd has always been bogus. It is like calling sysvinit monolithic because all it tools work with each other. Systemd is just a bigger collection of tools.

Systemd is lacking runtime customisation options so then auto configures self in ways users don't always want.

Is journald/udev/dbus in fact integrated not exactly. Does systemd configure it self particular ways when it detects their presence yes.

Integrated says not removable and embedded developers proved the 3 your point to as removable. So another bogus claim. Systemd includes journald/udev/dbus in the same tree but they are not integrated to the point of not being split-able.

Interesting enough if you look at the changes in udev in eudev you find a few very interesting things. Most of the changes in eudev are nothing todo with systemd they are to do with glibc features. The few systemd dependant changes are removing usage of a systemd library. A library that does not require systemd to be PID1 and was done to reduce code duplication between many parts.

Again most of the yell is because systemd is modular not monolithic. With the interdependency between modules mean if you had cut out udev you would have libraries starting with the name systemd because they contain shared parts used in different programs in systemd collection same thing exists in gnu core utils and people don't go around calling that monolithic.

no config flag for any of them. secondly it is a great effort to get it all out of systemd. It was done and abandoned.

[oiaohm]

I installed runit from the Debian testing repo in my test partition with Debian testing Xfce. After reboot that partition booted to a black screen and I wiped it. After that i tested void Linux, it runs fine, but lacks a graphical software manager. Also they use networkmanager and it was too difficult install wicd.

https://wiki.debian.org/runit

When you read this you go o hell. Welcome to teeth pulling. No one has bothered submitting a default set of scripts for runit for debian. openrc at least includes some defaults.

Please note runit being in the broken state was true while debian was using sysvinit as well. So there has been a on going problem supporting multi init systems.

Debian discussed about what is the default desktop two years ago. The gnome camp argument was they have more human resources. Technically Xfce is far better, it is freely configurable, designed to use with a mouse, lighter, faster and ready. A well designed software does not need much maintenance. For me redhat is like the minority that is in power in Syria, redhat bombs you with a shitty software. My first Linux experience was with redhat in 1996, I installed it to a laptop and it was and still is cool that Linux has built in drivers and works out of the box. In 2000 I built a backup and web server for the company I was working using redhat.

Xfce is showing resource stress like with how far behind they are to enlightenment on Wayland implementation. Enlightenment has funding from embedded developers.

Like it or not there are a lot of areas that most distributions depend on that the only staff working in those areas is Redhat. Realy that does need to change.

[oiaohm]

no config flag for any of them. secondly it is a great effort to get it all out of systemd. It was done and abandoned.

Again most people who forked them out did not have the resources to maintain them. So then the work load returns to Redhat personal again. Complain about lack of config file options to turn these features on and off individually would having to delete binaries and other nasty things is a valid complaint against systemd.

So you say great effort the reality is it was unfunded effort that proved it was possible. Now who is going to put up the cash to fund the developers to take care of those parts. This is the question that need answering. So Redhat is getting de-facto control because they are they ones putting up the money.

Same thing happens with init systems where people are not putting up the money/resources to make them work.

[oiaohm]

Start menu of enlightenment is from hell 3000 bc, very deep tree design and many dialogs with 1-2 settings. After 20 years when wayland has same features that X, users do not see difference, except X programs runs slower and with more bugs with x-wayland wrapper.

Most of enlightenment embedded usage is not using the start menu and it shows. enlightenment now in wayland mode the difference between wayland mode and X11 is interesting. Performance difference between xwayland and straight X11 is less than 10 percent difference. But wayland app vs x11 app the native wayland is up to 15 percent faster. This can make a 25 percent speed difference between application running in xwayland and a ported to wayland version.

So this is not as black and white. A lot of people are looking at X11 app performance under wayland and fail to compare native wayland application speed vs x11 version of the same app. So X programs look slow on wayland for approx 50 percent because wayland applications are fast. The overhead of running xwayland is also reducing.

The performance shape of Wayland is known now.

[tuxd3v]

I always applaud diversity in technological choices within the free software community. But this anti-systemd movement seems motivated by the worst intentions. "The right to Init freedom," "respects diversity and freedom of choice." Get off your high horse, please. Devuan is not here to be a good operating system, but to make an argumentative point in a rather snide way. Even if I had real issues with systemd (I have a few) I would not use Devuan nor recommend it to any of my clients.

Believe it or not, but Devuan, is more performant than debian today..
And By the way, on Debian you need to consult code to check how it works, its easier to SysAdmins to check something on the fly, because you know shell scripting, is open code

[oiaohm]

Believe it or not, but Devuan, is more performant than debian today..

Really I would like to see the benchmarks. As I have not seen a performance benchmarks where debian loss to Devuan. The lack of containerisation in Devuan does effect your ability to bias correctly as well

And By the way, on Debian you need to consult code to check how it works, its easier to SysAdmins to check something on the fly, because you know shell scripting, is open code

That is a double sided sword. Shell script might be open to sysadmin to look at its also open of sysadmin to typo in as well. .service files where the template code is no there has some serous advantages in error reduction.

Its easy to forget that majority of a sysvint/openrc scripts is template code being duplicated over and over again increasing risk of human error.

[tuxd3v]

Really I would like to see the benchmarks. As I have not seen a performance benchmarks where debian loss to Devuan. The lack of containerisation in Devuan does effect your ability to bias correctly as well


That is a double sided sword. Shell script might be open to sysadmin to look at its also open of sysadmin to typo in as well. .service files where the template code is no there has some serous advantages in error reduction.

Its easy to forget that majority of a sysvint/openrc scripts is template code being duplicated over and over again increasing risk of human error.

But Still,
A editable language, would be preferred, if you make a typo, its your responsibility.
We are used to do changes on-the-fly.
Sometimes without machines to test the code..

I am doing that, with some great amount of oracle databases code, with lots of terabytes, for some years, and no problems...also with other products in same scale..
_BUT_, you do need to know what you are doing!
Because all Company business is at stake..and any change you do, you feel the pressure of a possible failure on your shoulders..

But Editable code, on the fly, trust me, is a way better solution.
I still have a dream to see a language like Lua, for a init system..
Open, fast, editable, double floating precision, and so on..

Compiled code is... impossible for us..
Believe me or not,
But I do know what I am talking about, I work with linux for some 20 plus years, for Several Countries in the world..

[oiaohm]

Compiled code is... impossible for us..
Believe me or not,
But I do know what I am talking about, I work with linux for some 20 plus years, for Several Countries in the world..

I have also worked with Linux for over 20 years.

I also know what I am talking about I also have over 20 years of experience. In my 20 years I have learnt not to through the baby out with the bath water like you are doing. Facebook and other are not using systemd heavily for no reason. cgroup/namespace setup in systemd is fairly straight forwards and makes bias between services easy.

A editable language, would be preferred, if you make a typo, its your responsibility.

Editable language is not always preferable. Heck if editable language was always prefer you would be using tccboot to build Linux kernel at boot and tcc runtine to build bash... The problem comes where should be binary and where should not be and this comes a double side sword problem or more. And I bet it not you who is pay the money when you your typo causes your firm to miss SLA requirements so has to pay customers at times millions of dollars in compensation.

The lack of flexibility to administrators by systemd is offset by lower error rate. Yes if you employer is seeing lower downtime issues using systemd due to less human error of course they are not going to support you using script based init. So it is a double sided sword like it or not.

Systemd .service files are not a bad idea but they are most likely not the ideal solution for everything.

Some of the work with openrc there were a few developers looking at adding systemd .service support to openrc. This would make a init system that has the best of both worlds.

Think of it this way you have a double sided sword 1 side is sharp and one is quite bunt. The sharp side is good for taking down people without heavy armour and the blunt side is good to use with heavy armour. Use the wrong side of sword things don't work well. This is what you see with openrc script based vs systemd.

.service files in systemd are good for basic services and setting up protections and biasing around those services. Don't mess around with complex scripting when you don't have to.
Script init system good for complex services to start but are many times the complexity you need for simple services so just increase error rates that hurt bottom line.

So this is a classic double side sword with blunt and sharp edge if you choose one side the sword is no longer good for all possible enemies. Yes choosing only template or only script has the same problem with services. Yes I do end up with scripts inside system.service files.

Depending the services, bias and uptime requirements systemd can be be best choice over script based init. Now a init that offers script based init features and systemd .service hard template could be a nice middle ground.

Really those who are saying script is then they always include

you do need to know what you are doing!

that is garbage. Why is it garbage.
Human error does not care how many years of experience you have or how well you are trained. It called human error because anyone who is human will do it at some point.

You control human error by reducing amount of work human need to-do.

The fact that script requires more lines to-do the same things systemd .service file does increases your human error rate. It about time you pull your head out the sand. Future init systems need to take in what systemd has done with .service files as these reduce human workload. Of course humans have the option to use script for more complex problems would not be a bad thing. But to control human error you need to provide a system so simple things are well reduced lines of typing.

Human work to make service function is something those designing historic init systems never considered instead went for flexibility. Flexibility+light as possible human work would be a good init system. Currently I don't know of any production init system that gives you both.

[tuxd3v]

In my 20 years I have learnt not to through the baby out with the bath water like you are doing.

Facebook and other are not using systemd heavily for no reason. cgroup/namespace setup in systemd is fairly straight forwards and makes bias between services easy.

I don't uderstood the baby bath thing...by that, you mean, the people doing the first steps in administration?
What Facebook does, at least is not my concern, I deal with serious business,with real money, not with 'personal perfil chat like companies'

The problem comes where should be binary and where should not be and this comes a double side sword problem or more. And I bet it not you who is pay the money when you your typo causes your firm to miss SLA requirements so has to pay customers at times millions of dollars in compensation.

Systemd .service files are not a bad idea but they are most likely not the ideal solution for everything.

Thanks god , I don't remember last time that happened..
Code, then analyze...confuse? Don't implement it!
Wait check again, step by step, calmly, then release it..only when you know for sure what will happen, at each step..

There are different types of Business.
The serious ones, like Banks Systems, Insurance companies, and so on, and the virtual ones like Facebooks, google, and so on..

The requirements for each of them are different..
The first one, require very talented, and above all, responsible people, but the second its not the same thing..the losses are not equal, when a failure comes..
So maybe in the second one, systemd is more adjusted to their business.

Systemd .services...or let call them SysVinit copy..
A lot of people talk about that, of Systemd Services like if it was an invention......systemd copies the exact same way from SysVinit ...

/etc/init.d/rcS on inittab
will go after all scripts in /etc/init.d

Were is the big thing you are talking about?

its the same process, but worst...in the core..its like magic, you don't have editable code to analyze..so its worst than SysVinit( because you can't look at the code on the fly..so they copied SysVinit...but done it in compiled code...puff )

The unique thing that I see in systemd is about the names space, a easier way to separate user processes from root processes or so..but they complicated it..

Some of the work with openrc there were a few developers looking at adding systemd .service support to openrc. This would make a init system that has the best of both worlds.

Think of it this way you have a double sided sword 1 side is sharp and one is quite bunt. The sharp side is good for taking down people without heavy armour and the blunt side is good to use with heavy armour. Use the wrong side of sword things don't work well. This is what you see with openrc script based vs systemd.

.service files in systemd are good for basic services and setting up protections and biasing around those services. Don't mess around with complex scripting when you don't have to.
Script init system good for complex services to start but are many times the complexity you need for simple services so just increase error rates that hurt bottom line.

So this is a classic double side sword with blunt and sharp edge if you choose one side the sword is no longer good for all possible enemies. Yes choosing only template or only script has the same problem with services. Yes I do end up with scripts inside system.service files.

Depending the services, bias and uptime requirements systemd can be be best choice over script based init. Now a init that offers script based init features and systemd .service hard template could be a nice middle ground.

Really those who are saying script is then they always include

that is garbage. Why is it garbage.
Human error does not care how many years of experience you have or how well you are trained. It called human error because anyone who is human will do it at some point.

You control human error by reducing amount of work human need to-do.

Systemd do the same as SysVinit in that regard, you have scripts that they call services, that do things..after all its the same
But you will have to create the scripts systemd services call...so in the end...the same capability, but worst..compiled code and a init system that pretends to be a Operating System..

Maybe it reduces a bit the human error..maybe..

The fact that script requires more lines to-do the same things systemd .service file does increases your human error rate. It about time you pull your head out the sand. Future init systems need to take in what systemd has done with .service files as these reduce human workload. Of course humans have the option to use script for more complex problems would not be a bad thing. But to control human error you need to provide a system so simple things are well reduced lines of typing.

Human work to make service function is something those designing historic init systems never considered instead went for flexibility. Flexibility+light as possible human work would be a good init system. Currently I don't know of any production init system that gives you both.

In systemd you need to create your scripts to run on a systemd service..no the systemd service file is simpler, but your script that will be executed its almost the same..
The amount of work needed in sysVinit to do the same is almost the same as in systemd, no gains on that regard.

I continue to say systemd makes to nexus, apart from parallelization of boot( that also could be done in other ways ), and centralization of several tasks...this centralization is for me the biggest feature..but I also agree that systemd is not the answer.

We need a init system open, and by that I mean editable,
With a language that is fast, low resources, double precision floating point,WORA( write once run everywhere )..
I agree on Centralization of some common tasks, and with a simple way to implement your deamons or whatever you want

But systemd is NOT the Saint-Grail that a lot of people says it is..

For me, it is a stone in middle of progress, that delayed what a init system should be.
If it was not for him, today we will be with joy on our faces because a better init have appeared..it delayed that progress..