The "Devuan" Debian fork
The "Devuan" Debian fork
Posted Nov 29, 2014 10:53 UTC (Sat) by Lionel_Debroux (subscriber, #30014)Parent article: The "Devuan" Debian fork
However, it appears that they're actively willing to duplicate, fracture, weaken and otherwise damage one of the most important projects for open source, upstream of many derivatives, directly used by tens of millions of persons in the world, instead of working with others as part of one, stronger Debian project...
Competitors weakening themselves through internal wars... Microsoft - even the new flavour thereof, more open towards Linux - must be overjoyed :)
Oh well. Hopefully, users will keep seeing the light, stick to the feature and use cases of the present and future provided by systemd in Debian and most other distros (*), and send that fork where it belongs, into oblivion...
Past discussions about init systems on LWN have shown that other init systems are no longer up to the task, let them rest in peace.
Posted Nov 29, 2014 11:20 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
On past form quite probably a fair few "black ops" guys, I expect ...
Cheers,
Posted Nov 29, 2014 11:45 UTC (Sat)
by Lionel_Debroux (subscriber, #30014)
[Link]
At work, I still have to deal with the combination of a custom System V init script, and restartd (to monitor and restart a daemon automatically), because of several x86_64 LMDE boxes, and also ARM boxes with such outdated, unmaintained kernels that they can't run systemd.
Posted Nov 29, 2014 13:46 UTC (Sat)
by philomelus (guest, #96366)
[Link] (16 responses)
Now that they are doing what they were told was the only option, people are up in arms about that too!
To paraphrase, "We are changing the way the entire OS starts up. If you don't like it, fork and continue to do it the old way."
"What is the matter with you people? Why are you forking over such a silly thing as the WAY THE OS BOOTS? Stupid greybeards. The majority voted and you lost, live with it!"
Posted Nov 29, 2014 14:31 UTC (Sat)
by thumperward (guest, #34368)
[Link] (1 responses)
If this takes off, and the dozen or so sociopaths who have made Debian's mailing lists such a cesspool for the last eighteen months or so all shuffle off to use it, then we'll all look back on it as a fabulous success. But I wouldn't hold my breath waiting for that outcome.
Posted Dec 2, 2014 12:01 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Nov 29, 2014 14:40 UTC (Sat)
by jwakely (subscriber, #60262)
[Link]
No they're not. Ignoring the sub-thread about corbet justifiably muting a troll account, the comments above seem to be mostly "I don't see the point in a fork" or "haha, whatever".
So your paraphrasing is wildly inaccurate.
Posted Nov 29, 2014 16:17 UTC (Sat)
by Lionel_Debroux (subscriber, #30014)
[Link] (12 responses)
Posted Nov 29, 2014 16:34 UTC (Sat)
by mgb (guest, #3226)
[Link] (8 responses)
There are already plenty of dependency-based boot managers. Technically systemd is nothing new, just NIH. And monolithic non-portable code can be found all the way back to the software stone age.
Nor is Embrace, Extend, and Extinguish new. Microsoft started using EEE decades ago.
FreeBSD may well implement an init system with similar functionality to systemd, but with modularity and without EEE it will not be at all similar to systemd.
Posted Nov 30, 2014 17:12 UTC (Sun)
by patrakov (subscriber, #97174)
[Link] (7 responses)
Posted Nov 30, 2014 18:39 UTC (Sun)
by gracinet (guest, #89400)
[Link] (4 responses)
Posted Nov 30, 2014 19:12 UTC (Sun)
by patrakov (subscriber, #97174)
[Link]
Node.js is so far the biggest offender, because it is plain impossible to write a correct UDP-based server in it that works on a multihomed system without resorting to timer-based polling of os.networkInterfaces(). Here "correct" means the following:
1. It must reply from the same of the several IPs belonging to a host where the UDP request came in.
I have expressed the issue in one of the comments to https://github.com/joyent/node/issues/8788 (no IP_FREEBIND, no IP_PKTINFO, no revcmsg/sendmsg (required to actually use IP_PKTINFO), no way to get notified about network configuration changes).
The second, smaller, offender is Python 2.7. It is possible to hack IP_FREEBIND into it (and bind to all "interesting" addresses in advance, even before they appear on interfaces), but not IP_PKTINFO (because of no recvmsg/sendmsg). Also good is that unofficial netlink bindings exist, so one can watch interfaces and IP addresses coming and going without resorting to timer-based polling.
Python 3.3 does have recvmsg/sendmsg support, and IP_PKTINFO can thus be hacked in. Ruby even has ip_pktinfo support out of the box.
Posted Nov 30, 2014 20:20 UTC (Sun)
by cortana (subscriber, #24596)
[Link] (2 responses)
Posted Dec 1, 2014 1:07 UTC (Mon)
by lsl (subscriber, #86508)
[Link] (1 responses)
That should be trivial to do in any programming language, as the file descriptors are just inherited from the parent process. It's there without you doing anything. The count of inherited FDs is passed in the environment (as LISTEN_FDS) and they start at 3.
Sure, there's the sd_listen_fds(3) C API but you don't actually have to use that. Especially not if calling into C involves unholy things like JNI.
Am I missing something?
Posted Dec 1, 2014 4:42 UTC (Mon)
by patrakov (subscriber, #97174)
[Link]
For TCP client sockets, this functionality does exist (new net.Socket([options])), but you can't import an already-existing listening TCP socket by fd. So even for TCP, supportable socket-activation functionality is limited to inetd-style daemons that are executed anew for each incoming connection.
Posted Nov 30, 2014 19:31 UTC (Sun)
by mgb (guest, #3226)
[Link] (1 responses)
A well-designed dependency-based boot manager might have some value on a laptop but production servers cannot rely on trying to guess all the O(N*2) dependencies between components.
Incidentally, all of our systems - servers, VPSs, laptops, and desktops - have one or more inittab entries to bring up serial consoles, maintenance networks, maintenance sshd, etc. Sysvinit tries them and if something fails it waits and tries again.
They work perfectly precisely because they don't rely on systemd-ish human-error-filled notions of trying to specify exactly which network interfaces and file systems need to be up and mounted.
Posted Nov 30, 2014 19:41 UTC (Sun)
by patrakov (subscriber, #97174)
[Link]
And in many contexts (in particular, in clusters where the service depends on something remote) trying and retrying until success is indeed the only working solution. The only possible disagreement here is whether such retrying should be done by the service or by the service manager, but I don't have a strong opinion here.
Posted Nov 29, 2014 17:23 UTC (Sat)
by rleigh (guest, #14622)
[Link] (1 responses)
As one of the sysvinit/initscripts maintainers, I'd say that we were well aware that while they had served us well for decades they did have certain shortcomings and that a replacement which solved these would have been well received. We were in no way opposed to a quality replacement so long as it was backward-compatible to allow upgrades without loss of function or configuration. Three years ago, I was hopeful that systemd had the potential to be that replacement, and spent some time investigating it. For reasons which have been tirelessly debated and which I will not reiterate here, I did not ultimately feel that systemd was suitable as a replacement, and in the three years since then the course of systemd development has not changed my opinion on the matter; if anything it has further reinforced it.
The need for this fork could have been avoided entirely if certain developers were willing to accommodate continued use of the old init. But willing cooperation is not part of some developers' agendas, and that is a great shame since it is that which allowed us to build such a high quality and comprehensive integrated software distribution in the first place.
While I still use Debian daily at both work and home, most of my systems have been running FreeBSD since February. I've needed to evaluate what the post-jessie migration paths might need to be. My plan is to switch over to Devuan once the dak instance and archive is set up, and participate in development at some level, though I don't know what the extent of that will be at this point. If it is small and focussed upon correcting this single major problem with Debian, I think it has a good chance of success, and we can hope that maybe the differences between the two distributions can be resolved at some point in the future. I'll continue to maintain stuff in Debian alongside this work.
Regards,
Posted Nov 29, 2014 18:18 UTC (Sat)
by Lionel_Debroux (subscriber, #30014)
[Link]
systemd clearly isn't perfect (some of its embarrassing holes have made it to oss-sec), the attitude of its maintainers doesn't shine, etc. However, in the big picture, the alternatives (mainly, according to the Debian init system discussion, sticking to sysvinit or switching to upstart) are worse in the short, mid and long term...
With both sides' abuse (there are casualties in the systemd packaging camp, too) and unwillingness to work with each other, the only way to resolve the differences between the two distributions, without burdening Debian and marginalizing it from the bulk of other Linux distros, shall probably be the fork disappearing. "Disappearing" means that it manages to appear in the first place, but in the short term, there are probably enough systemd haters out there for that to happen.
I'm not aware of die-hard sysvinit fans at my work place, thankfully. Most people are on Windows to begin with, and among Linux people, most are on RHEL / CentOS. Most of the few Debian-ers among us are already convinced that systemd is the path forward, due to its functionality and reach among distros. Good luck having uselessd, or suchlike works (I'm not saying that they're completely uninteresting), widely adopted.
*: that much-delayed and much-needed unification of Linux distros, to reduce duplication of effort and portability hurdles across distros in lower-level plumbery, and make Linux an even stronger competitor to Windows and MacOS X, across all platforms. Many other portability hurdles across distros will remain, but reducing one of them is a step in the right direction.
Posted Dec 2, 2014 18:39 UTC (Tue)
by rhawkins (guest, #100068)
[Link]
There's no need for the VUAs to "live with their times", as you put it, and likewise there's no reason for systemd proponents to not adopt systemd. The Devuan fork is not going to harm Debian, and may even be beneficial to Debian in the long term, as someone pointed out in another comment. There has already been a long history of Debian derivatives.
The majority of distributions have already switched to systemd. Surely having a selection of quality distributions which offer an alternative is a good thing? Why is choice suddenly bad?
Posted Nov 29, 2014 15:04 UTC (Sat)
by jb.1234abcd (guest, #95827)
[Link] (6 responses)
Are you talking about systemd ?
You would be interested in this eye opener about systemd-resolved:
"Competitors weakening themselves through internal wars... Microsoft - even the new flavour thereof, more open towards Linux - must be overjoyed :)"
No wonder ! Some people think that systemd does a "god's work" right out of
"Oh well. Hopefully, users will keep seeing the light, stick to the feature and use cases of the present and future provided by systemd in Debian and most other distros (*), and send that fork where it belongs, into oblivion..."
When uselessd sys init appeared on the scene they said that too.
Btw, there is an interesting view coming from InfoWorld that matches that of "graybeard" sysadmins:
That's all by being blessed by systemd !
Posted Nov 29, 2014 23:30 UTC (Sat)
by sjj (guest, #2020)
[Link] (5 responses)
Posted Nov 30, 2014 11:39 UTC (Sun)
by misc (subscriber, #73730)
[Link] (4 responses)
I guess that for some people, the Microsoft hatred is a fundational brick of their free software involvement, and suddenly discovering that things are more complex than the binary manichean division of the world they had in mind shattered their views of the world, who had to be readjusted to the new changes, and readjusted using schemas of the past. They maybe are trying to make sense on what they didn't like without knowing why, being fueled by the fears of their pasts, about frustrating experiences they didn't fully grasp.
So I am not sure what they need exactly, besides people to spend time to hear them and try to understand what they really fear. The kind of customer services jobs that the free software have always been good at avoiding, by not caring and chasing people who would be good for that, by showing that only technical contributions matters, forgetting all the others.
Posted Nov 30, 2014 20:31 UTC (Sun)
by dlang (guest, #313)
[Link] (3 responses)
as for talk of trying to create a monopoly, it's the systemd advocates/developers who say that the goal is to take over the entire linux plumbing layer so that they can make changes to every distro by just changing systemd
none of this takes a hatred of microsoft.
Posted Nov 30, 2014 23:32 UTC (Sun)
by misc (subscriber, #73730)
[Link] (2 responses)
Posted Dec 1, 2014 0:04 UTC (Mon)
by viro (subscriber, #7872)
[Link] (1 responses)
Posted Dec 1, 2014 0:37 UTC (Mon)
by ovitters (guest, #27950)
[Link]
If you read the "dng" mailing list, there is a high amount of what "misc" described going on. Just read it for yourself: https://lists.dyne.org/lurker/list/dng.en.html. It's only like 10 people though. It should be doable to have a good distribution when you have around 20-25 more-or-less active people. But if you read the mailing list it seems to be overly negative and a lot of strange suggestions/accusations/etc. Mainly hate and so on. A small amount of help by people not liking systemd and having the knowledge to do something about it and the distribution will thrive enough. Hopefully the atmosphere there will soon change for the better.
The "Devuan" Debian fork
Wol
The "Devuan" Debian fork
When the Jessie boat has sailed and been propagated in LMDE, and newer kernels have been provided by the manufacturer for the ARM boxes, no more System V script, no more custom postinst to add/update entries in restartd's conf... just a trivial systemd service.
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
the dozen or so sociopaths who have made Debian's mailing lists such a cesspool for the last eighteen months or so all shuffle off to use it
You really think they'd leave? They'd just find something else to be abominable about. It's the offense and the reaction and the sense of self-importance they care about, not the topic. (Most of them appear barely to know a thing about the topic.)
The "Devuan" Debian fork
The "Devuan" Debian fork
Have you seen that some people in the FreeBSD community, among whom one of the co-founders of FreeBSD, would very much like to see functionality and unification improvements in FreeBSD's init system, effectively making it more similar to systemd ?
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
2. It must deal with interfaces going up and down, appearing and disappearing, and the same for their IP addresses. In particular, it must not demand that all "interesting" IP addresses exist on the interfaces at startup time. Bonus points for not requiring to list all potentially-interesting IP addresses explicitly.
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
[To put this into perspective, I spent many man days of effort in the wheezy release making sysvinit align better with systemd to aid migrations and interoperability both ways; that's what you do when the goal is a well integrated distribution. I spent several solid days just making sure that hwclock timezone settings worked in every possible scenario. I think it's fair to say in retrospect that this was ultimately a fairly one-sided effort.]
Roger
The "Devuan" Debian fork
I only mentioned functionality (I meant, use cases that are better fulfilled by a systemd foundation than by a sysvinit foundation, in my own experience and that of many other people), and unification (*).
As we all know, systemd and sysvinit scripts are not even exclusive. AFAICT from watching the many sysvinit scripts involved in my Debian jessie/sid systems' boot process, including the $DAYJOB software whose init script I made in 2012, systemd's backwards compatibility with sysvinit scripts just does the job, in the meantime.
The "Devuan" Debian fork
The "Devuan" Debian fork
Add intrusiveness, lack of interoperability, etc ...
http://lwn.net/Articles/620879/
Posted Nov 17, 2014 18:36 UTC (Mon) by jb.1234abcd
Follow it thru to the end.
You will understand why so many people resist this and other parts of systemd.
an ops book by MS ...
http://uselessd.darknedgy.net/
An interesting overview too:
http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
By now, many already hope and openly admit that it has a chance to be
an alternative to systemd as we know it (and do know it or understand it
yet...).
http://www.infoworld.com/article/2608973/linux/it-s-time-...
At the bottom are more articles from "The systemd debate" series.
jb
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork
The "Devuan" Debian fork