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

[Scias]

Backported retpoline GGC 4.9 compiled linux-libre 4.14.19 kernel and FGLRX on top and guess what? This is weird as it could be but "everything" works, i am sure BSD can't do this.

Wait... So you can't stand having systemd on your system despite it being fully opensource and integrating nice within Linux but the dreaded horrific proprietary fglrx clusterfuck is fine? Where's the logic here?

[grok]

Wait... So you can't stand having systemd on your system despite it being fully opensource and integrating nice within Linux but the dreaded horrific proprietary fglrx clusterfuck is fine? Where's the logic here?

Maybe it runs well on a radeon 2000/3000/4000/5000/6000?
And on debian stable (or ubuntu lts) you don't get to run version n+2 of everything where maybe the open source performance doesn't suck ass anymore.
For me I don't see a difference between systemd or upstart or sysv! I want pulseaudio though (or ossv4 without pulseaudio but firefox, even 52 wants pulseaudio).

I tried jessie, actually lmde 2 which is without systemd! but the last fglrx doesn't install despite xorg and kernel being supported.
The problem though is having a low end board I can't overclock (or know the frequencies of!). Really low end have lazy stupid low clocks e.g. RAM at 535MHz, which would be 100% stable at 800MHz. On a 64bit bus.
If I installed XP x64 this shit would fly, like 100 fps in old games at low res full detail and AA 2x.

[dungeon]

Wait... So you can't stand having systemd on your system despite it being fully opensource and integrating nice within Linux but the dreaded horrific proprietary fglrx clusterfuck is fine? Where's the logic here?

As i said "This is weird as it could be" as that was linux-libre kernel with removed/blocked firmwares so only FGLRX could run there

That was as i joke really, i tried to make scenario that no one is expected to use as a proof of concept that even "crazy" combos works on Linux - "backported retpoline patches to GCC 4.9 and all kernel mitigations working, on linux-libre and 2+ years dropped FGLRX" - that would theoretically never happen in reality, but i am here to show you that even unexpected could work fine Silence does not mean things does not work, most of the time it is an opposite.... so here I am to show you some dirt

And yes one more thing is weird, i do this on 32bit OS installation... basically something that is not expected that one will use it like that, works just fine

You might not like FGLRX because it is blob, but there is one feature i like the most (i am also sure that also most are like me) and that is - it works on any kernel version pretty much same way To not mention even work with 2.6 kernels up to the 4.16-rc1 and any other in between - practically with anything same way, so some potentional user is not required nor interrupted nor any else sado-maso-push to upgrade his kernel at all or to move anywhere else - it works everywhere same way, even with linux-libre It works even with no support claimed, did i mention how it is clusterfuck stable that it hurts, it moves nowhere and breaks nothing

Compare that with now (and not just now, i will soon start speaking in decades ) released Ryzen APUs and as usual unfinished opensource drivers which forces you to do this or that, to even roll something out of tree and to spend time on bugzilla, to figure out this or that... i think that pretty much hurts many potentional users all the time - there is so much truth in this that is so boring and does not need any kind of further discussion

Of course i also expect many many Phoronix articles about a process, there is a story how on Linux only developers are happy and these ignorant sado-maso pushers, and i think that is kind of truth proved by many numbers

And here comes the story about Poettering right in place, do i need to draw some pictures or to post some videos why some of these people feel that way - of course i can do that on your request as i am your servant for the lifetime

I understand both sides and i try to be kind to both (blob and oss) as they are all people no difference, only politic might differ and these who push something and these who don't won't to recieve something. But that is what it is, as not everything in opensource is good nor is opensource good just because source of some shit is open... as a result of that kind of ignorance we just keep getting plenty of derivatives only and pretty much nothing else

Where's the logic here?

There is no logic in pushovers nor are arguments needed, you throw some BS i'll give you more i expect your ignorance and here is mine - i just downgraded X on stock Debian 9 (64bit) and same FGLRX works:

~$: lsb_release -d
Description:    Debian GNU/Linux 9.3 (stretch)
~$: xdriinfo
Screen 0: fglrx

Instead to install blob firmwares i choosed to install entire blob, so what? Games on Steam are also blobs, so who cares.

