Devuan Progress Report Published

zdzichu writes: The group of anonymous Italians behind the recent Debian fork have published their first progress report. It covers a wide range of topics: the 4.5k€ of donations received so far, moving distro infrastructure from GitHub to GitLab, progress on LoginKit (which replaces systemd's logind), fraud accusations, logo discussions, and few more important points.

Comments

Nice progress!

[Anonymous Coward]

Totally beyond my previously (already good) expectations :)
They will have a future much more promising than those who are afraid of choice would say.

Re:Nice progress!

[Anonymous Coward]

Agree'd, we're probably looking 3+ months away from early beta releases, but they're well on their way, and seem to have a good idea of what their options are that stick to their ideals.

Re:Nice progress!

[Anonymous Coward]

Glad to see somebody incapable of writing logical arguments.
Please enjoy making fun of yourself :) ;) ;D :D

good job Dev Juan

[Anonymous Coward]

Do you package burritos?

Re:good job Dev Juan

[rvw]

Do you package burritos?

They code in spaghetti!

Re:good job Dev Juan

[marcello_dl]

Wait, but devuan is the fork, so systemd must be the spaghetti.

Doubts?
man journald.conf and appreciate systemd's implicit mandate for backup suffixes that won't fill your hd undetected as an exercise.

As for me, my init is sh: Still a better log story than systemd.

Re:good job Dev Juan

[TechyImmigrant]

and appreciate systemd's implicit mandate for backup suffixes that won't fill your hd undetected as an exercise.

So implicit that it wasn't explicit.

Their comments on trolls/trolling

[Barsteward]

Seems a bit rich as most of the vitriolic trolling was/still is the "anti-systemd" and "anti-LP" variety - what are they scared of now? I can't see anyone who is okay with systemd going to troll them, the only trolls they'll get will be the idiots who troll anything and everything because thats all they have to live for.

Its good to see there are some people out there that are willing to put their money where their mouth is. I wish them luck with their endeavors.

Re: Their comments on trolls/trolling

[Anonymous Coward]

They are worried that LP will somehow "force" them to switch to systemd, just like he has "forced" all other distros to do that.

Re: Their comments on trolls/trolling

[Anonymous Coward]

They do get a bit of trolling on the devuan IRC. There are some idiots on both sides of this debate.

On the other hand some devuan people find any information on systemd to be trolling, even when it is brought as a very dry technical explanation as to why something they are ripping out was done in the first place.

The working hypothesis over at #devuan is "it had systemd in its name, so it must be stupid". Since it is stupid it is save to remove the systemd code without even trying to understand what it does first. There is e.g. one person replacing logind, that was unaware that this piece of code is among other things allowing for the x server to run without root (in many setups).

OTOH logind is -- according to the #debianfork channel on IRC -- useless and it is better and more secure to run x.org as root than to have systemd running.

Re: Their comments on trolls/trolling

[Anonymous Coward]

OTOH logind is -- according to the #debianfork channel on IRC -- useless and it is better and more secure to run x.org as root than to have systemd running.

Which seems reasonable. Look how many recent security bugs are related to systemd vs x.org.
It's very prudent to defer systemd deployment until it gets mature (in case it has the possibility to get mature :).

Re: Their comments on trolls/trolling

[Anonymous Coward]

Well it has worked just fine for years. Don't fix what ain't broken.

Re:Their comments on trolls/trolling

[Anonymous Coward]

It's natural that you do not see the trolls from the systemd side, because you are one of those constantly trolling on systemd-related topics on /.
Happy trolling, dude ;)

Re: Their comments on trolls/trolling

[Anonymous Coward]

Yeah, the Pythagorean theorem is too outdated. We should just throw it away!

Re: Their comments on trolls/trolling

[Anonymous Coward]

It's fine if you want to build a shed, but not enough if you want to build a bridge.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Living in caves obviously works very badly. Moving from concrete houses to a half-constructed building with proved flaws is worse.
Same feeling when systemd constantly hangs during booting with network file systems.

Re: Their comments on trolls/trolling

[Anonymous Coward]

So you realise it's amusing to say Unix is outdated when the theory used to build bridges are mostly several hundred year old and still depend on instead of scrapping (can they? :) simple theorems like Pythagorean theorem?

Re:Their comments on trolls/trolling

[Anonymous Coward]

You are mistaken. Linux and trolling go hand in hand.

Re:Their comments on trolls/trolling

[Anonymous Coward]

You are mistaken. People and trolling go hand in hand.

FTFY

Re: Their comments on trolls/trolling

[t_hunger]

The absense of CVEs can mean the absense of people looking, and with the x11 being a quagmire of protocols, often contradicting each other as new stuff gets added over the decades, there are very few people that can even understand the code. One guy started to look last a while back and he is finding appalling bugs, check the recent CVEs and his presentation at last years chaos communication congress (30C3).

Making this swamp a bit dryer by not having it have root priviledgea is something that was work in progress ever since xfree started to run on Linux.

Now you come here and tell me that this sour spot for the last thirty years is better to keep around than having a much smaller, much cleaner codebase where almost all parts run in their own security context -- usually with privileges way lower than those you have as a user. Right.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Have you actually seen the calculations they make when they build a modern bridge? Just wind simulations alone will throw the Pythagorean theorem out the window.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Go fuck yourself, Lennart.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Have you actually seen the calculations they make when they build a modern bridge?

Whose theory might be even older than Unix. And still no mathematician dares to say mathematics no longer needs to depend on those old theorems :)

Re: Their comments on trolls/trolling

[Anonymous Coward]

The point, as you seem to have missed, concerns the difference between disregarding improvements and fixing what is broken.

So yes, by all means we should replace the Pythagorean theorem -- when you come up with a demonstrably better one.

Re: Their comments on trolls/trolling

[Spazmania]

Thing is, I've been using it to build sheds and I'd like to keep using it to build sheds. Don't insist I use bridge-building techniques to build a shed.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Moving from concrete houses to a half-constructed building with proved flaws is worse.

That analogy is probably more apt than you realise, given that concrete buildings don't last that long and are relatively difficult to maintain.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Glad that you finally realise something running well and continues to run well cannot be "just broken". And in case you need demonstrably better alternatives to systemd, there are already quite a few.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Which still doesn't save one "modern" building from a fundamentally flawed design and half-baked construction.

Re: Their comments on trolls/trolling

[Anonymous Coward]

The systemd codebase is much smaller and cleaner? You must be drunk, dude: 5.6M xorg-server-1.16.2.901.tar.bz2 3.7M systemd-218.tar.xz.
And I don't want to remind you of how terrible the codebase is, even when compared to xorg. (Well, I still reminded you of that. So be it.)
And in case you really need simplicity, why not watch this?

BTW, one flaw vs more than ten (with a few still unresolved) flaws? Now you come here and tell me that these sour spots for the coming years is better to keep around than having much smaller, much cleaner codebases where everything does what they are intended to do. Right.

Re: Their comments on trolls/trolling

[juanfgs]

but! but! muh unix way!

Re: Their comments on trolls/trolling

[Anonymous Coward]

None of those are alternatives to systemd. Why are you trying to pitch alternatives when you don't even know what systemd is?

Re: Their comments on trolls/trolling

[Anonymous Coward]

They are (much better) alternatives in the init sense, but not in the bloatware ("what systemd is?") sense.

Re:Their comments on trolls/trolling

[0100010001010011]

I wish they would had put their efforts into Debian's kFreeBSD. It can't move to systemd and they downgraded it from an 'official' Jessie release.

Personally it's a bit of the best of FreeBSD and the best of Debian (apt-get) in a nice package. There's no problem with ZFS being 'in' the kernel. The latest versions of FreeNAS and FreeBSD both have ZFS booting.

Plus it still has all the debian server admin tools.

Re:Their comments on trolls/trolling

[Anonymous Coward]

You are mistaken. People who use Linux and trolling go hand in hand.

FTFY

Re: Their comments on trolls/trolling

[Anonymous Coward]

Even you own numbers show that xorg-sever is way bigger than systemd. Not that compressed archive sizes are a meaningful metric, nor is the contents of the archives remotely comparable.

