Devuan 2.0 Reaches Beta, Debian Without Systemd & Now Based On Stretch

[FireBurn]

The root problem is it's only a matter of time until sysv init scripts for packages stop being available if this direction is allowed by distro at all. Systemd unit files are far simpler and work more consistently so if it's a matter of choice, maintainers will only ship them

There's no reason that OpenRC could have support for unit files added

[FireBurn]

I thought the claim was that it was SysV-init style init systems that were popular before systemd? IE a number of init implementations that have very similar behaviour to the SysV init system. I don't think they were using the Sys-V init implementation itself.

I've been using various Linux distros for over a decade and in that time I've seen lots of different init systems being used. So many infact that I haven't noticed there being one popular init system. When I used Slackware, I think it had a non-SysV init design based around scripts. I'm pretty sure I've only ever used versions of Ubuntu which have used Upstart (10.04, 12.04 & 14.04). I can't remember what init I used when I used Gentoo, but I guess it was probably OpenRC. I used Mandrake Linux ages ago; maybe that used a Sys-V style init system? Maybe this Sys-V style init popularity you're referring to was a thing in the very early days. It doesn't seem to have been that popular during my years of GNU/Linux usage.

I have a question for you: are you hoping we get to a point where systemd is almost ubiquitously used on GNU/Linux systems (like the kernel itself and also GCC)?

I do hope for that, it's already the case for the distros I care about. Gentoo at home, RHEL7 at work (it's a pain when I have to do things on RHEL6) and sometimes Arch

[gerddie]

And in this case it was 100% a Linux kernel bug not a SystemD bug so it should be fixed in the kernel.

Exactly that is the attitude I was talking about. Of course it should be fixed in the kernel, but that is no reason not to add a workaround in systemd. It's called defensive programming, because you can not expect that a user has always the latest kernel running or that the RTC is at the reasonable time. systemd should simply not lockup the system only because the RTC is wrong or the kernel reports something wrong.

Fixing it in the kernel or SystemD wound't make much difference for users, both of them being updated regularly by distros.

What you forget here is that this bug report specifically mentioned arm based systems, and these usually run customized kernels that are often way behind the mainline kernel. Updating user space on such a system is normally quite easy, but getting kernel updates is difficult, so working around a kernel bug in systemd would help the users, and this is what earns you sympathy. What I asked myself when I read the comments on that bug report and also your comment: Why is it so difficult to take a user-centric view and simply do what's best for them - after all you want that you software is used.

[monraaf]

Not directly, but indirectly. Actually it is is more of a fork than it is derivative.

They are not even rebuilding 95% of the packages. How the fuck is that fork?

It is not latest, it started with this systemd Local Privilege Escalation

Problem is Mr. Poettering again as he think he is God sent to rewrite anything (now rsync) and that everbody will accept that But they don't like his ideas in the first place

You sound like some crazy conspiracy theorist. Anyone who isn't out of their mind reading this will just laugh at you.

[monraaf]

So it is matter of choice to only ship one so that we could all pretend how that is the best... that is real total BS

You are not contributing a single line of code yourself but you expect others to work on stuff for free that they aren't even using themselves.

Do you understand that free software doesn't mean that someone is going to work for you for free?

No one owes you anything. If developers decide to work on systemd stuff only, it's their right. There is no conspiracy involved and no one wants to force anything on anyone. It's simply a fact that the majority of users and developers simply don't give a flying fuck on anything else but systemd simply because it's the easiest to work with and develop for.

After all, it's just a piece of software. Just get over yourself, you sound like a twelve-year-old who's got nothing better to do than to complain about stuff they are getting for free.

[monraaf]

Maintainers can decide but should also follow guidelines, as we are all users. Otherwise they will lose users

Except that you are talking out of your arse and the majority of users don't give a flying fuck about systemd being default. On the contrary, the users that actually PAY for the software - i.e. the customers of RHEL and SLE - actually prefer systemd over the clusterfuck that sysvinit is. And, no, no one in their right mind isn't going to run anything but RHEL or SLE if they want to do serious business (the most commonly used business software from SAP isn't certified on anything but RHEL and SLE when it comes to Linux).

And if maintainer is ignorant, pretending that he has freedom to do do whatever he wants then people have exact same freedom to do forks or package things for themselfs the way they like or need - that is how things works

Do you realize that the huge majority of users aren't using any of these braindead non-systemd distributions and the people who are actually paying for Linux distributions are on RHEL and SLE?

You seriously have no fucking clue what you are talking about.

[amoKK]

I want Devuan without Devuan, that's fuckin freedom !!

[amoKK]

Devuan is a big fat ass

[starshipeleven]

There's no reason that OpenRC could have support for unit files added

It could but parsing text files with a shell script is going to degrade performance significantly (and also throw any semblance of security out of the window, because shell injection would be running rampant)

Now they could have a similar system by using shell-like syntax in their "unit files" like Procd does (the systemd-like init system of OpenWrt, where its "service" files are technically shell but most of the functionality is actually done by a binary init)

[MartinN]

I just hope that after "init freedom" they will do something about the equally pressing problem of "cp freedom". Once that is resolved, they should focus on linux itself: how does Linus dare forcing everyone use his kernel? The distro should have no less than 10 different incompatible kernels and you must be able to install them all at the same time or else.

Finally we should also focus on the absolutely unacceptable notion that the motherboard forces you to use one particular type of CPU and that that CPU forces you to run one specific type of binaries. I want to put an ARM Cortex A72 into my Intel motherboard and run SPARC code on it. Choice choice choice! Don't tell me that doesn't make sense, Devuan devs! You evil Poettering co-conspirators!

shut up, you will drive everyone toward FreeBSD