[oiaohm]

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 like how people attempt to change this to sysvinit style. That is not the case. distrowatch.com has the data. When distrowatch says a distribution is using sysv it using the sysvinit pid 1.

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.

In fact Slackware is not a non sysvinit design. The PID 1 is sysvinit the script system has been altered to be BSD like. In fact the reason why you can enable selinux on Slackware is that you are using sysvinit pid1. Pid1 with selinux has to link against libselinux or will not be able to boot in full enforcing mode.

People thought they were seeing a lot of different init systems. Sysvinit had a lot of distribution unique modifications that make it look like there was more than 1.

I'm pretty sure I've only ever used versions of Ubuntu which have used Upstart (10.04, 12.04 & 14.04).

Ubuntu early sysvinit with selinux then upstart with apparmor then to systemd. Yes when Ubuntu switched away from sysvinit they lot for a while the means to use selinux.

upstart is a failed in design init system. Yes it one of the rare sysvinit like that go deployed.

I can't remember what init I used when I used Gentoo, but I guess it was probably OpenRC.

Openrc is older than systemd. Openrc was started to compete with upstart. This is 2006(upstart) 2007 openrc and systemd is only 2010. But before 2006 when you go to distribwatch you find 90% sysvinit.

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.

Mandriva/Mandrake init is like most of the non sysvinit init systems. Use by 1 or 2 distributions in Mandrake/Mandriva case only used by 1. Reality is minority of distribution have been rolling their own init system and these init system are close to one offs. Majority have been taking another party developed init system and attempting to make it work for them.

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)?

Distrowatch did a really good job of mapping what a lot of distribution through out history really contained. So sysvinit has been very ubiquitously used just due to distributions individually tweaking on top to attempt to work around it failures a lot of people using sysvinit thought they were using something sysvinit like.

Systemd has caused kind of a shock to system due to upstream in fact dealing with lots of the issues so distributions are not required to do as many of their own unique fixes so systemd systems look a lot more a like so its more clear that these distributions are sharing a init system. Why was not sysvinit dealing with the issues in the main project because the maintainer-ship of sysvinit has been non functional.

A lot of people don't care what the init system is. What we care is that its functional and properly maintained. I have not see devuan address the issue of the maintainership problem of the init systems they have picked up.

Also it not like debian and redhat were not sharing common alterations to the sysvinit stack and application have been built depending on these features as well.


There is very little new about what is going on with systemd it not was happening with sysvinit behind a murky mess of individual distribution patching.

This is where a lot of arguements against systemd hit failure. There should have been a lot of complaints in 2000 with selinux in PID1 with sysvinit but people back then were not paying attention are like majority today still don't care what the init system is as long as system works..

[jacob]

shut up, you will drive everyone toward FreeBSD

It's funny though how the FreeBSD folks are absolutely convinced of that. They used to believe that everyone would jump ship because they would prefer the BSD licence to the GPL. Then it was because FreeBSD got ZFS first, so users would leave Linux in droves and migrate to FreeBSD just so that they can use one filesystem. Then it was supposed to be because of the systemd rollout: they were certain that the fact that Linux was getting further and further from a "real Unix" would be a final turn-off for users and the moment of FreeBSD's inevitable and imminent triumph. It didn't exactly work out that way (just like Devuan didn't take the entire Debian community with it, as the founding VUAs expected), but now they have a new source of certainty: Wayland! Of course, in their minds, people won't tolerate using anything less broken than X11, yet alone a system initially designed to run more than just xterm and xload, so obviously Linux is dead, everyone is about to switch to FreeBSD, hooray!

[niner]

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.

Why do you think the systemd developers have anything but a user-centric view? Maybe because user-centric really means you-centric. But it doesn't. The developers cannot just take your needs into account but also have to think about future users. It's them who would suffer because of an unmaintainable code base full of workarounds. The developers sacrifice some short term convenience for long term sustainability. It is a reasonable trade off. Certainly not the only valid approach, but also not a bad one. We've seen what happens when you pile workaround on workaround far too often.

[gerddie]

Why do you think the systemd developers have anything but a user-centric view?