I was able to follow the systemd codebase rather easily, it is not to horrible in my opinion. I won't comment on xorg for lack of first hand experience.

Check http://www.x.org/wiki/Development/Security/ yourself: The last batch from Dec. alone was 12 CVEs. Compared to those the issues you listed in systemd are rather tame. And yes, there will be more issues discovered in systemd (as there will be more in x11).

But all that is completely besides the point: We have a way to run xorg non-root now, and you do not like that way. Please suggest an alternative then, that gets the same results but which is more robust. So far I hear "running xorg as root is secure" and the argument for that is "we always did it that way".

I am hoping the devuan people will come up with ideas to solve long-standing problems, but do far I have not seen much interest:-(

Re: Their comments on trolls/trolling

[Anonymous Coward]

Bridges are about arches.
Sheds are about triangles.
Right tool for the right job.
(Trellis bridges are simply many sheds)

Re: Their comments on trolls/trolling

[Anonymous Coward]

You tacitly admit you don't know what systemd entirely even is and call it bloated in the same sentence. Absolutley astounding.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Even you own numbers show that xorg-sever is way bigger than systemd. Not that compressed archive sizes are a meaningful metric, nor is the contents of the archives remotely comparable.

> du -hd0 *
> 41M xorg-server-1.16.2.901
> 40M systemd-218
Which is even more supportive of my point. It's not complelling argument, but at least it shows the systemd codebase is not "much smaller". And xorg is in maintaince mode while systemd is aggressively adding new modules.

I was able to follow the systemd codebase rather easily, it is not to horrible in my opinion. I won't comment on xorg for lack of first hand experience.

The participants in IOCCC can understand their own code doesn't mean other programmers can. The systemd codebase is still in comparison much worse than a lot of other projects' (eg. GNU coreutils and GNU grep, just to name two).

Check http://www.x.org/wiki/Development/Security/ yourself: The last batch from Dec. alone was 12 CVEs. Compared to those the issues you listed in systemd are rather tame. And yes, there will be more issues discovered in systemd (as there will be more in x11).

OK, I concede the "xorg is secure enough" point. But systemd suffers from the same problem, in a similar severity. Introducing bug-prone systemd to protect users from bug-prone xorg-server is almost certainly ridiculus - now you have two bug-prone programs in your machine.

But all that is completely besides the point: We have a way to run xorg non-root now, and you do not like that way. Please suggest an alternative then, that gets the same results but which is more robust. So far I hear "running xorg as root is secure" and the argument for that is "we always did it that way".

I am hoping the devuan people will come up with ideas to solve long-standing problems, but do far I have not seen much interest:-(

As said above, the implication of using systemd to mitigate flaw x11 is inapplicable; this can be solved in a really much simpler way. In case vdev's github page is not explicit about that, here's its project announce: https://www.freelists.org/post/modular-debian/Announcing-vdev

Re: Their comments on trolls/trolling

[Anonymous Coward]

You tacitly admit you don't know what systemd entirely even is and call it bloated in the same sentence. Absolutley astounding.

I know it is entirely bloatware. Or if it is not, so what is it? I would so much like to know ;)

Re: Their comments on trolls/trolling

[t_hunger]

What got vdev/udev to do with running xorg as non-root? Yes, that does initial setup of device nodes, but all the rest is handled by systemd-logind.

You are brandishing the wing stick:-)

Re: Their comments on trolls/trolling

[Anonymous Coward]

The rest is fully achievable using ConsoleKit2. You realize you don't understand it, which is good ;-)

Re: Their comments on trolls/trolling

[t_hunger]

It was not possible with consolekit, great that there was progress with consolekit2.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Binary sizes are even more meaningless than compressed archive sizes.

Systemd does e.g. quite a bit of static linking to minimize reliance on the linker.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Perhaps, but those are sizes of uncompressed source packages.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Wow, the person announcing vdev really understood session management. Allowing only xorg to access the device nodes is not even the problem... Session management is about making sure that the person in front of a computer is the only one that can actually use the web cam and microphone connected to that computer. That is to stop other possible users of that machine to listen in on conversations. The same is of course also true about the keyboard, mouse, graphics devices.

It would be so nice if people actually went through the trouble to understand the problems they are trying to solve. Study what the stuff you are trying to replace does before announcing new projects. Makes you look less like a fool.

Re:Their comments on trolls/trolling

[davydagger]

No one is scared of anyone, I am just sick of hearing bitching and complaining from the anti-poettering, and anti-systemd crowd about trolls. They are the trolls, and have gone as far as to issue poettering death threats. Once we fought back, like a typical reactionary bully, they cried of being oppressed. Fuck them

Its good to see a few of them are actually putting their money where their mouth is. The beauty of open source is that it gives the loudmouth enough rope to hang himself. He doesn't get to bitch that anything was forced on him, or he had no choices.

But you see how this ends, if they were any bit good a system design, or even system administrator, they wouldn't be bitching about systemd or poettering in the first place, because if they were any good, they'd understand there are other options, and installing something else isn't hard. If you're a decent sysadmin that is. But if they had the skills to run a diffrent init system, they wouldn't be bitching.

No one is forcing anything on these people, its simply the more technically competant people who work for distros are more technically competant. So, after years of bitching they finally did something, and do you know what is going to happen to Devuan? Nothing. Its going to fizzle because maintaining a distro isn't as hard as making death threats and bitching, and if they actually had the skill and dedication to learn something new, most likely they'd be systemd fanbois

Re: Their comments on trolls/trolling

[Eunuchswear]

Hooray! The anti-systemd paedophiles have turned up again! Now the gang's all here.

Re: Their comments on trolls/trolling

[Peter H.S.]

The rest is fully achievable using ConsoleKit2. You realize you don't understand it, which is good ;-)

Link please. AFAIK, it isn't possible to run Xorg as non-root in a safe manner using either CK or ConsoleKit2.

And BTW, the difficulty in running xorg as non-root in a safe manner is caused by the way the Linux kernel handles devices, not Xorg. That is why you need user session management from systemd-logind in order to secure that attached devices can't be abused to compromise security.

Re: Their comments on trolls/trolling

[Anonymous Coward]

i think loginkit promises to solve that without introducing speghetti code like systemd
loose coupled, easier to understand, easier to inspect, and easier to maintain

Re: Their comments on trolls/trolling

[Anonymous Coward]

the announce only said "to obviate the need for systemd-udev and parts of systemd-logind"
and the rest seems solvable using consolekit2, or loginkit if i misunderstand the former's scope

Re: Their comments on trolls/trolling

[Anonymous Coward]

Actually dimkr is not interested in what systemd does exactly and is concerned in adapting the logind interfaces to consolekit2. I talked to him and others on IRC: There is no interest whatsoever to find out why logind is different from consolekit.

