Originally posted by Xaero_Vincent
View Post
Announcement
Collapse
No announcement yet.
Devuan: Debian Without Systemd
Collapse
X
-
Originally posted by ryao View PostThat said, twisting my words really does not do justice to any sort of dialogue and reflects poorly on both yourself and those associated with you. Please either confirm that you reject the idea that there are different levels of ability among developers or apologize for misunderstanding my point.
Here's those twisted words again, folks:
"From my perspective, the systemd camp is mostly comprised of an end users who are vulnerable to hype and less experienced developers while the sysvinit camp is mostly compromised of system administrators and veteran developers."
That's what you said, right there. If you were only talking about developers of different levels of ability, perhaps that's what you should have written.
Comment
-
This issue with systemd vs init just seems like Gamersgate. Nobody knows why to hate systemd other for the reason of because. Is it better? Yes? Then why go through the trouble of making a fork of Debian for something outdated like init? Especially when you know nobody is going to use it.
If the developers of systemd are assholes is inconsequential to me and other people. Mostly because 99% using the OS don't know who the developers are or even know what systemd is. For that matter, even care.
Comment
-
Originally posted by ryao View PostThey are known to change working code and have broken working systems. One example involves the network device interface names, where fallback code was removed and system boot broke. A collegue of mine who is a major systemd fan and I had a discussion about systemd a few months ago. He had significant difficulty believing this was the case, but commit histories show that it was. In a similar vein, the core systemd developers have blamed others for bugs in software that they wrote because other software did not adapt to fix it. A prominent example involved the kernel syslog code. Their attitudes caused them to be banned from contributing to the Linux kernel.
They're known to "change working code", you say? No! How terrible!
Erm.
What software development project, exactly, doesn't "change working code"? Any commit other than one which exclusively fixes a bug that affected 100% of the user base "changes working code". It's an absurd objection.
"and have broken working systems"
Well, yes. That's called a "bug". Software has them. All software. Hey, let's take a look at the OpenRC bug tracker. Oh, what do we have here? "After update openrc in my lxc container from 0.9.8.4 to 0.11.6 and reboot, network interface in container up fail with error:"
Hey, looks like someone changed working code and broke a working system! (For bonus points, the developers then tell the user they were doing it wrong, just the sort of thing people are forever complaining about with systemd). Objecting to a software project on nothing more than the grounds that it "change[d] working code and have broken working systems" is like objecting to the sun on the grounds that it's hot. If you meant something more specific, *say* something more specific, I can't abide this kind of waffle.
"One example involves the network device interface names, where fallback code was removed and system boot broke...but commit histories show that it was"
But you don't link to anything or provide any kind of details. Hey, Veteran Administrator - this here thing's called the World Wide Web. You may remember why it got so popular in the first place - you can use these things called hyperlinks to handily provide useful references for people. You might want to try it. If you provided any kind of references for this I'm sure we could see that you were badly misrepresenting the situation, like I happen to know that you did the next one, but I'm not familiar with the case you're referencing here so I can't correct it.
"In a similar vein, the core systemd developers have blamed others for bugs in software that they wrote because other software did not adapt to fix it. A prominent example involved the kernel syslog code. Their attitudes caused them to be banned from contributing to the Linux kernel."
So as I said, I happen to know about this case (for which you, again, did not provide any references). What you're talking about is this issue. It was highly controversial, but you're just printing one side as if it were the Universally Acknowledged Truth.
What actually happened is that one particular systemd dev (Kay Sievers) and some kernel devs had a disagreement over the semantics/ownership of the boot command line; whether it's valid for systemd to enable its debugging mode when the 'debug' parameter is passed, or whether generic parameters like that should be assumed in some sense to 'belong' to the kernel. And then, as developers are sometimes wont to do, they got all Maury Povich about it. I wouldn't say it reflected particularly well on either side of that particular debate, but it's nowhere near as clearcut as you represent it. As for the 'banned from contributing to the kernel' bit, that was Linus in full-on "people should be retroactively aborted" mode. I'm inclined to suspect he was being melodramatic - here's his post, for reference. It's hard to tell whether he really meant the mail literally (hey, people are always keen to tell me he was just talking figuratively/non-seriously when I quote that earlier email, so why can't I suggest he was in this case?), because Kay doesn't really write upstream kernel code anyway, so it's kind of academic - but even if we assume for the purpose of argument that he was, you state "the core systemd developers...attitudes caused them to be banned from contributing to the Linux kernel.", which is clearly not supported by the facts, because Linus did not say anything about any systemd dev other than Kay in that particular debate.
Can we please have less of the vague, detail-free, reference-free mudslinging and more properly supported facts?
Comment
-
I should clarify something above - when I said "Kay doesn't really write upstream kernel code anyway" I meant he doesn't do it much *any more*, because he got worn down by the LKML attitude. He did used to do so. His last credited commit is from April 2013, and the last before that was in 2012. https://git.kernel.org/cgit/linux/ke...thor&q=sievers
Comment
-
Originally posted by BeardedGNUFreak View PostWatching the systemd fiasco continue to unfold from my perfect FreeBSD Unix workstation.
systemd - it's funny because it's not happening to me.
FreeBSD Founders/developer are proposing a systemd-like system to be created and laughing at linux for being held back by these flamewars about systemd instead of moving forward.
Comment
-
Don't name Debian 8 Jessie
Originally posted by dungeon View PostIt is relevent as it is, but is not releveant anymore for Jessie... systemd decision as default init system is maded for Jessie many months ago.
In perfect world, users should choose what they understand and not what they not . Some people probably does not care about writing very much comprehensive manuals, when init is so simple - code reading spoke very much about it
Comment
-
Originally posted by ryao View PostThere are a significant number of distribution developers who think that systemd is the only way to start software because of GNOME's dependence on it. There are also a significant number who think that systemd will be the only way to start all of their present software in the future. I also hear from people developing new Linux distributions that they are concerned about these things. These are concerns of inexperienced developers. Starting a daemon is not rocket science.
They are less experienced compared to developers such as Robert Leigh and Ted T'so.
The same could be said about system administrators adopting Windows versus those with UNIX beads who refer other systems. Many of them felt coerced into adopting it. There are people developing distributions who speak to me and say "I don't like systemd, but people say that I cannot develop a Linux distribution going forward without it.".
Only a masochist would [maintain downstream patches]. I would rather just refuse to put systemd on my computers than engage in such a one-sided relationship. Consequently, that is what I do.
I have sent patches to fix things in systemd-udev in the past and they were rejected because my use cases were considered stupid, despite the enterprise distributions getting patches for similar things. I have no interest in trying again. That was part of the reason eudev was founded.
Anyway, if you don't want to contribute to udev, then that is your right. And I actually applaude the eudev people for forking when there was a fundamental disagreement (which there was). To the best of my knowledge the disagreement was about backwards compatibility with older kernels and compatibility with non-glibc libc's. Whatever stance you take on these issues I believe are fair, nothing is inherently wrong here, it is just about what your aims are as a project. However, these aims (of udev and eudev) are mutually exclusive, so a compromise is not really possible. I have criticised the way in which the eudev group technically went about their fork, as that was not really professional nor helpful to themselves nor conductive to future collaboration (they made forwards and backwards porting extremely hard, and broke a lot of stuff unnecessarily). What they could have done instead would have been to maintain a handful of patches on top of systmed which would give them precisely the same result but without all the code-churn. At the end of the day, that's their problem, I just wanted to point out that I did not mean to criticise the fact that they forked, I'm all for that.
I consider those that claim that /etc/rc?.d is part of sysvinit to lack understanding at such a fundamental level that they have no idea what they are discussing.
The discussions in which you have taken part are *much* better than the ones in which I have taken part.
You are going to have to be more explicit. The way that OpenRC scripts work is to block until something is up and things are allowed to run in parallel provided that they do not depend on one another. I am not familiar with any races under this model.
Anyway, the aim should be simplified daemon startup (i.e., move as much of the common logic from the daemons to the supervisor), and simplified dependency handling. In order to do that systemd implements things like socket-activation (which means there is in many cases no longer a need to specify the dependencies between things anywhere), and to allow daemons to drop things like double-forking.
Now, if you were to take a daemon written for systemd (i.e., without any explicit dependencies, and/or without doing double-forking and PID-file writing) and run that under OpenRC, it will be racy as OpenRC does not know precisely when it is ready, so does not know when to start follow-up services. Or worse still, daemons that do double-forking and PID-file writing and all the other dances they need to do in order to work properly on OpenRC, but somehow messes it up (it is not that easy to get right, and daemons _keep_ getting it wrong) will also be racy. It is much easier to write a correct daemon under systemd as all this code can simply be dropped.
The purpose of the redundancy is to enable updates to be done without restarting the system. I understand that systemd can do execve, although this is much more dangerous
than just changing things outside of PID 1.
Add support for other libc libraries, add compatibility shims for older kernels,
document things like XDG_RUNTIME_DIR so that you do not get maintainers of alternative systems like Roger Leigh complaining about how poorly documented things are,
actually offer suggestions on how use other distributions' existing cases can be handled without telling them that they are stupid,
stop making backward incompatible changes to long established code (e.g. network device naming) without leaving compatibility code to avoid breaking system services.
If marketshare is your only measure of success, then there is nothing that could make systemd more successful. The same can be said for the Windows operating system. That said, there are other metrics, such as not breaking systems when package upgrades are done and keeping an always releasable HEAD. Commits to the systemd repository have historically failed these metrics so horribly that I no longer bother to look.
There are a significant number of distribution developers who think that systemd is the only way to start software because of GNOME's dependence on it. There are also a significant number who think that systemd will be the only way to start all of their present software in the future. I call that buying into hype.
Telling people that they are the equivalent to members of a terrorist groups for not using systemd with Linux as someone did in this thread and other remarks like it are contrary to the principles of free software. Do you mean to say that this is not the case?
I disagree. OpenRC handles people's use cases and incrementally improves as time passes. We do not have to deal with inoperable systems because of the latest experiment that the OpenRC developers decided to do. To me, that is very exciting.
Comment
-
Originally posted by pal666 View Postutter bullshit. debian is hostile to nt kernel. there is no debian/kreactos. i demand to ban sysvinit from debian because it harms choosing kernels
I know this is a troll post but just how would a NT kernel be made to interact with a completely *nix GNU userland? Maybe with a huge amount of hacking, implementing *nix style system calls and subsystems into into the ReactOS kernel, things can be made to work. As of now ReactOS and it's kernel can only run Windows applications with likely less compatibility than even Wine.
There was once even an effort for Debian/kNetBSD but it was abandoned because almost nothing worked and that was even a *nix kernel.
In contrast, Debian GNU/kFreeBSD is pretty straightforward and most programs compile and run without problems in Debian using GCC and glibc rather than BSD libc; Only minor patches here and there are needed for things to work. At least this was the case until systemd appeared. Granted, the BSDs are beginning to work on a systemd-compatable "systembsd", so in the long term it might not be a huge problem. They are also trying to reimplement somthing like launchd from MacOS X.
Comment
Comment