Because instead of fixing a problem they pointed fingers, and like someone pointed out in the comments, the problem is not that the kernel is sending bogus data (granted, this is a bug in itself), but that systemd locks up the system and makes it unusable instead of failing gracefully. Adding some code that ensures the latter should actually not be considered a workaround, but an essential part of the software, because otherwise it becomes a security thread: it could become the target for a DoS attack.

Maybe because user-centric really means you-centric.

Neither did I report that bug, nor did I comment in the bug report, it was obviously something more then a just-me problem, so no, my view is not so me-centric, especially since in this case I could just move to another init system.

The developers cannot just take your needs into account but also have to think about future users. It's them who would suffer because of an unmaintainable code base full of workarounds. The developers sacrifice some short term convenience for long term sustainability. It is a reasonable trade off. Certainly not the only valid approach, but also not a bad one. We've seen what happens when you pile workaround on workaround far too often.

As someone who maintains a bunch of Debian packages and also my own free software projects I know the difference between a bug that just causes inconvenience, that you just report upstream, or against another package, maybe with a patch, and a RC bug that should be fixed ASAP - and IMNSHO if one can lockup a system by sending some bogus data, then this is release critical.

[oiaohm]

Because instead of fixing a problem they pointed fingers, and like someone pointed out in the comments, the problem is not that the kernel is sending bogus data (granted, this is a bug in itself), but that systemd locks up the system and makes it unusable instead of failing gracefully. Adding some code that ensures the latter should actually not be considered a workaround, but an essential part of the software, because otherwise it becomes a security thread: it could become the target for a DoS attack.

Without the bug I cannot say if fail gracefully was even an option. Its really does depend what that invalid data is saying if crashing, lockup or doing some other action is perfectly valid.

Neither did I report that bug, nor did I comment in the bug report, it was obviously something more then a just-me problem, so no, my view is not so me-centric, especially since in this case I could just move to another init system.

I know at times on systemd bugs it takes submit 20 more comments to get them fixed upstream. So the fact you say you did not put a comment on this bug fairly much that action says you were happy with the defect now complain about it here where you comment is not going to the developer that will not get it fixed.

As someone who maintains a bunch of Debian packages and also my own free software projects I know the difference between a bug that just causes inconvenience, that you just report upstream, or against another package, maybe with a patch, and a RC bug that should be fixed ASAP - and IMNSHO if one can lockup a system by sending some bogus data, then this is release critical.

If you are a proper debian upstream maintainer I would recommend you go read debian policy on complain about bugs. Because what you have done right now is a breach of debian policy. The policy requires notifying upstream before complaining else where. So admit you had not put a comment on a bug you are talking about here is breach of debian policy. I would really recommend get your actions in order.

PS. If you look my name in in the issue list of systemd you will see where I have done 20 more comments before to get stuff fixed in it. So if issue is important sometimes to get it fixed requires being a on going annoyance.

[cybertraveler]

oiaohm:

that's an awful lot of words to confirm that I did indeed only use one distro in over 10 years which had a sysv init style init system (slackware). I actually forgot to mention i used Knoppix from time to time, which I found out recently has its own home-brew, simple, single-script init system. This is the video where I found it out:
Defying systemd - or how to do wrong things the right way [en] - Klaus Knopper - YouTube
He discusses the very practical reasons why systemd isn't suitable for his distro and shows how he removes it:

You seem to have complaint with me calling it a "sysv init style" init system. I don't trust you. You seem to have some kind of freaky thing going on where you attempt to bend reality using language, to fit your systemd-maximalism world view I'm not 100% certain on this, but everything I've read so far is telling me that no GNU/Linux distro is running the original SysV init code and all of the systems claiming to have Sys-V init are running 1 of a number of implementations of it. Just like none of us are running UNIX, but probably all of us are running a UNIX-like or UNIX-style OS (eg GNU/Linux, FreeBSD, OpenBSD, Mac OS X) and many of our UNIX-style operating systems are sharing bits of code or running forks.

This is you:


Keep it real.

[Guest]

Guest You might be the only one to consider the end-product not by what went into it.

Well, isn't that how progress works? Only the end result counts. A lot of thought and effort went into many things that we still ditched at some point, like "flat Earth" theory for example.