Consolekit used to have sever problems that were fixed with logind, and consolekit2 inherited those. No idea whether those issues were fixed in consolekit2 recently. Unfortunately I am pretty sure nobody working on loginkit knows either:-(

Re: Their comments on trolls/trolling

[Anonymous Coward]

Aehm... nope.

Loginkit is only going to adapt the logind API over to consolekit2, so you can not expect more from loginkit than from consolekit2. The later inherited sever problems from consolekit. Those were thought to be unfixable, which is why consolekit was abandoned and logind was started.

Consolekit2 inherited those problems and so far I was not able to so any claim that they were fixed in the meantime.

Re:Their comments on trolls/trolling

[Anonymous Coward]

Just remember, folks! If someone forces you to something you don't like, YOU'RE THE TROLL!

Re: Their comments on trolls/trolling

[Hognoxious]

Forcing is probably too strong.

But you'd be surprised how much shit a charismatic person in the wrong place at the wrong time can cause.

Re: Their comments on trolls/trolling

[Anonymous Coward]

" anti-systemd paedophiles have turned up again!"

      As opposed to the systemd-rapists, I can't tell which is better.

Re: Their comments on trolls/trolling

[Anonymous Coward]

Are we talking SAC safe, or simply idiot safe?

Perfect is the enemy of good, as the saying goes...

Re: Their comments on trolls/trolling

[Barsteward]

Its up to you to define and explain your version of "bloatware", just throwing words around with nothing to back them up is pretty damning for your argument.

Re: Their comments on trolls/trolling

[Anonymous Coward]

the reason he does not entirely know what it is, is because it's bloated. learn to keep up here.

Re: Their comments on trolls/trolling

[Anonymous Coward]

LOL I think LP wrote the post above.

the systemd trolls keep saying our reasoning for not liking systemd is.. "we don't like systemd because we are stooopid and don't know to use it or switch to something else"

clueless systemd trolls. we don't like it because it's being forced onto distros without any real testing. and to top it off, it keeps growing bigger and bigger and adding more useless stuff thats already been solved.

Re: Their comments on trolls/trolling

[Anonymous Coward]

What is the saying again? If the attacker has physical access you are fucked anyways?

This seems to be the corner case above all corner cases for replacing everything down to the init with a eldritch horror of a project.

Re: Their comments on trolls/trolling

[Anonymous Coward]

The whole concept of seats seems like a demented (or paranoid) game of musical chairs.

trying to make hotpluggable devices seat aware via software seems like corner case heaven.

In essence it boils down to trying to turn what was from the outset a single user device (Personal Computer) into a multiuser device (desk top mainframe?).

SOAP vs Rest

[Tailhook]

This reminds me of the early days of "web services." The "enterprise" folks were jetting around writing gobs of XML and SOAP specifications, making speeches at conferences and whatnot. Meanwhile, some thoughtful people pointed out that the combination of existing HTTP verbs and the natural namespace provided by URLs satisfied the same use cases without the mountains of esoteric specifications and staggering protocol overhead. One memory I have from that time has persisted; some SOAP standards body muckity-muck was asked about REST during some function that happened around the time of the SOAP 1.0 specification release and he said (paraphrased); "Those REST folks aren't the kind of people the get things done!"

Today, SOAP gives people nausea almost universally and REST is the first choice of green-field work, with all sorts of API's proliferating everywhere. New languages and tools target REST first and SOAP eventually. Maybe. And if not then, meh, whatever.

Now we have the Debian fork. And what is said of the people behind it by those advocating systemd bloatware? Well they're just malcontents. They don't understand the problem systemd is trying to solve. They made a crummy web site and didn't even put their names on it. They'll never accomplish anything!

I have the feeling Poettering et. al are going to lose this one. If so then at least we can credit systemd with providing the motivation to progress, and reaffirming some of those cherished (if possibly mythical) UNIX principles.

(Incidentally, if anyone knows who was responsible for that statement about REST I mentioned please chime in .... I'm 99% sure it appeared on Slashdot.)

Re:SOAP vs Rest

[igloo-x]

Your little SOAP vs. REST story is only memorable because it almost never happens. Debian has a tendency to eat it's children and I've yet to read a single compelling technical reason on Slashdot why systemd is a bad idea. Most anti-systemd people heard about it then decided they hate it because of its feng-shui or whatever, then retroactively invent bullshit technical reasons for it which are either ignorance or lies.

Re:SOAP vs Rest

[DrXym]

I don't see many parallels. Working with systemd isn't exactly rocket science for admins or end users. Instead of typing one command to start or stop a service you type another. Systems even provide aliases or links to support the old notation, e.g. shutdown in FC21 is a link to systemctl which infers what to do from argv[0].

Tenuous comparison aside, probably the main reason SOAP dropped out of sight was it wasn't suitable for the eventual problem domain. SOAP was fine for computer to computer (B2B) communication where it's rather important to have schemas with validation, XML signatures, bindings like Axis that generate some nice stub classes for you and all that stuff. But it's a pain in the ass when you're a bit of JS in a browser trying to process some text you just got from a server and it's too much effort to produce schemas for the sake of some snippets of data. Of course JSON has taken off so much that suddenly having a schema for validation purposes is quite important again. I bet anyone who has used JSON in a server or wherever has had to handroll validators to ensure what they're getting is correct (e.g. that a field exists or contains a number etc.). There are drafts to produce a JSON schema spec and I expect in time tools will appear that spew out stubs and validators from a schema in a manner not wholly dissimilar from SOAP. So things will turn full circle in time. Doubtless someone will proclaim that JSON is too much effort at that point and suddenly we'll all supposed to be using YAML.

Re:SOAP vs Rest

[Anonymous Coward]

I've yet to read a single compelling technical reason on Slashdot why systemd is a bad idea.

Ignorance is fun? Makes people wonder how you yourself has the gut to say "ignorance" here.

Re:SOAP vs Rest

[igloo-x]

One post that begins systemd is basically a huge pile of modules compiled into the PID 1 init process (it isn't), another that states the existence of some bugs (gasp) and someone who had a problem dist-upgrading Debian.

If that's the best you've got, I'll rest easy on my position.

Re:SOAP vs Rest

[Anonymous Coward]

s/brave/reckless/
Your English needs some improvements

Re:SOAP vs Rest

[Anonymous Coward]

Yeah, you're right - we should continue to use sysvinit because Bash is perfectly secure

Yeah, glad to see the number of unresolved security flaws in systemd, which is about 5 years old, is more than resolved security flaws in bash, which is several times old than systemd. I'm looking forward to the first 0-day of systemd :)

Also, please provide evidence of boasting about security by the systemd developers.

Maybe this? Also, boasting about FFS in binary log suffices :D
I really wish you good luck trying to cover up all the holes in a sieve-like design, and still being proud about a "secure" product.

Your own link admits that the Linux kernel, upstart and "lots of the "good, old, reliable UNIX codebase" have exactly the same problem. This is no reason to reject systemd.

So you mean "does not look a lot better" is the same as "is as bad as" because they "have exactly the same problem"?
Your programming must have been taught by LP :)
Oh, and let alone systemd's codebase is not even tested by time, ...

That guy bitches about systemd making assumptions, files a bug report about it which itself assumes that Debian has to have a kernel package installed, which it doesn't. Lol.

Which does not seem to be a cure for systemd's "brave" assumptions.

Next.

Now it's your turn :)

Re:SOAP vs Rest

[igloo-x]

All non-trivial software has bugs. Given the scope of systemd, I'm surprised there aren't more. As pointed out in your own link, all software has sketchy code in places. This is not a valid reason not to use systemd. If there are any valid technical reasons why systemd is a bad idea, you clearly don't know them. My point still stands.

Re:SOAP vs Rest

[Anonymous Coward]

All non-trivial software has bugs. Given the scope of systemd, I'm surprised there aren't more.

Which is the problem. That's unnecessary - in some way like how xorg-server unnecessarily handles many details.
Those daemontools-like init approaches, the emergence of eudev, consolekit2, loginkit, ..., supports this.

As pointed out in your own link, all software has sketchy code in places. This is not a valid reason not to use systemd.

Which does not explain systemd's exceptionally bad design (or did they design at all?) and implementation. Maybe this is not complelling reason to abandon systemd if there are no alternatives, just like x11 before the inception of wayland. Fortunately, there are quite a few of excellently designed and implemented init systems, and a fraction of them are actively maintained.

Re:SOAP vs Rest

[igloo-x]

systemd is a suite of tools designed to provide a unified and integrated way to manage Linux systems. It is what it is because a bunch of people got talking about problems they were having with their Linux set-ups and decided that the best way to solve their problems was to re-implement a few system components under the umbrella of one project. This is so these components can interface with each other and do stuff that they couldn't do before.

"Oh but small sharp tools! Do one thing and do it well! It's the UNIX way!" Yes. The vast majority of what they're doing would have been possible if they'd just decided to develop and publish an API of some sort, and let the various authors of each component integrate it at their own various paces. But then you realise that you can publish standards till the cows come home, but it's no guarantee they'll ever be implemented, and you're left suffering with the same problems.

So at least give them credit for taking the bull by the horns and getting shit done.

Re:SOAP vs Rest

[Anonymous Coward]

> This is so these components can interface with each other and do stuff that they couldn't do before.
is there a single thing systemd does that can't be done by loose coupled code?

> The vast majority of what they're doing would have been possible if they'd just decided to develop and publish an API of some sort,
> and let the various authors of each component integrate it at their own various paces.
shell utilities do have well defined interfaces and they compose nicely, or there won't be unix; and they still compose nicely, or linux won't become what it is
and about standards, spaghetti code does not constitute well defined interfaces, or a simple patch would get the infamous journald easily disabled on bare systemd codebase, and logind would be forked in a breeze

> So at least give them credit for taking the bull by the horns and getting shit done.
they have earned their credits, but reality (code and bugs) shows their energy have been used poorly. one does not contradict the other

Re:SOAP vs Rest

[Anonymous Coward]

"A few"...

Re:SOAP vs Rest

[Hognoxious]

It is what it is because a bunch of people got talking about problems they were having with their Linux set-ups and decided that the best way to solve their problems was to re-implement a few system components under the umbrella of one project.

It may be the best way to solve their problems. But if I'm suffering from these problems, I haven't noticed yet. So I'll take the status quo over a half-assed solution that's been in existence for a shorter period than some people's uptimes, thanks all the same.

Re:SOAP vs Rest

[Barsteward]

"Which does not explain systemd's exceptionally bad design (or did they design at all?) and implementation."

that is just your opinion because you don't like it (which is a normal reaction to "i don't like it so i'll trash it") - so why not do an in-depth analysis on its "exceptionally bad design and implementation" and publish it so we can all see what you are talking about and check your points of reference and justification for your opinion. I'm sure if your analysis has any good points, they'll be stupid not to implement them.

Re: SOAP vs Rest

[Anonymous Coward]

just go look at the fuxking code. look at all the bugs that get marked as fixed because that's a feature not a bug and get closed :/

For a bunch of people who hate Debian

[Anonymous Coward]

They certainly have no qualms about reusing the debian logo as their official logo. Why the incorporate the design elements of logo of a organization you now bitterly hate? The other debian derivatives had no problem creating completely original branding.

Re:For a bunch of people who hate Debian

[Anonymous Coward]

Nice propaganda, except they do not hate Debian :)
What they might hate is the people flooding Debian that are afraid (look, I do not use "hate" :) of choices.
Devuan is embracing the original spirits of Debian, so no wonder it reuses elements from the Debian logo.

Re:For a bunch of people who hate Debian

[Anonymous Coward]

So embracing the original spirits of Debian community requires the community to rip off Debian's trademarks and use them in their derivative?

Re:For a bunch of people who hate Debian

[Anonymous Coward]

Nice logic, so similar to this.

make it easy!

[t_hunger]

Mid term devuan has just one chance: Make it easy for developers to provide solutions that work with multiple int systems. Systemd does bring quite a few improvements for developers. That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.

If devuan wants to keep a manageable distribution they need to make it similarly easy to tackle issues in a convenient and reliable way when using multiple init systems. If they manage that, then I am pretty sure developers will support their interfaces in favor of systemd. No developer wants needless ties.

Unfortunately it is much harder to provide generic solutions than it is to provide a specific one. So devuan is in a very challenging position to make things easier for developers.

Is they blow this, then they will have more and more software that depends on systemd-only interfaces and more and more work to remove those dependencies.

Re:make it easy!

[Anonymous Coward]

That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.

Which is very debatable, if not just laughable.

Re:make it easy!

[Anonymous Coward]

That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.

Which is very debatable, if not just laughable.

Systemd is Microsoft Event Viewer and data store for GNU/Linux. We do not want binary logs. If an operating system requires more than a text editor to view log files, there is a problem with the operating system and/or the log files. As an GNU/Linux since 1992 when SLS was "the distribution of choice" the current trend with the Debian GNU/Linux Project baffles my mind. What happened to the vision Deborah and Ian conceived so many year ago?

Re: make it easy!

[t_hunger]

That consultation mongering in that link is indeed laughable.

Re: make it easy!

[Anonymous Coward]

But still seems much more resonable than simply saying developers like it without giving any evidence.

Re:make it easy!

[Barsteward]

"We do not want binary logs." - not this boring load of shit again. You can have text logs if you configure systemd to use rsyslog

Re:make it easy!

[Anonymous Coward]

You can have text logs if you configure systemd to use rsyslog - not this boring load of shit again. We need to get rid of journald totally.
journald is as superfluous as it can be, and elegant alternative are easily implemented: http://linux.slashdot.org/comments.pl?sid=5841469&cid=48175739

Re: make it easy!

[t_hunger]

That person is bitching that everybody and their dog start to depends on systemd. That is your evidence right there.

Of course you have to do the dating assumption that devs do whatever they like... It kind of crumples if you assume that there are systemd hitmen traveling the world, forcing developers to depend on systemd.

Re: make it easy!

[Anonymous Coward]

So you realize you can't even give a logically sound refutation to the points in that post, and asserting the result is the evidence by itself? ;)

Re: make it easy!

[t_hunger]

There is no way to refute conspiration theorists. It is a self-contained believe system, that functions outside of the real world. I won't bother to argue with that.

Re: make it easy!

[Anonymous Coward]

Tip: "use so likes" theories have less credibility ;)

