Slashdot Mirror
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.
Totally beyond my previously (already good) expectations :)
They will have a future much more promising than those who are afraid of choice would say.
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?
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.
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.
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?
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.
Regards, Tobias
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.
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
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.
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.
Avoid the MS tax, always buy I.B.M. PC's (I Built-it Myself)
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.
Watch this Heartland Institute video
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.
All hope abandon ye who enter here.
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.
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.
Watch this Heartland Institute video
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.
-Bucky
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.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol