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

[oiaohm]

Debian got maintainers for SysV (who went Devuan), until they decided to go systemd.

You can't expect users to deal with bugs and do the bug reports for free.
Most of them don't have time or know how to do that (BTS is nothing close to a website) and they're going Linux because MacOS and Windows aren't an option.

Explain to ,me why consolekit was out of date in debian even before debian changed to systemd. So you have just made a bogus claim. The reality is Debian did not have the maintainers to keep sysvinit support going. Yes some people have turned up in Devuan after debian went systemd. Still no one has submitted any of the required updates to Debian to reopen the debate. This is just the facts of the mater.

There are many fragments of required to make a complete system using sysvinit that have been critically out of date or not maintained.

I like how Devuan claim to be maintainers who broke away from Debian yet you find that they were not doing any maintenance on the core packages that sysvinit solutions need that were missing maintainers. Packages missing maintainers are public record on Debian.

[oiaohm]

Hey oiaohm: may I suggest that you tone down your sophistry

Funny you only just did the same thing. We all do know sysvinit is flawed. The Unix haters book documented over 20 years ago. If don't know its flawed you need to catch up on the topic.

The story behind Linux init is very much different to what you were making out. sysvinit package most people don't direct think that its a direct historic link to sysv and sys III init system because people don't talk about it. Its in the wayback machine preserved sites with talk about were the code of that project came from.

Really lets person attack me to avoid that fact that the story is way deeper. The single init system starts early in the Linux world. Understanding the reasons why sysvinit came dominate before systemd is kind of key to understand what is required to try to have more than 1 working init system.

[oiaohm]

Knoppix, MX-Linux, Antix, etc

There's even a list on the internet: http://lmgtfy.com/?s=d&q=No+Systemd

Did you take a close look at that list I bet not.

Univention Corporate Server v4.2 (Sept 2017) GRUB menu offers choice of systemd or sysvinit

Interesting right. You are starting to see more on that list start switching across to either systemd or openrc. Being maintained Init systems.

Those wanting sysvinit are going to be out of luck in time.

What is going on here is the fact that the upstream projects are starting to stop maintaining premade sysvinit scripts that work with stock sysvinit. If upstream project do not support you init solution the maintenance load increases and the number packages/applications you provide to end users decrease.

[UpsetingFact]

1.