Re:make it easy!

[Barsteward]

its not superfluous, its more comprehensive than rsyslog, it starts logging earlier than rsyslog can, it logs after rsyslog has stopped. but if you don't want the binary log info, you can discard it. If that alternative was elegant, why wasn't it adopted across all distros?

Wait a minute...

[wonkey_monkey]

It covers a wide range of topics: the 4.5k€ of donations received so far, moving distro infrastructure from GitHub to GitLab, progress on LoginKit (which replaces systemd's logind), fraud accusations, logo discussions, and few more important points.

Was someone trying to sneak that one through in the middle of a dull-news sandwich?

Re:Wait a minute...

[Peter H.S.]

It covers a wide range of topics: the 4.5k€ of donations received so far, moving distro infrastructure from GitHub to GitLab, progress on LoginKit (which replaces systemd's logind), fraud accusations, logo discussions, and few more important points.

Was someone trying to sneak that one through in the middle of a dull-news sandwich?

The problem is that all money donated to Devuan doesn't go directly into Devuan, but into a rather dubious organization, with no public oversight and no accountability.
Here is a link to the org and their pre-Devuan Linux distro:
http://www.dynebolic.org/
Take a look around, and notice how a "donate" button never is far way from any project or web page.

The foundation has a chairman called Denis Roio, AKA "Jaromil", and according to themselves, the foundation "helps them pay taxes", in other words, they pay themselves from the org whatever they like.

There is a certain smell of "scam" around the Devuan project, not so much its contributors as a whole, but about the small group of shady figures centered around the "dyne org".

Re: Wait a minute...

[Anonymous Coward]

Yes

Re:Wait a minute...

[jaromil]

Thanks Peter! you are so kind! Hey wait a minute! the scammers are also on slashdot!! quick quick, close your wallet!

Re:Wait a minute...

[Peter H.S.]

Thanks Peter! you are so kind!

Hey wait a minute! the scammers are also on slashdot!!

quick quick, close your wallet!

Well, I am right ain't I. You funnel the donated Devuan money into dyne org, and as CEO/Chairman of that small org with self elected people, with no public oversight of the money, you also pull money out of dyne org into your own pocket to "pay for taxes". Dress it all up as a non-profit org too.

Make Devuan a proper org that directly receive the donated money you are begging for all the time, and have a proper elected committee with public oversight over the donated money and what they are spend on, and then maybe the smell of scam will evaporate.

Re:Wait a minute...

[marcello_dl]

If dyne is a foundation, I don't see why there must be another entity for Devuan, since the objectives are the same. It's like 300â down the drain yearly for mere bureaucracy. If a bunch of devuan devs got elected to "lead" the distro and dyne.org staff did not respect their decisions, dyne would be a hindrance, but I'd wait for this to happen and or provide some substance to your fraud accusation. AFAIK, a foundation would need accounting tricks or no funds appropriation can take place.

Re:Wait a minute...

[Anonymous Coward]

I don't mind buying them some sandwiches for $10 if we get a debian fork out of this.

Forked the Debian? or the Debian?

[ThePhilips]

The larger question is: what Devuan is really forking?

Do they fork a distro?

Or do they fork an organization?

With some work, one can fork a distro. But to fork the organization, one need to win over the people. I doubt that they will win over many (Debian) people without actually changing something in the forked organization.

Though many see the "systemd vs world" as the dividing force, in reality there is IMO problem with Debian organization. I have followed the debate for some time, and IMO, the problem is that there is too much democracy in the Debian. Public debate is a good thing. But too much of it simply prevents the organization from doing its work. That is IMO what has happened during the Debian's init system selection process.

Re:Forked the Debian? or the Debian?

[ruir]

The problem with Debian is that for whatever reason they ignored the power of linux, choice. At least in Debian 8, it is still trivial to make it use sysvinitrc instead of system. Why not let people choose, instead of forcing it upon new upgrades, and worse insult yet, make current systems upgrade to systemd by default?

Re:Forked the Debian? or the Debian?

[kthreadd]

Choice is not a matter of just pressing a button and have it magically appear. Someone has to actually maintain it. The Devuan developers think that they can do that. If so then that's great. It's sad that they don't think that they can do the same thing within Debian though I understand their reasoning. It takes a lot of time and effort to get into Debian and they want to be more pragmatic.

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

The Devuan developers don't think they can do it in Debian for two reasons:

One, most of them never contributed to Debian before, they only use it.

Two, they have a "burn it with fire" attitude instead of actually understanding how to support both systemd and sysvinit in the same distro.

Captcha: dispute

Re:Forked the Debian? or the Debian?

[Cley Faye]

The proposition to have multiple init system in Debian was promptly rejected with arguments ranging from infeasible to "who is going to make all these packages compatible with sysv init" (although they were compatible a few month ago).
I don't think doing it anyway in Debian was a good choice in that ambience.

Re:Forked the Debian? or the Debian?

[kthreadd]

"who is going to make all these packages compatible with sysv init"

Exactly. Did someone step up within Debian to do it?

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

Amusing attitude. "I can do whatever I want, others have to clean up after me".

Re:Forked the Debian? or the Debian?

[ThePhilips]

I do not know the answer for the Debian, but if you did RTFA, you would notice that it is precisely what the Devuan is doing: creating and packaging software which provide the interface of systemd services without the systemd itself.

The (retorical) question which I have already asked on difference occasions here is whether the Debian is a good place to do such development.

One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to maximize the reuse of the code from the other distros. This turned into a weird attitude when systemd vs. upstart was evaluated. The upstart devs and maintainers have committed themselves to implement whatever Debian needs. The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package". And that was later respun by a couple of CTTE members as "upstart still needs development while systemd doesn't".

That is also why I raise the question about changes to the Debian organization in Devuan: How could Devuan be more software developer friendlier? At the moment the barrier to entry is very high, leaving developers at mercy of the respective Debian packager. Or leaving the developer basically out if it has something to do with the low-level stuff like init system.

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

The Devuan developers don't think they can do it in Debian for two reasons:

One, most of them never contributed to Debian before, they only use it.

Which makes the false assumption that Debian is only contributed to by developers. Nice distro that does not need users!

Two, they have a "burn it with fire" attitude instead of actually understanding how to support both systemd and sysvinit in the same distro.

.. or instead because systemd is such crapware, does not play well with other software (eg. NFS mount), and has excellent alternatives?

Captcha: dispute

Keyword: propaganda.

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

systemd is [slashdot.org] such [slashdot.org] crapware [dieweltistgarnichtso.net],

Lol they really are the best you've got, aren't they?

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

So you are beginning to lol because you not even dare to refute them? Nice reaction ;)

Re:Forked the Debian? or the Debian?

[kthreadd]

I do not know the answer for the Debian, but if you did RTFA, you would notice that it is precisely what the Devuan is doing: creating and packaging software which provide the interface of systemd services without the systemd itself.

Yes, that's what they are doing.

The (retorical) question which I have already asked on difference occasions here is whether the Debian is a good place to do such development.

One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to maximize the reuse of the code from the other distros. This turned into a weird attitude when systemd vs. upstart was evaluated. The upstart devs and maintainers have committed themselves to implement whatever Debian needs. The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package". And that was later respun by a couple of CTTE members as "upstart still needs development while systemd doesn't".

That is also why I raise the question about changes to the Debian organization in Devuan: How could Devuan be more software developer friendlier? At the moment the barrier to entry is very high, leaving developers at mercy of the respective Debian packager. Or leaving the developer basically out if it has something to do with the low-level stuff like init system.

You're talking about Debian and Devuan like it's two monolithic organizations. It's not. It's people. And and if you want "Debian" to do something then real human Debian developers will have to do the job. It doesn't matter what any committee decides if no one is interested in actually doing the work.

The Devuan developers are obviously up for the task. That's great. They do what they want to do. It's just too bad that they for whatever reason couldn't do it in Debian. I don't blame them. It takes an arm and a leg to get into Debian nowdays, so if it's easier for them to create a fork then maybe that says something about the Debian project too.

Re:Forked the Debian? or the Debian?

[Peter H.S.]

The problem with Debian is that for whatever reason they ignored the power of linux, choice. At least in Debian 8, it is still trivial to make it use sysvinitrc instead of system. Why not let people choose, instead of forcing it upon new upgrades, and worse insult yet, make current systems upgrade to systemd by default?

Every choice has a cost and a consequences. In this case, supporting multiple init-systems dramatically increase the maintenance complexity. Every Debian Developer would need to run both a stable and unstable/testing version of both init systems, and some packages would have to be maintained in two different versions (talk about dependency hell).

But that isn't even the most problematic part; that is the fact that all non-systemd development have more or less collapsed the last couple of years; "ConsoleKit" bit-rotted for years, meaning DE developers couldn't justify developing against it, "SysVinit" is hopelessly understaffed (don't even have a build test) and haven't made a release for 5 years (RH/SUSE was the defacto maintainers), there is no development taking place on real alternatives to systemd's "udev" (the "eudev" is mainly a shadow fork by AFAIK, one person), "cgroups" development like "CGManager" will cease when systemd provides functionality to support LXC, and so on.

In short, there is a huge stack of development needed now and in the future in order to run a non-systemd Linux distro, and fewer and fewer developers to do the job.

When FreeBSD changes to a modern init-system (they will probably clone systemd), they won't support old legacy style init-scripts daemons permanently either. It is simply too much work with too little gain.

Re:Forked the Debian? or the Debian?

[Peter H.S.]

.... The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package".

That is simply wrong. Please notice that several long time systemd developers with commit access to the systemd git tree, are in fact Debian Developers. So there is a lot of "Debianism's" in where files placed etc.

Sure, the main branch of systemd wants to have as few distro specific patches as possible, but they do accept them if there is no other solution.

Here is a Debian specific patch that predates Debians adoption of systemd as default init-system:
http://cgit.freedesktop.org/sy...

Re:Forked the Debian? or the Debian?

[ThePhilips]

You're talking about Debian and Devuan like it's two monolithic organizations. It's not. It's people. And and if you want "Debian" to do something then real human Debian developers will have to do the job. It doesn't matter what any committee decides if no one is interested in actually doing the work.

Hu?

This very topic was laundered during the init system selection on the debian-ctte for very long time: it makes no sense to invest time into developing systemd if upstart is picked, and vice versa.

There might be people willing to do the work - but there is little more demotivational than a project declaring that they are taking a different path.

But the most demotivational is when people are told that they can't even have an alternative systemd implementation/fork - of which there are already couple - because GNOME demands the systemd, not just any systemd.

For motivation to spend your free time on something, this is as good as hitting a brick wall at full speed.

The Devuan developers are obviously up for the task. That's great. They do what they want to do. It's just too bad that they for whatever reason couldn't do it in Debian. I don't blame them. It takes an arm and a leg to get into Debian nowdays, so if it's easier for them to create a fork then maybe that says something about the Debian project too.

To me the most interesting part whether the whole fork would even take off.

Technical aspects of init system replacement are very easy - compared to the establishment of an organizational structure of the Debian.

Re:Forked the Debian? or the Debian?

[ThePhilips]

Sure, the main branch of systemd wants to have as few distro specific patches as possible, but they do accept them if there is no other solution.

I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.

Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.

If you are willing to grep through the 1K emails - you would definitely find that being repeated several time.

Here is a Debian specific patch that predates Debians adoption of systemd as default init-system: http://cgit.freedesktop.org/sy...

It's obviously not Debian specific.

It is very obviously a distro specific part of systemd: Debian was added to the list where Fedora and Arch were already present.

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

I have, but then my arguments aren't so weak that I need to repeat them again and again in the same discussion to try and "win".

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

Then I would be more than glad to see your analysis :)

Re:Forked the Debian? or the Debian?

[Peter H.S.]

I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.

Without source or citation. I think your representation of what was said is rather biased.

Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.

If it isn't a bug, why patch it? Sure, some people have tried to drop some turd patches into systemd, eg. ripping out security features in order to support some obscure glibc variant. The right thing of course is to patch the glibc variant to support the proper security functions, not patching systemd.

No package maintainer wants to support non-trivial, non-mainline patches without very good reasons. The whole point of open source software, that as many people as possible can share and enjoy improvements, so patches should go upstream as fast as possible. Maintaining non-trivial, non-upstream patches can also be a real problem when backporting security fixes, and may introduce patch specific bugs too.

If you are willing to grep through the 1K emails - you would definitely find that being repeated several time.

I have actually read most of them at the time, and I still think you are misrepresenting the systemd maintainers.

Here is a Debian specific patch that predates Debians adoption of systemd as default init-system:
http://cgit.freedesktop.org/sy...

It's obviously not Debian specific.

It is very obviously a distro specific part of systemd: Debian was added to the list where Fedora and Arch were already present.

Huh? The main point is that systemd mainline accepts Debian (and distro) specific patches if it is unavoidable. Despite the many claims to the contrary, the systemd developers do care about feedback and have many different distro developers with commit access. If you got a good user case, chances are good that a distro specific patch will be accepted. And having the patch going into the upstream repo is much better than carrying it as a separate distro patch.

In short, Debian developers where taking part in creating systemd long before Debian discussed making systemd the default init system. So they knew what they where doing when selecting systemd over Upstart (the CLA was enough to discount it), and the latest GR have confirmed that the vast majority of Debian developers firmly backs systemd as the default init-system.

Re:Forked the Debian? or the Debian?

[Damouze]

But the most demotivational is when people are told that they can't even have an alternative systemd implementation/fork - of which there are already couple - because GNOME demands the systemd, not just any systemd.

Anyone remember AARD?

Re:Forked the Debian? or the Debian?

[Eunuchswear]

The proposition to have multiple init system in Debian was promptly rejected

No it wasn't.

What was rejected was the proposition that packages that didn't support all init systems should be removed from Debian, violating the Debian constitution:

2.1.1 Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them.

Deboian does have multiple init systems, and if people want it to continue to have multiple init systems then it is up to those people to do the work, not to try to force other developpers to do the work for them.

Re:Forked the Debian? or the Debian?

[Eunuchswear]

GNOME demands the systemd, not just any systemd.

No. Gnome demands libpam-systemd or consolekit. libpam-systemd demands either systemd or systemd-shim.

So either work on consolekit/consolekit2 or work on systemd-shim.

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

Because SOCIAL JUSTICE.

Debian has been taken over by feminists and SJWs.

Debian rejects game due to authors opinion on women.

A properly licensed opensource casino video game was
recently posted to the debian bug tracker as a request
for packaging, as is the standard method for pursuing
such things in debian.

The bug was quickly closed, tagged as "won't fix"
The reason given by one of the debian developers
alluded to the authors past anti-feminist remarks:

https://bugs.debian.org/cgi-bi...

The piece of software in question is licensed
under the GPL and is one of the only of it's
kind for linux (ascii-art console slot machine software)

Is professing progressive politics now a hard requirement
for being allowed to contribute to free software projects?

Re: Forked the Debian? or the Debian?

[Anonymous Coward]

The 3 arguments you link to are each destroyed within 1 click on each respective page.

Re:Forked the Debian? or the Debian?

[ThePhilips]

If it isn't a bug, why patch it?

And this is a clear systemd bias (and GNOME attitude).

If systemd says it is not a bug, then it is not. And if something doesn't work - well, somebody opened a ticket about something NOT working - then something does NOT work. And if the systemd refused to fix it - who's going to?

The whole position of systemd implementors in Debian was and probably still is: we change how the whole system works, but we are totally not responsible if something breaks, because it is, duh, mainline systemd.

The whole problem of the hairy rcS scripts was ability to workaround pretty much any software or hardware problem on spot. Here, systemd insists that they are always in right - it is the rest of the world who are wrong. The problem is that a blank statement about wrongness of the world (it never was right to begin with) doesn't solve the immediate problem users are having.

I have actually read most of them at the time, and I still think you are misrepresenting the systemd maintainers.

Frankly I do not remember. It could have been one of the adjacent tickets about the systemd breaking the systems on autoupdate.

Tollef Fog Heen was pretty clear that he is not going to do anything special for Debian. (He is (or was at the time) a Fedora user already anyway.)

Huh?

If you can't tell what the hell the trivial commit does, then you are obviously not a software developer.

That was a great PR move on part of the systemd developers: to flood the mail lists with the buzz words. Users have no idea what they mean - but they sure sound cool - so systemd must be cool too.

Re:Forked the Debian? or the Debian?

[ThePhilips]

GNOME demands the systemd, not just any systemd.

No. Gnome demands libpam-systemd or consolekit. libpam-systemd demands either systemd or systemd-shim.

So either work on consolekit/consolekit2 or work on systemd-shim.

I was basically quoting Debian's GNOME maintainer, from the times of the Debian's CTTE debate.

At least at the time, Debian's GNOME package had a hardcoded dependency on the systemd package, not a feature/virtual package which provides the services. And GNOME DDs were refusing to change that, because they didn't like the systemd-shim.

Re:Forked the Debian? or the Debian?

[Eunuchswear]

At least at the time, Debian's GNOME package had a hardcoded dependency on the systemd package, not a feature/virtual package which provides the services. And GNOME DDs were refusing to change that, because they didn't like the systemd-shim.

Whether that was the case then it isn't now.

gdm3 depends on libpam-systemd.

libpam-systemd depends on systemd-sysv | systemd-shim.

There is exactly one package in current Jessie or Sid that depends on systemd -- gummiboot.

Re: Forked the Debian? or the Debian?

[Anonymous Coward]

Confusingly how you destroy the arguments with "clicks" instead of refuting them here :D
(Or you are Superman? But how can you, instead of LP, be Superman, if you are not LP himself? :)

Re:Forked the Debian? or the Debian?

[blind biker]

I had the impression your post had an agenda, and then I read, at the end, you confirmed it:

When FreeBSD changes to a modern init-system (they will probably clone systemd)

Re:Forked the Debian? or the Debian?

[Peter H.S.]

If it isn't a bug, why patch it?

And this is a clear systemd bias (and GNOME attitude).

If systemd says it is not a bug, then it is not. And if something doesn't work - well, somebody opened a ticket about something NOT working - then something does NOT work. And if the systemd refused to fix it - who's going to?

Not every bug filed is an actual bug, even though the submitter feels it is. Saying no to bad patches and closing non-bugs with a "not-a-bug" is the daily grind of developers and package maintainers.

The "Heartbleed" bug is a prime example on how bad things can go when you accept patches that circumvent security measures in order to support obscure user cases.

Really, systemd developers accept a huge amount of patches from hundreds of different non-systemd developers each year, suggesting that they won't accept patches is simply contrary to reality. I have yet to see a reasonable patch being rejected on the systemd-mailing list.

The whole position of systemd implementors in Debian was and probably still is: we change how the whole system works, but we are totally not responsible if something breaks, because it is, duh, mainline systemd.

I really don't see the Debian systemd maintainers that way at all. They seem to be hard working and serious to me. I have yet to see a example of them accepting breakage because mainline systemd. As I said, there are Debian developers with commit access to the systemd git tree, so they obviously have a lot of influence on systemd as a upstream project.

Tollef Fog Heen was pretty clear that he is not going to do anything special for Debian. (He is (or was at the time) a Fedora user already anyway.)

I have seen no examples or evidence of this. Really, what specific non-trivial patches could Debian need that couldn't go into mainline systemd? Can't think of any, nor have I ever seen it on the mailing list.

Huh?

If you can't tell what the hell the trivial commit does, then you are obviously not a software developer.

It is trivial, but it is Debian distro specific and in upstream systemd. There are a lot more examples in the git tree, and also of Debian influence in the general design of systemd. You assertion that systemd developers doesn't care or won't accommodate the Debian distro is therefore unfounded.

That systemd actually accepts trivial distro specific patches, shows that they are accommodating their users. Since it is trivial, it could have been carried by the distro maintainer.

That was a great PR move on part of the systemd developers: to flood the mail lists with the buzz words. Users have no idea what they mean - but they sure sound cool - so systemd must be cool too.

Really, trying to pass off systemd as a "fad" that Debian accepted because of "buzzwords" on a mailing list is outright pathetic; systemd is real improvement over SysVinit in every aspect, and the Debian CTTE choose it because of its technical merit. That the Debian developers agree with this, was demonstrated at the latest Debian GR.

Re:Forked the Debian? or the Debian?

[Peter H.S.]

I had the impression your post had an agenda, and then I read, at the end, you confirmed it:

When FreeBSD changes to a modern init-system (they will probably clone systemd)

Sure, my agenda is to show that supporting multiple init systems is very difficult.

That FreeBSD (and other BSD's) will change to a systemd-like init system is a given thing too. Even the founder of FreeBSD has publicly said it is in the future for FreeBSD.

The fact is that the way people uses computers have changed dramatically the last decade; virtualization, OS containers, instantiated services, mobile devices etc. SysVinit and similar legacy style script based init systems simply aren't up to working with all this.

So when FreebSD change their init system (and they will), they won't support a free choice between the new init system and old legacy script based init systems either.

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

That is as backwards at its finest. All the packages were sysv init compatible before the whole systemd switcheroo started.

All in all, it was the systemd proponents that should have started a fork. This to demonstrate that it would work, and if people wanted it they could move over. This would have been more in tune with how evolution works.

Instead we get a massive political fork...

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

"One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to maximize the reuse of the code from the other distros."

A weird attitude for a project that previously have forked such things as Firefox over a licensing issue.

This makes the whole init choice reek of bad politics, and makes Ian Jackson seem to have been in the right from the outset.

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

If only systemd was just a init...

Re:Forked the Debian? or the Debian?

[linuxrocks123]

Technical aspects of init system replacement are very easy - compared to the establishment of an organizational structure of the Debian.

Ha ha ha ha ha. The best way to kill the project would be to set up the "organizational structure of Debian". Once you remove from Debian the ftp-masters political intrigues, the bureaucratic red-tape "freeze" phases, the militant feminist lobbying group, and the unnecessary and technically incompetent divergences from upstream (see "Debian openssl"), there's not much "organizational structure" to Debian left.

Re:Forked the Debian? or the Debian?

[Barsteward]

who let you out of kindergarten?

Re: Forked the Debian? or the Debian?

[Anonymous Coward]

why did your mother give birth to you? we all agree she should have swallowed your dads load. your dad probably wishes he made her swallow as well.

Re:Forked the Debian? or the Debian?

[Anonymous Coward]

A bit-rot initiated by Poettering. Apparently Canonical was to take over maintenance, but under a new name and new repository. Except it seems to have never materialized, and the decision was never mentioned on the mailing list. A mailing list Poettering shut down claiming he didn't want any spam. All this while patches as recent as 2014 is sitting in the bug tracker, awaiting approval.

The recent Consolekit2 fork came about because the XFCE dev that initiated it read the final mailing list mails as Poettering wanted the Freedesktop.org repository dead and buried. Said dev seemed like he really wanted to reopen the consolekit repository rather than create a fork.

Re:Forked the Debian? or the Debian?

[Eunuchswear]

A weird attitude for a project that previously have forked such things as Firefox over a licensing issue.

Debian didn't fork Firefox. Mozilla told Debian that if Debian didn't build exactly the code that Mozilla released then Debian weren't allowed to use any Mozilla trademarks -- the name, the logo and so on.

Since Debian stable doesn't change versions (that's what stable means) that would have meant no bug fixes for Firefox (and Thunderbird) for a whole Debian stable release, which was unacceptable. So Debian made a version of Firefox with no Mozilla trademarks, Iceweasel. It's not a fork, Debian writes no code for it, it's just Firefox with a new name, logo, and whatever security patches are needed.

Why to develop anything?

[short]

Linux worked better - or rather it really worked - before systemd. Why to develop anything? Just keep the old proven and _working_ daemons.

Re:Why to develop anything?

[Anonymous Coward]

Fast. Reliable.Simple. Pick two.

1) People running IaaS/PaaS need to boot to a running OS/application in a fraction of a second, have fun doing that w/ a sequentially blocking init system & 20+ init dependencies (including long ones like network init/config that is otherwise idling the CPU, waiting for PHY devices, DHCP, etc to do their thing).

2) As software complexity increases (some software stacks have dependencies on things like elasticcache, redis, mongo, apache, etc, etc), achieving a parallel init system (point #1) and a robust self-recovering init system (which implies event dependencies, among other things that aren't simple order-of-init sequence things, but the state of hardware, or state of a daemon) - it becomes impossible to write a sysv init script that serves all purposes well (you can get the best common ground, but you won't achieve ideal efficiency for any dependent services, or you can optimise init for a specific dependent service and be potentially even worse for everyone else).

Re:Why to develop anything?

[short]

upstart is event based, it has replaced sysvinit in RHEL-6 and RHEL-6 still worked, I have noticed it has replaced init only after some time using it. systemd's scope is needlessly large for the even based parallelization, systemd replaces everything what worked and nobody complained before.

Re:Why to develop anything?

[Anonymous Coward]

Fast. Reliable.Simple. Pick two.

False assertation. daemontools, runit, s6 all do that successfully with simplicity and elegance.
systemd? a init spaghetti monster, even worse than sysvrc (in case you do not know sysvinit and sysvrc are two things).

Re:Why to develop anything?

[thegarbz]

Systemd's scope is as large as it needs to be for what it is trying to achieve, complete system level management. It was never about simply replacing the init system. In many ways it hasn't done anything to init systems that hasn't been done before by many of the init replacements.

But the thing about nobody complaining is that it just plain isn't true. People don't magically create software where there isn't a gap to fill (fucking about user interfaces excepted of course). There are people who think the idea of unified system management able to handle all aspects of process control in one package is great. There are plenty of detractors (especially vocal on slashdot) who will say that this should be managed by a set of 40 different projects, but it appears enough people think otherwise that it has not only been created but it has also been adopted.

Re:Why to develop anything?

[Anonymous Coward]

systemd replaces everything what worked and nobody complained before

logind is intended to replace consolekit, which is buggy and no longer being maintained upstream.

So your statement isn't true for this reason alone.

Re:Why to develop anything?

[Anonymous Coward]

for what it is trying to achieve

... that is quite a bad idea considering how poor it is implemented? An init subsystem that is even worse than sysvinit/sysvrc, a logging subsystem that is as notorious as Windows Event Log, a DNS subsystem that is coded without considering security, a DHCP subsystem that sacrifices security (susceptible to ARP attacks) in favor of speed, ... more to add.

Re:Why to develop anything?

[Spazmania]

I picked my two: reliable and simple. That's why I picked Debian. If my priority was "fast" I'd have picked Gentoo and suffered.

See init get complicated in the name of a faster boot gives me heartburn.

Re:Why to develop anything?

[Anonymous Coward]

Sad that Debian does not seem to be in the way it originally was.
Before Devuan matures, maybe Gentoo is worth a look, at least from the perspective of a Gentoo user :D

Re:Why to develop anything?

[short]

Maybe there is some need for extension (although I have never found it) but in that case - systemd is still too buggy to be deployed in a real OS. After any upgrade/update I am dealing with daemons refusing to start, system upgrade takes _whole_night_ because systemd crashed on an assert - on each host upgraded etc. etc.
It is similar to pulseaudio, since that time I had to learn all the options of audio software how to deal with silent audio which always worked before pulseaudio deployment.

Re:Why to develop anything?

[Barsteward]

Why don;t you create a blog and expand on all those assertions you've made about systemd so it is easily explained to all of us? All you seem to have done is put out your opinion with nothing to back it up - how can we make an informed decision on heresay?

Re:Why to develop anything?

[Anonymous Coward]

Why don;t you create a blog and expand on all those assertions you've made about systemd so it is easily explained to all of us? All you seem to have done is put out your opinion with nothing to back it up - how can we make an informed decision on heresay?

> An init subsystem that is even worse than sysvinit/sysvrc
That's admittedly subjective. If you want something loosely like an argument, see number of complaints about systemd vs number of complaints about sysvinit/sysvrc.
> a logging subsystem that is as notorious as Windows Event Log
See number of complaints and their similarity in design.
> a DNS subsystem that is coded without considering security
http://seclists.org/oss-sec/2014/q4/592
> a DHCP subsystem that sacrifices security (susceptible to ARP attacks) in favor of speed
https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8

Do you want more?

Re:Why to develop anything?

[Windowser]

I picked my two: reliable and simple. That's why I picked Debian.

I use Debian for the same reason

See init get complicated in the name of a faster boot gives me heartburn.

You need a system that boot fast when you reboot often. I don't care if my Linux system takes a couple seconds more to boot since I almost never reboot it.

Re:Why to develop anything?

[Anonymous Coward]

So half your assertions are vague generalities and the other half are FUD.

Re:Why to develop anything?

[IMightB]

Faster boot seems to be the one small feature that systemd haters pick up on. In reality, systemd provides many many more things than just a faster boot.

Re:Why to develop anything?

[Spazmania]

I think of it like passing programs between processes like bash now does in the environment variables.

DO. NOT. WANT.

Re:Why to develop anything?

[Anonymous Coward]

Heh...which is fully explained why by WHOM did it. Lennart Pottering. He's the dev that presided over similar semi-failed projects that were answers looking for problems to solve that few had. PulseAudio's one of those that most people know about. Avahi being one of the others.

With some of the ways they approach issues (which is to say, not- and tell you throw up your hands and hope for the best) I keep wondering what in the F*CK Red Hat is even thinking by bankrolling that idiot or any of the rest of his bunch. Seriously. Someone keeps backing this fool with stuff that's needing to be more and more mission critical...and he's not a f-ing clue about how to actually *DO* mission critical anything.

Re:Why to develop anything?

[Anonymous Coward]

Yeah, it brings corrupted and corruptable system logs. It brings all sorts of things that're *HIGHLY* debatable in a mission critical piece of software (best effort doesn't mean half-assed...they've got a LOT of that going on in there) with a team that possesses a mentality for code develoment that doesn't have a place in applications development, let alone systems development like this piece is.

Sorry, I understand the guts. YOU clearly don't. If you did, you'd have issues with it unless you're part of the bunch sponsored by Red Hat on this. This wasn't an answer. But then, neither was PulseAudio or Avahi before it. They were solutions looking for a problem to fix- that didn't really exist in the form they sought to fix things with. That's how Lennart actually goes about "designing" things, based on past track record- and it's no different now with this abortion he's gotten someone to sign off on and jam down people's throats- all in the name of "enterprise system configuration".

If you wanted Windows...USE Windows. This is the same problem set they "solved" with the same problems because of the "solution". You're not going to implement it better by trying again at it. Find a differing answer set.

Re:Why to develop anything?

[Anonymous Coward]

So half your assertions are vague generalities and the other half are FUD.

Notority can descends directly from complaints. And as to the FUD part, I feel really glad to see you have argument to say, except for they are "FUD" or by "haters" without evidence. Good job for you ;D

Re:Why to develop anything?

[Anonymous Coward]

In reality, systemd provides many many more things than just a faster boot.

Read as bloat.

Re:Why to develop anything?

[Anonymous Coward]

And as to the FUD part, I feel really glad to see you have argument to say, except they are "FUD" or by "haters" without evidence.

How clumsy of me, a "no" is obviously missing.

Re:Why to develop anything?

[Anonymous Coward]

Faster boot seems to be the one small feature that systemd lovers pick up on. In reality, systemd has very little to do with a faster boot.

Re:Why to develop anything?

[bucky0]

People don't magically create software where there isn't a gap to fill (fucking about user interfaces excepted of course).

Everything systemd aside, that's not true. The NIH-syndrome is alive and well. Instead of working on and improving existing software, a LOT of people want to start from scratch just so they can have their braces in the place they like to see them. For instance, I was poking around with protobuf earlier and saw that there are five javascript bindings.

Re:Why to develop anything?

[Barsteward]

"complaints" against something doesn't mean they are true, it can just mean they are they don't like "new". people will complain about something even if its faultless.

again, the logging is overblown because you can still have text logging so its used as a stick to beat systemd even though text logging still works.

again, that DNS component is optional. i'm sure they'll fix it at some point as they are discussing it now so until then use what you use now.

i didn't see anything in the blog post that says "sacrifices security (susceptible to ARP attacks) in favor of speed" but it does say they are pretty much the same speed as all other implementations so does that mean all other implementations are also sacrificing security in faour of speed?

Re:Why to develop anything?

[thegarbz]

See init get complicated in the name of a faster boot gives me heartburn.

If you think the goal of systemd was faster booting then you have some reading to do. Like a lot of reading.

Re: Why to develop anything?

[Anonymous Coward]

I still remember the times when sysv init was introduced: Replacing the simple and elegant BSD style init with a needlessly big and complex monster of sysv-init. People will always shout for the stuff they know, there is no argument there for which system is better.

The DNS problem is well within specification: Such simple caches do not need to do much wrt. security. Systemd is not the only offender in that area. Nor is that code even enabled by default.

The DHCP is fast:-) With ARP spoofing you can break most DHCP implementations (even the slow ones:-) and again that is a system that is not enabled by default.