Maybe, just maye because -a dellusional- William Jon McCann was more focused on "learning what XFCE is" (tinkering with what would become Gnome 3 since 2007) istead of developing ConsoleKit (which make it dying since 2009) ?
(http://linux.subogero.com/open-source-hall-of-shame/)

So you're the one making a bogus claim. This has nothing to do with debian maintainers (who were still there), but Consolekit's one.

You don't know what you're talking about.

2.

Yeah like people are so stupid to not realize the "V" sysvinit meant something.

Yup, you're full of sucking-your-own-dick syndrom.

If one fucking system init don't works by design, either rollback or make a better one.
Gosh, there's too much people advocating mediocrity through Beta-To-Manufacture shit than stability.

3.

What if I told you, that they did good, by not forcing systemd and let people choose something that works ?
That means people won't have to deal systemd bugs and shit because they have more important work to do.

Also do learn that if something works well, there'll be not much maintenance to do.

And that OpenRC is by far better than systemd or even sysVinit. But the thing is, people are still forcing systemd than OpenRC.

[gerddie]

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.

There was actually a comment with some code that pointed out how the systemd time-daemon could be killed if it was flooded with bogus data, making the system boot, so yes, it seems to be possible.

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.

The bug was already closed for comments from non-team members when I found it, so I was not able to comment there. The only approach would be to open another bug that will immediately get closed as duplicate (and rightfully so). Actually, the only reason I came up with that bug here was to point out that a certain attitude can be found on both sides of the (anti-)systemd fence.

The policy requires notifying upstream before complaining else where.

Where is this written? I only know that if I find a bug in Debian I should report it there and not upstream, because it might be a problem in Debian only (unless, of course, it's one if the packages I maintain myself where I would know better). However, here the bug was already reported upstream, so reporting it also in Debian would be a duplicate.

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.

This is very commendable, but in a perfect world it shouldn't be needed

[TheBlackCat]

Knoppix, MX-Linux, Antix, etc

There's even a list on the internet: http://lmgtfy.com/?s=d&q=No+Systemd

Which distros "dumped" systemd, or even talked about doing so? You didn't mention distros not (yet) switching to systemd, you talked about distros that used systemd then stopped. That is what "dumping" means (again, the word you used).

[BeardedGNUFreak]

So until something better and not that systemd clusterfuck is out, better stay on SysV.

Yes. No one gives a crap out the clusterfuck that is systemd. It is destined for the garbage heap of software history.

The real problem is how some clown and his fanboys managed to hijack an entire operating system. That should never have happened and it should scare everyone that it did.

You want to replace a core component of the operating system with your pet project? Fine, go off for a few years with your own fork and when it is stable and a drop in replacement get back to us and we will consider it.

[arokh]

If the only thing that works is replaced by some unstable shit (technical lunatics you said ? don't make me laugh) without any other viable options:

It is forced, get over it.

What you're doing is exatly "Do as I say or die", period.

What's stopping you from using something else again? I don't get it.

[oiaohm]

There was actually a comment with some code that pointed out how the systemd time-daemon could be killed if it was flooded with bogus data, making the system boot, so yes, it seems to be possible.

https://github.com/systemd/systemd/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen++timesyncd+

Does not appear here.

Early timesyncd was targeted at limit usage of inside containers and vm so data hitting the service could be controlled. I do not exactly like how systemd prototypes. But it is what it is.

The bug was already closed for comments from non-team members when I found it, so I was not able to comment there. The only approach would be to open another bug that will immediately get closed as duplicate (and rightfully so). Actually, the only reason I came up with that bug here was to point out that a certain attitude can be found on both sides of the (anti-)systemd fence.

Now this is a could case that you should have opened another bug. I had to do that twice on one bug in systemd to get it on the list to be fixed.

Where is this written? I only know that if I find a bug in Debian I should report it there and not upstream, because it might be a problem in Debian only (unless, of course, it's one if the packages I maintain myself where I would know better). However, here the bug was already reported upstream, so reporting it also in Debian would be a duplicate.

There is policy covering dealing with upstream projects. Was there anything in the bug saying it was a issue for debian that the upstream had this issue. The bug policy of debian does not forbid associating upstream bugs with debian bugs in fact recommends it to that when the upstream patches there is a record of when debian tested and confirmed it was fixed in debian bug list.

https://www.debian.org/Bugs/Reporting

So if it was a fault found in debian systemd a bug should be open on debian for it. So the Debian maintainer is following the upstream bug and it if closed without being fixed obeying rules opens another one.

You just stated why is against the rules to talk about a bug that you have not filed upstream as a proper Debian Maintainer because that bug may not be real.

The reality here with bug reporting so every works requires duplication.

If you are not a maintainer by debian standard policy you are only meant to file against debian bug solution. Then the maintainer is meant to make sure that the bug is not something debian added to start with. The maintainer is also to make sure it is filed upstream with status open until fixed and upstream is informed that the issue effects debian. If it takes opening another bug to inform upstream that debian is wanting that fault fixed so be it.

This is very commendable, but in a perfect world it shouldn't be needed

The world is not perfect. You have to work inside the limitations of what you have. If this means having to it multi times that is the way it is.

Something else to be aware of gerddie I have see code with comments that say if you do X program will malfunction you write a test case that does X and find that it don't and it a case that the comment was written early on in development and never deleted. Unless you are really sure policy does forbid proper debian maintainers talking about it until its confirmed as an upstream problem and there are bugs open upstream to address it that have a debian maintainer as a message in the upstream bug tracking so they know its being watched.

You did not even follow the general reporting rules that required you to at least make sure a bug was open in debian bug list for it so maintainers of systemd in debian to watching the upstream bug and able to get up the ribs of the developers of systemd at times to fix it if they closed the bug without fixing or excessive time without being fixed was happening.

Basically I have nothing against complaining but if you claim to be a debain maintainer and you are not opening the bugs you should you need to be pulled into line. Like how many other bugs have you not opened on debian that upstream have closed without fixing because there was not a bug in debian to mark that it has to be tested to confirm fixed so still effecting debian.

Debian policies exist for very good reason.

This is some of the problem with systemd. Lot of people complain yet not enough people are opening bug reports in distributions to have bugs tracked in systemd if they are fixed or not. So when systemd closes a bug that is not fixed its reopened a new until they fix it. It comes simple for them to fix than put up with 20+ maintainers opening the same bug and having to deduplicate every time they close the master bug without fixing it. Of course this stunt only works with a maintained init system. But with maintained init systems this is like a jackhammer it gets there in the end..

I maintain some of my own solutions built from source. So I am a maintainer of this stuff so I do at time report straight to systemd. I know what it takes to get stuff fixed. If you are not following the policies this does not help particularly when dealing with systemd or consolekit before it. The requirement to report bugs multi times to particular upstream maintainers is not new.

gerddie basically you response admits now that you did not do what was required as a end user of debian by policy. So you are not a end user or debian maintainer doing the right things. So either you are a debian maintainer who need kick ass or you claimed to be a debian maintainer without being one. I can look up who are real debian maintainers.

This is dot i and crossing t. If it not done stuff does not get fixed in a timely fashion. Beside person might be complain about systemd and admit to doing this mistake but you have to ask how many other faults they have in other packaged everyone uses that they are not reporting properly.

[UpsetingFact]

Another bunch of fallacies, as usual...

@BeardedGNUFreak

You must be new to the internet to not know that such clusterfuck that's the major problem of systemd.
The "fanboys" are paid to do shit, there's nothing else to wank about it.

What if I told you, that people don't simply have time to do code something else because they're dealing with systemd's shit ?

@arokh

Don't like my posts ? Don't come here then.

Either grow up, or either go Apple with that childish mindset.