The only argument you have against core pieces of systemd is hearsay. The rest is about stuff that is not enabled by default, and in areas that the systemd devs themselves do not recommend to use at this time.

Re: Why to develop anything?

[Anonymous Coward]

True.

Provided you consider init systems that can not reliably find the processes they started to be useful. They surely are simple.

Re:Why to develop anything?

[Barsteward]

Obviously Redhat don't suffer your unjustified prejudice against technical people that are far smarter than you could ever be.

Re:Why to develop anything?

[Barsteward]

I think i'd rather take Redhat, Suse etc stance over systemd than an AC who "proclaims" to "understand the guts" as I am sure they would rather not have a system given to clients that would be a problem. Fortunately your unsupported opinions don't carry any weight with likes of Redhat etc, fully supported opinions with evidence probably would be looked at.

Re:Why to develop anything?

[Spazmania]

Red Hat uses upstart. It's as nasty if not nastier than systemd.

Re:Why to develop anything?

[Spazmania]

Well, if it's goal was improved reliability or making the sysadmin's life easier it missed by quite a bit. If it's goal was something else, then it's moving in a direction other than the reason I wanted Debian for.

i want to see an ISO to burn & install

[FudRucker]

then i will see how much i like Devuan

Modular Debian

[trek00]

I see another good project starting, Modular Debian, that aims to integrate the pid 1 freedom in the main distribution, without forking https://www.freelists.org/arch...

Well I've donated a little to help.

[Anonymous Coward]

Already donated $10 dollars to help this...After all I like some diversity in my choice of Linux distros and different ways of implementing it.