[go: up one dir, main page]
|
|
Log in / Subscribe / Register

Devuan Jessie beta released

Devuan Jessie beta released

Posted May 1, 2016 20:00 UTC (Sun) by darwish (guest, #102479)
In reply to: Devuan Jessie beta released by ddevault
Parent article: Devuan Jessie beta released

I'm really tired of these attacks on GNOME "drinking the systemd kool-aid" stuff ..

Systemd is a core port of Linux ecosystems these days, just like the kernel. It's a foundation layer that finally brings some much needed order, coherency, and vertical integration to the mess that is Linux userspace.

This vision is _way different_ from how Linux was built in the past, and people will need to re-learn things and ease out their own attachments to the old way of doing things.

For more details, check Greg KH article on the futhre of Linux as a _tightly-coupled_ "core distro":

https://plus.google.com/+gregkroahhartman/posts/V2t57Efkf1s

This tight-coupling is the vision of things going forward; a tight core containing the kernel, kdbus IPC, systemd, polkit, logind, and other core userspace daemons. Initiatives like GNOME xdg-app [1], and new KDE versions [2] will also be tightly-coupled with such core.

Check the link at [2] to understand the valid reasons upstream developers are voting with their own development time for such coupling.

Yes, this will leave people who enjoy configuring their systems to the smallest minutiae (Gentoo users, etc.) a little bit on the dust. But before putting all of the blame on systemd, please remember that:

- This is the path most of the relevant upstream developers are embracing (Gnome, xdg-app, KDE)

- This is also the path most of the industry has taken since the 2007 in the form of iOS, Android, OLPC [3], and Apple TV.

- Surprise, surprise, this is also the same vision currently embraced in the serverland in form of CoreOS, etcd and fleet.

[1] https://wiki.gnome.org/Projects/SandboxedApps
[2] http://blog.davidedmundson.co.uk/blog/systemd-and-plasma
https://blog.martin-graesslin.com/blog/2014/10/libinput-i...
[3] https://lwn.net/Articles/494095/

to post comments

Devuan Jessie beta released

Posted May 1, 2016 20:04 UTC (Sun) by ddevault (subscriber, #99589) [Link] (40 responses)

To clarify, I personally use and appreciate systemd. It's quite clear that GNOME has been moving towards not supporting operating systems that don't have systemd, though. This isn't just a problem because of people who have some kind of religious hate for systemd, though - consider for example the case of running GNOME desktops on Unix systems that aren't Linux. The BSDs of course won't have systemd support. Even if systemd was portable it'd probably be a hard sell.

Yeah, systemd is different, and maybe that's not a bad thing, but it's also not Unix. Settle down and let the people who like Unix keep enjoying Unix.

Devuan Jessie beta released

Posted May 1, 2016 20:24 UTC (Sun) by darwish (guest, #102479) [Link] (35 responses)

> consider for example the case of running GNOME desktops on Unix systems that aren't Linux. The BSDs of course won't have systemd support. Even if systemd was portable it'd probably be a hard sell.

The Linux desktop market share is really in single digits.. We are already pretty late, and soon Android will transition to become a desktop environment and everyone will be screwed .. the Android desktop layers are a code dump rather than concrete community-based open-source projects .. thus the Linux desktop won't be a collaborative project anymore and depend on google bi-yearly code dumps ..

The Linux desktop must quickly move and support things like containerized applications, app stores, etc. like what's now done with the combination of systemd+kdbus+xdg-app .. and all of these depend on Linux-specific features. Otherwise we may all go bust and return to a ubiquitous semi-proprietary desktop environment ..

So in this case, the BSDs must not drag the Linux desktop down or everyone will lose. If someone wants to invest efforts, let him or her develop systemd shims in-place (as the KDE developers stated in the link I've posted earlier) ..

> Yeah, systemd is different, and maybe that's not a bad thing, but it's also not Unix. Settle down and let the people who like Unix keep enjoying Unix.

Yup, and in a sense the Linux Kernel too is not Unix anymore .. Unix stopped its growth by the early 90s .. modern operating systems are now heavily IPC-based systems, which has nothing to do with Unix ..

Devuan Jessie beta released

Posted May 1, 2016 20:40 UTC (Sun) by ddevault (subscriber, #99589) [Link] (34 responses)

> The Linux desktop market share is really in single digits.. We are already pretty late, and soon Android will transition to become a desktop environment and everyone will be screwed .. the Android desktop layers are a code dump rather than concrete community-based open-source projects .. thus the Linux desktop won't be a collaborative project anymore and depend on google bi-yearly code dumps ..
> The Linux desktop must quickly move and support things like containerized applications, app stores, etc. like what's now done with the combination of systemd+kdbus+xdg-app .. and all of these depend on Linux-specific features. Otherwise we may all go bust and return to a ubiquitous semi-proprietary desktop environment ..

Do you think any of this has anything to do with Linux's market share? Containerized apps and app stores are going to do next to nothing for Linux market share, and are in fact entirely unrelated to Linux market share. Windows doesn't have these things and it's doing fabulously well in terms of market share. The reason Linux doesn't have market share is a combination of lack of vendor support and bad marketing. We're fighting for market share against opponents with million and billion dollar budgets against our $0 budget.

Why do we even need more market share? Who cares? What will we have sacrificed to get it? We shouldn't worsen our OS in the name of attracting more non-technical users. Our users are the technical kind already, work for their sake instead of for the imaginary non-technical Linux user.

Devuan Jessie beta released

Posted May 1, 2016 21:06 UTC (Sun) by darwish (guest, #102479) [Link] (6 responses)

> Why do we even need more market share? Who cares? What will we have sacrificed to get it?

Market share is quite important, even from a pure technical standpoint.. But maybe I should've rephrased it to "mind"-share ..

For example, now every ARM board manufacturer has Linux BSP + Yocto build out of the box. Why are they doing so? Because the mind-share of Linux on embedded ARM boards is very high .. This benefits the entire Linux ecosystem: more developers & users = more bug reports, more questions and answers on online forums, and a much bigger set of possible contributors in the future ..

The same case happens for the Desktop.. Now for example if you buy an Nvidia Tegra board, you'll find all of the supplier blessed development tools works and tested only on Ubuntu LTS by default. Why? Because Ubuntu has the highest (ancedotal) market/mind share in the Linux desktop ..

Now the Linux desktop is in a crisis.. All the new generations are developing apps for iOS and Android, and this is hurting the Linux ecosystem pretty badly.. To newer generations "open-source" means just creating Android mods on xda-developers and the like..

If Android gets on its way and transcend to the Desktop, this means it will have quite high market share.. And since people are quite familiar with its Java APIs, creating easily-instealled apps for such a desktop will be a snap ..

If this gloomy scenario continues without a user-friendly and application-development-friendly alternative, the open-source community linux desktop with be further marginalized to negligence .. and Android will be the new Linux desktop all the new generation uses .. This means that over-time only the Linux Kernel will be truly built in an open-source community manner .. the community won't have control on the rest of the stack of anymore (except on the server land) ..

> We shouldn't worsen our OS in the name of attracting more non-technical users. Our users are the technical kind already, work for their sake instead of for the imaginary non-technical Linux user.

This is a short-sighted argument. More users = more mindshare = more future developers = a non-aging always-youthful platform = more support from the industry = more lower levels (hardware) and the upper levels (apps) support .. Otherwise, our beloved platform will be marginalized to negligence ..

And systemd is really not worsing our OS architecture. On the otherhand, it finally modernized it for today's server, desktop, and even embedded use-cases ..

Devuan Jessie beta released

Posted May 1, 2016 21:16 UTC (Sun) by ddevault (subscriber, #99589) [Link] (4 responses)

You're incorrectly conflating youth with technical imcompotence. Today's young technologists, like yesterday's young technologists, are a diverse group. These new programmers who are working on Android and iOS might otherwise be working on Windows or OSX yesterday, not Linux. The last "generation" of new programmers would split their time and their individuals between making websites, making little games with GameMaker, making little Windows Vista sidebar widgets, and so on. The situation hasn't changed, just some of the players - and Linux is still definitely in the game.

How will Linux be any better anyway if we move everything, _everything_ to this same monolithic architecture our opponents use? An enormous part of what makes Linux appealing is the ability to mix and match components and customize the system to your heart's content.

Devuan Jessie beta released

Posted May 1, 2016 21:39 UTC (Sun) by darwish (guest, #102479) [Link] (3 responses)

> How will Linux be any better anyway if we move everything, _everything_ to this same monolithic architecture our opponents use? An enormous part of what makes Linux appealing is the ability to mix and match components and customize the system to your heart's content.

You can mix and match as you like, all you'll have to do is to mix-and-match above kernel+systemd, instead of just above the kernel.. this is the "core distro" vision outlined here http://lwn.net/Articles/685679/ and supported by upstream devs these days ..

> The situation hasn't changed, just some of the players - and Linux is still definitely in the game

In the desktop land, this platform called 'linux desktop' has just failed horribly.. Linux desktop in 26 years failed to achieve a 1/100 of what iOS and Android achieved in the last 8 years .. we don't have a platform with stable and easy-to-develop-against APIs, and as a result we having nothing of the interesting applications, games, etc...

Devuan Jessie beta released

Posted May 1, 2016 22:29 UTC (Sun) by ddevault (subscriber, #99589) [Link] (2 responses)

> You can mix and match as you like, all you'll have to do is to mix-and-match above kernel+systemd, instead of just above the kernel.. this is the "core distro" vision outlined here http://lwn.net/Articles/685679/ and supported by upstream devs these days ..

What, with GNOME? Hah. GNOME implements everything desktop themselves and are actively against attempts to integrate anyone else's software into their desktop. GNOME is the poster project for NIH. You also keep dragging this "core distro" vision around like I don't understand it or like it's a good thing - I do and it's not.

> In the desktop land, this platform called 'linux desktop' has just failed horribly.. Linux desktop in 26 years failed to achieve a 1/100 of what iOS and Android achieved in the last 8 years .. we don't have a platform with stable and easy-to-develop-against APIs, and as a result we having nothing of the interesting applications, games, etc...

We have loads of interesting applications and plenty of APIs for building them with, from GTK to Qt, from wxwidgets to SDL, and so on. We have an incredibly rich application landscape. And none of it is thanks to anything like systemd. These are fundamentally unrelated things - stop shipping the entire operating system with it's desktop UX. Android and iOS's success is completely unrelated to their widget toolkits or desktop UX, it's related to the fact that your average joe can walk into their local phone store and get a damn phone running Android or iOS.

It's not like these have stable or easy-to-develop-against APIs, either. Have you ever tried to develop applications that support a broad range of Android versions? It's a bloody nightmare. I don't know much about iOS but I presume it's not much better with all sorts of apps only supporting the newest versions of iOS. On Linux pretty much every application since the dawn of Linux will still run on Linux, at least until this big unification/containerization/monolithicization effort pays off.

Devuan Jessie beta released

Posted May 2, 2016 0:26 UTC (Mon) by pizza (subscriber, #46) [Link]

> Have you ever tried to develop applications that support a broad range of Android versions? It's a bloody nightmare.
> I don't know much about iOS but I presume it's not much better with all sorts of apps only supporting the newest versions of iOS.

Are you seriously complaining that developers deliberately choose to take advantage of features only present in newer versions of operating systems? Have you actually checked the deployed market share of these older versions?

With Android, the collective install base for everything older than 4.0 is under 5%. But hey, you can download the SDK today, and target Android 1.0 if you choose... and it'll even run on a modern device. But it won't have access to any of the APIs added to Android in the past, oh, eight years or so.

With iOS, it's even more pronounced -- over 85% of the market is using the latest iOS version (9), and less than 6% of devices run iOS 7 or older. Granted, Apple is a lot more aggressive in deprecating older versions, but the fact remains that if you are writing a new application today, there's no point in targeting anything other than the last two versions.

> On Linux pretty much every application since the dawn of Linux will still run on Linux,

Only if you're able to recompile it, and everything it depends on. Hence the beef commercial concerns have with Desktop Linux.

Devuan Jessie beta released

Posted May 2, 2016 1:46 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> What, with GNOME?
No, not only with GNOME.

> We have loads of interesting applications and plenty of APIs for building them with, from GTK to Qt, from wxwidgets to SDL, and so on. We have an incredibly rich application landscape. And none of it is thanks to anything like systemd.
I'd say we have at least some applications despite them having to deal with SysV init and other mess.

And actually, you're wrong. CoreOS (which is getting popular) depends on systemd.

> It's not like these have stable or easy-to-develop-against APIs, either. Have you ever tried to develop applications that support a broad range of Android versions?
I have. We supported around 300 devices for our application. They needed an occasional tweak here or there, but it mostly JustWorked. These days it's even easier to do it with DeviceFarm on Amazon AWS.

> On Linux pretty much every application since the dawn of Linux will still run on Linux
ORLY? Do you mean if I take a binary from Debian Potato and run it on Fedora 23 then it'll just work?

Devuan Jessie beta released

Posted May 2, 2016 7:46 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

> If this gloomy scenario continues without a user-friendly and application-development-
> friendly alternative, the open-source community linux desktop with be further
> marginalized to negligence .

While systemd and containers are kool tech, Linux desktop people delude themselves if they actually think any tech can substitute itself to strong adherence to backwards compatibility (And no automated baseline snapshots are no substitute.).

Embedded and server Linux thrives, because it depends on the kernel and on middleware that doesn't change behaviour or name every six months (the evil aggressive Linus T that stomps any attempt to make progress at the expense of existing apps). Desktop Linux will remain a no-go as long as its promoters are more interested in reworking the plumbing than in stabilizing it.

Devuan Jessie beta released

Posted May 1, 2016 22:28 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (26 responses)

> Do you think any of this has anything to do with Linux's market share?
Yes. Classic Linux has always been a nightmare for vendors to support. Still is, but it's getting better.

> Why do we even need more market share? Who cares? What will we have sacrificed to get it?
Desktop Linux doesn't _need_ a market share. It can go on as a fringe OS for somewhat crazy enthusiasts pretty much indefinitely. Kinda like AmigaOS or BeOS.

> We shouldn't worsen our OS in the name of attracting more non-technical users.
It's not your OS. You don't own it.

Devuan Jessie beta released

Posted May 1, 2016 22:34 UTC (Sun) by ddevault (subscriber, #99589) [Link] (24 responses)

> It's not your OS. You don't own it.

Right, which is why the Devuan folks have jumped ship to another one. I'm discussing a comment that originally lamented the lack of GNOME support, and it's entirely GNOME's fault that this is the case. Don't get upset when folks like Devuan take their ball and go home to write another distro - we told them to when we refused to listen to their concerns about systemd and the Big Gross Unification.

Devuan Jessie beta released

Posted May 1, 2016 22:49 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (17 responses)

> I'm discussing a comment that originally lamented the lack of GNOME support, and it's entirely GNOME's fault that this is the case.
No, it's not GNOME's fault. GNOME does what is best for GNOME, in opinion of GNOME's developers.

> Don't get upset when folks like Devuan take their ball and go home to write another distro - we told them to when we refused to listen to their concerns about systemd and the Big Gross Unification.
Upset? No, you don't get upset at clowns.

There were far more productive ways to deal with the problem. For example, creating a fork of systemd with additional features like optional journald. If that fork turns out to be popular then chances are it will be merged into the mainline. It's not even that hard, systemd's codebase is clear and modular.

Instead they've chosen the most stupid way to do changes, even going on a crusade against libsystemd. I predict that the whole idea will die off in a couple of years (at most) without producing anything useful.

Devuan Jessie beta released

Posted May 1, 2016 22:52 UTC (Sun) by ddevault (subscriber, #99589) [Link] (16 responses)

I'm pretty certain that Devuan isn't going anywhere, too. But I respect some of the developers for their opinions and for putting their money (or at least effort) where their mouths are. But this is definitely not an option:

>For example, creating a fork of systemd with additional features like optional journald. If that fork turns out to be popular then chances are it will be merged into the mainline. It's not even that hard, systemd's codebase is clear and modular.

You clearly don't understand their beef with systemd. Things like journald are just the details that contribute to the whole - systemd is *fundamentally different* from what they want to see from their operating system.

Devuan Jessie beta released

Posted May 1, 2016 23:12 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

> You clearly don't understand their beef with systemd. Things like journald are just the details that contribute to the whole - systemd is *fundamentally different* from what they want to see from their operating system.
And that's why they are clowns. They simply dismiss _everything_ different and want everything to stay the same, just because they have "30 years of experience". The appropriate reaction to this is to point and laugh.

There are more serious projects to create a better init system. For example: http://homepage.ntlworld.com/jonathan.deboynepollard/Soft...

I doubt they are going to achieve much, but they are at least _trying_ to do something new. I personally highly respect this.

Devuan Jessie beta released

Posted May 2, 2016 7:13 UTC (Mon) by jaromil (guest, #97970) [Link] (14 responses)

your comments are offensive and contain false information about Devuan. For example:
1- Noone of us said "30 years of experience" despite the fact among us are people with even more than that
2- We don't intend to keep everything the same, this is also stated on the website regarding ongoing research on init systems. I'll be looking at nosh, while being a fan of GNU DMD.
3- You seem to imply Devuan is an init system project. Its not: we are developing a new base distribution, which to us mostly means binaries and a very minimal, non obtrusive layer to handle their execution.

Devuan Jessie beta released

Posted May 2, 2016 8:06 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

> your comments are offensive and contain false information about Devuan.
Really?

> We don't intend to keep everything the same, this is also stated on the website regarding ongoing research on init systems. I'll be looking at nosh, while being a fan of GNU DMD.
Yeah, sure. I predict that it'll end up with a huge "best init system" bikeshed thread. And since half of those "veteran unix adminstrators" have superstitions against cgroups ("It can steal your soul!"), nothing really interesting will come out.

> You seem to imply Devuan is an init system project. Its not: we are developing a new base distribution, which to us mostly means binaries and a very minimal, non obtrusive layer to handle their execution.
So far I see pointless crusades against libsystemd and pretty much nothing else.

Devuan Jessie beta released

Posted May 2, 2016 8:36 UTC (Mon) by jaromil (guest, #97970) [Link] (12 responses)

>> your comments are offensive and contain false information about Devuan.
>Really?

yes.

> "veteran unix adminstrators" have superstitions against cgroups ("It can steal your soul!")

false information. is this a literal quote? if not, why quotes?
FYI what we call VUA is an informal group of IT professionals counting more than 1000 subscribers.

> So far I see pointless crusades against libsystemd and pretty much nothing else.

False information.

Devuan is not waging any crusade against libsystemd. There is nothing religious in what we do. Believe it or not, some of us have nothing against systemd per-se.
Referring to your statement here: libsystemd is a package still found in Devuan's beta release.

Devuan Jessie beta released

Posted May 2, 2016 8:45 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

> false information. is this a literal quote? if not, why quotes?
Just read _this_ article. Lots of systemd haters simply have no idea what cgroups do and why they are needed.

> Devuan is not waging any crusade against libsystemd.
Yes, it does.

Other readers, sorry for the quote:
> Since I'm running Debian testing on my desktop, I decided to look at the
> packages, and there it was, systemd was installed automatically somehow
> when upgrading my packages! I've installed Debian once, 10 years ago,
> and was just upgrading the packages occasionally ever since then, so
> package upgrades was the only way systemd was able to sneak into my
> computer. It feels like my computer was infected by a bad virus. I
> quickly removed the systemd package and all packages that depended on it
> without issues. However, I noticed libsystemd0 was still installed and
> doing a reverse dependency check showed that there are lots of important
> packages that indirectly depended on it because of dbus depending on it.
> That is clearly a bug, and I hope Debian can fix this issue. Normally,
> I wouldn't object to having some library installed, but from what I read
> about systemd from the links on your site, it's so awful that I don't
> even want its library installed on my computer.

> Referring to your statement here: libsystemd is a package still found in Devuan's beta release.
That's because this crusade is abandoned because of too much work. As ultimately other stuff is going to be abandoned.

But please, do continue to provide entertainment.

Devuan Jessie beta released

Posted May 2, 2016 8:51 UTC (Mon) by jaromil (guest, #97970) [Link] (9 responses)

We should try to stick to technical arguments. While we do, nothing prevent people from coming here or on our mailinglist or on our IRC channel to posting text which basically amount to rants without technical merit.

You are one of those people, as your interaction here is manipulative, offensive and does not contain any factual evidence for your assertions.

Devuan Jessie beta released

Posted May 2, 2016 8:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Technical arguments? Who cares about technical arguments?! SystemD is the Great Satan of software and must be destroyed.

You asked for evidence about libsystemd crusade - I provided a quote from a previous version of the Devuan website. And this very thread has uninformed rants against control groups.

Others might try to read the Devuan mailing list and confirm it for themselves. It's helpfully archived by gmane: http://news.gmane.org/gmane.linux.devuan.devel

Devuan Jessie beta released

Posted May 2, 2016 9:55 UTC (Mon) by jrigg (guest, #30848) [Link]

> Technical arguments? Who cares about technical arguments?!

Most of the readers here, I imagine. Is it too much to ask to keep the discussion on a polite and rational level?

Devuan Jessie beta released

Posted May 2, 2016 14:50 UTC (Mon) by mgb (guest, #3226) [Link] (4 responses)

> Technical arguments? Who cares about technical arguments?! SystemD is the Great Satan of software and must be destroyed.

Great Satan? No. Harmful monolithic hack? Yes.

Hacking is creative and wonderful. Much that is good in computer science started as hacks. But init systems are not new. Dependency-based init systems are not new. Gnu/Linux needs an engineered init solution, not a hack backed by a tawdry political movement. I don't know who V.R. is but this is half of the sort of document that the Debian Tech Committee should have produced instead of the hand-waving we saw from both sides: http://blog.darknedgy.net/technology/2015/10/11/0/ Anyone who has to use systemd would do well to read V.R.'s document for a much better understanding than systemd's own documentation offers.

Nevertheless, despite ignoring decades of software engineering, the systemd hack would still be a valuable experiment if it were truly modular. It is not. It has a vast and untidy surface over a convoluted and unstable interior. There are arguments to the contrary by those who look at the nitty gritty of makefiles and build options while ignoring the big picture but the fact is that distros are splitting into with-systemd and without-systemd flavors because by intent and by poor design systemD is in practice monolithic.

Systemd succeeded because Gnu/Linux is modular - truly modular in practice. But SystemdD itself is monolithic. It blocks the way forward for Gnu/Linux. This is why I have always opposed systemd and why the route forward from Wheezy is Devuan. Not because systemd was an undesigned hack that just grew and metastasized, not because systemd is a bad implementation of a good idea, but because systemd seriously impedes the future development of F/LOSS.

Devuan Jessie beta released

Posted May 2, 2016 15:16 UTC (Mon) by peter-b (guest, #66996) [Link]

I'm looking forward to your forthcoming good implementation of systemd's "good idea". If it successfully addresses the problems that systemd solves, then I'm sure it will be adopted very enthusiastically.

I don't mean this sarcastically or dismissively -- I genuinely believe that there is space for multiple implementations of a good dependency-based, race-free init system for Linux. Even better if it exposes an implementation of the public systemd API so that people can try it out with their existing tools more easily.

Devuan Jessie beta released

Posted May 2, 2016 15:21 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

… but because systemd seriously impedes the future development of F/LOSS.

Considering that the cobbled-together suckage that is the traditional setup (System-V init, init scripts, inetd, cron, at, syslogd, …) apparently hasn't managed to seriously impede the future development of F/LOSS for the last 25 years or so, I wouldn't worry unduly about systemd. People have obviously dealt with much worse stuff than systemd (and by all indications don't mind planning on still dealing with it going forward, see Devuan), or we wouldn't be here now.

Devuan Jessie beta released

Posted May 2, 2016 15:59 UTC (Mon) by johannbg (guest, #65743) [Link]

Well there are cases where you still "cobbled-together" components with systemd like for example it's a common misconception that type timer units replace a cron based solution that stems from people filled with the bright idea of migrate "everything" to native systemd type units which ends up like a work of bunch of idiots re-implementing cron in the form of timer units but now with the double the administrative overhead to it's end users and no technical benefits.

When I went through the whole components that ship cron scripts in Fedora ( ca 100 components ) only half of that was applicable to be migrated to timer units and once I had gone through those ca 50 components that ship those cron scripts and filtered out the unused, obsoleted scripted trash which seem to be shipped and exist only to waste peoples space on hardrives or serve as an example to the terminal world how not to write a script, I ended up with roughly 30 components which would have been migrated.

In the above example these two solution complement each other short comings and should be implemented as such where applicable in the distribution and elsewhere not re-implemented in the form of type timer units instead of cron scripts because they "can" or systemd is "hot" for the moment.

Devuan Jessie beta released

Posted May 2, 2016 18:19 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> Gnu/Linux needs an engineered init solution
Then provide one.

> I don't know who V.R. is but this is half of the sort of document that the Debian Tech Committee should have produced instead of the hand-waving we saw from both sides: http://blog.darknedgy.net/technology/2015/10/11/0/ Anyone who has to use systemd would do well to read V.R.'s document for a much better understanding than systemd's own documentation offers.
I read this document. I don't see any real technical points against systemd design in principle. And no, "inelegant" does not count. Real-life systems are almost always "inelegant" from theoretical standpoint.

There are also lots of inaccuracies in details (like the statement that cgroups v2 requires the single writer).

And really, statements like:
> It should be noted that dynamic tracing is another potential way to achieve deferred execution conditional upon resource availability.
Are a _huge_ warning sign for anybody maintaining real-life systems.

Devuan Jessie beta released

Posted May 2, 2016 18:55 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

>Technical arguments? Who cares about technical arguments?! SystemD is the Great Satan of software and must be destroyed.

I thought GPL was. Changed your mind already? ;)

Devuan Jessie beta released

Posted May 2, 2016 19:30 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

GPL is the Greater Great Satan. Duh.

Devuan Jessie beta released

Posted May 2, 2016 13:19 UTC (Mon) by smcv (subscriber, #53363) [Link]

> Devuan is not waging any crusade against libsystemd

From the outside, its long list of forked packages certainly gives the impression that it is. I maintain dbus upstream and in Debian, so I was curious what the debdiff for that source package would look like.

It appears that the changes are as follows:

* Remove the libsystemd build-dependency and don't pass --enable-systemd to configure. This is the "don't link libsystemd" change.

* Don't pass --with-systemdsystemunitdir to configure. Together with the previous, this results in the systemd metadata (a few hundred bytes of text) not being installed.

* Merge the version of dbus 1.8.20 that used to be packaged in stretch before it was superseded by 1.10 (1.8.20-1), not the version that is in jessie (1.8.20-0+deb8u1, which has the new upstream version but not the packaging changes). This does not fill me with confidence about Devuan's change-management: if I had intended those packaging changes to be in a jessie stable-update, I would have put them there. I suspect this was accidental. However, it's nice to know that I'm more conservative about what I'll include in a stable update than Devuan developers are...

Why are you bothering to patch this package for those, if the answer isn't "removing libsystemd for political reasons"? Even if we take it as axiomatic that systemd will not be used, the only positive technical effect of diverging from Debian here is to save a few K of disk space (a library and metadata that would not have been used if init wasn't systemd). This seems a deeply inefficient use of developer time; you could save much more space than that, if that's your goal, by compressing /usr/share/doc/*/copyright.

If you do want to remove libsystemd for political reasons, something like https://anonscm.debian.org/cgit/users/md/libsystemd-dummy... [1] would involve an order of magnitude less forking than what you seem to have done. Every package you fork consumes developer time and is an opportunity to introduce bugs and/or delay security fixes; if it has taken this long to get a beta-quality fork of Debian 8, it seems that developer time is a resource that should be used wisely.

I should perhaps mention here that in addition to libsystemd, dbus-daemon in Debian links two libraries that can never be in active use at the same time[2]: libapparmor and libselinux. This nicely illustrates how, if your goal is to minimize unused library dependencies, Debian is unlikely to be the best place to start. Fedora, for example, has a much closer focus on providing only the things that are actively supported, with SELinux and no AppArmor in their dbus-daemon. The flip side of that is that they only support their chosen init system, which happens to be systemd.

Once again, I work on Debian, not Fedora; I don't think minimizing unused library dependencies is actually a particularly useful goal, so I ship a dbus-daemon in Debian that can be used to its full potential with any or no LSM, and with or without systemd.

[1] provided by a Debian systemd maintainer out of frustration with how some anti-systemd efforts were approaching their chosen task
[2] assuming the corresponding "big LSMs" don't become stackable at kernel level, which seems unlikely

Devuan Jessie beta released

Posted May 2, 2016 8:24 UTC (Mon) by ovitters (guest, #27950) [Link] (5 responses)

> I'm discussing a comment that originally lamented the lack of GNOME support,
> and it's entirely GNOME's fault that this is the case

I tried working with Devuan on their _public_ mailing list to see if there were places we could work together. Similar to how I reached out to *BSD, Gentoo, MATE, etc.

Status: *BSD people can approve git.gnome.org accounts. MATE (and similar projects) maintain several GNOME components with releases on download.gnome.org, etc (so beyond just being able to approve git accounts). Several years ago we've integrated several patches during some freeze because we had several assumptions that compiling with systemd meant it was also the init system. This at the time that Canonical/Ubuntu used Upstart (the time logind started to depend on systemd).

Devuan mailing list is toxic. I tried to be as approachable as possible as well as waiting a few months to hope for the trolls to go away. After reaching out, I got _loads_ of offlist insults. Now you say it is entirely GNOME's fault? Really? Read the Devuan mailing list and search for my name.

Devuan Jessie beta released

Posted May 2, 2016 8:46 UTC (Mon) by jaromil (guest, #97970) [Link] (4 responses)

Dear Olav,

I'm sorry you had this experience on the DNG mailinglist. I see you have posted 3 times regarding GNOME, on 5th Dec. with an incipit which was rather negative to begin with.

Rest assured that the people who have replied you in public are not representative of Devuan, with the exception of Matteo who is also a member of VUA. Here a link to his reply to you: https://lists.dyne.org/lurker/message/20141205.144514.5f9...

I hope with this exchange we can get over the noise and re-connect on the topic which was debated, as I share Matteo's enthusiasm for your effort to reach out.

MVG

Devuan Jessie beta released

Posted May 2, 2016 11:37 UTC (Mon) by pizza (subscriber, #46) [Link]

> Rest assured that the people who have replied you in public are not representative of Devuan, with the exception of Matteo who is also a member of VUA. Here a link to his reply to you: https://lists.dyne.org/lurker/message/20141205.144514.5f9...

Unfortunately, while all but one of the folks responding may not *represent* Devuan, they are actually *representative* of Devuan.

Devuan Jessie beta released

Posted May 2, 2016 18:51 UTC (Mon) by rahvin (guest, #16953) [Link] (1 responses)

If your public mailing list is that toxic it's useless and you should be reaching out to their mailing list and doing the coordination on your end. That's the cost of having a mailing list like that.

Devuan Jessie beta released

Posted May 3, 2016 14:59 UTC (Tue) by jond (subscriber, #37669) [Link]

We suffer this problem in Debian, too - the listmasters do try but sometimes they appear overwhelmed.

Devuan Jessie beta released

Posted May 3, 2016 6:57 UTC (Tue) by ovitters (guest, #27950) [Link]

The negativity is expected after seeing so much false statements, personal attacks and so on.

The mailing list is still toxic IMO.

Written by Nate Bargmann on April 30th 2016 (http://article.gmane.org/gmane.linux.devuan.devel/10009):
> When he discusses GNOME Shell, etc., perhaps what he doesn't realize is
> that many of those developers may not be eating their own dog food as it
> were. For how long haven't we been reading about and watching various
> videos from FOSS conferences only to realize they're often using the most
> proprietary hardware and software in the world today, AND DAMNED PROUD
> OF IT. It made me sick read yet another developer (sometimes even a

It took me barely 3 minutes to such drivel making really bad _personal_ statements. It's not about GNOME, it is about the people and attacking them.

I know the actual Devuan developers are good. You or another Devuan developer mentioned this in a personal email IIRC. But if the mailing list is so toxic then it's highly likely I get agitated. It's not on to me to stay super polite while seeing one message after the other like above.

Devuan Jessie beta released

Posted May 2, 2016 20:54 UTC (Mon) by roc (subscriber, #30627) [Link]

> Desktop Linux doesn't _need_ a market share.

Maybe not in some absolute sense, but the lower its market share is, the harder it will be for people who want to use it to actually use it ... because hardware and application support will deteriorate, for example.

Devuan Jessie beta released

Posted May 2, 2016 6:30 UTC (Mon) by anselm (subscriber, #2796) [Link] (3 responses)

Yeah, systemd is different, and maybe that's not a bad thing, but it's also not Unix. Settle down and let the people who like Unix keep enjoying Unix.

The funny observation here is that pretty much all the non-Linux “Unix” systems have got rid of System-V init ages ago, in favour of something more or less like systemd.

Devuan Jessie beta released

Posted May 2, 2016 11:58 UTC (Mon) by ddevault (subscriber, #99589) [Link] (1 responses)

FTR I think System-V init is awful and the systemd init is fine. It's the rest of systemd that most of its opponents take offense at.

Devuan Jessie beta released

Posted May 2, 2016 13:08 UTC (Mon) by anselm (subscriber, #2796) [Link]

But then again the rest of systemd is largely optional – nobody forces you to use systemd's network configuration tools, NTP client, or DNS resolver, for example. Even the journal can be mostly omitted in favour of a traditional syslog-based approach, although unless you're processing vast numbers of log messages per second it's probably not worth the trouble. (And the systemd journal does have its advantages – I'm working on an appliance-type system now, and having a web-based interface to the system log is really quite popular with our customers. The journal makes it easy to drill down to the messages from a particular systemd service during a particular period of time, and I would really hate to have to implement this based on the traditional setup – I would probably have to get rsyslog to write stuff to an SQL database, and I'd much rather get by without that particular complication.)

OTOH, it's the cross-distribution unification of large swathes of the basic plumbing that makes systemd interesting to distribution maintainers, because they can direct their attention towards other areas of the system.

Devuan Jessie beta released

Posted May 2, 2016 19:10 UTC (Mon) by flussence (guest, #85566) [Link]

Adding to the irony, Debian itself seems to be the upstream for sysvinit. It sends a clear message when the distro usually most resistant to arbitrary change wants to wash its hands of a piece of infrastructure it's in full control of and already invested in.

Devuan Jessie beta released

Posted May 2, 2016 8:05 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (49 responses)

Lol. "People who enjoy configuring their systems to the smallest minutiae" are the core Linux constituency. They're most desktop Linux users and are also the elite system administrators.

We won't be left in the dust. GNOME, KDE, et al. are already being left in the dust. LXDE and XFCE have already eaten most of their market share; MATE and Trinity have fragmented the remaining devotees; and, the exodus is continuing.

Linux's power comes from its configurability. With Slackware's BSD-style init system, you can see exactly what is making the system boot, just by opening up some shell scripts, and, if you need to change something about the boot process, you can do it with just a text editor.

The anti-SystemD side has the talent. SystemD is and will be used by the lower-skill, corporate drone system administrators -- you know, the ones who pay Red Hat for support. And also the casual Linux desktop users. And, also, a small amount of highly skilled administrators in specialized domains (huge server farms, perhaps) where the things SystemD brings to the table actually matter. SystemD is good for some things, after all ... just not very much.

Traditional init will continue to be used by all the mobile developers creating new Linux-based hardware: they will have no choice as simply including the SystemD binary would double the size of the required flash in many of these cases. It will also be used by all of the skilled system administrators who manage servers not of the cookie-cutter variety. And, of course, it will be used by the most skilled, most "hardcore" Linux desktop users and developers -- that is, the ones most likely to have the capability of scratching an itch and bringing something useful to the table. We don't care what GNOME or KDE does because we switched to XFCE, or LXDE, or i3, or openbox, many, many years ago.

How many devs do you think Devuan has? I have no idea, but I doubt many. It doesn't strike me as a big project. But they won't need many, because they have a good, intelligent plan to leverage as much of Debian as possible, continuously, and they have the skills to implement that plan. Making a distro doesn't take much if you're good: I once used a Slackware SPARC port that was maintained by exactly one guy. And he had an unrelated full-time job and just did it in his spare time.

Many of the most skilled Linux users will not use SystemD. And we will continue innovating. And we will be fine.

Devuan Jessie beta released

Posted May 2, 2016 8:43 UTC (Mon) by anselm (subscriber, #2796) [Link] (44 responses)

The anti-SystemD side has the talent. SystemD is and will be used by the lower-skill, corporate drone system administrators -- you know, the ones who pay Red Hat for support. And also the casual Linux desktop users. And, also, a small amount of highly skilled administrators in specialized domains (huge server farms, perhaps) where the things SystemD brings to the table actually matter. SystemD is good for some things, after all ... just not very much.

Chances are that systemd will be used by virtually anyone running RHEL, SLES, Fedora, openSUSE, Debian, and Ubuntu, simply because all of these distributions now come with systemd by default and there is really no compelling reason to change to anything else. What percentage of Linux users does that cover?

It's also a bit premature to claim that “the anti-systemd side has the talent”. There's certainly enough “talent” on either side of the divide, and a lot of the “talent” simply doesn't care because the init system on their machine doesn't impact what it is that they are doing. For sure there are loads of articles and conference talks by clever and talented people to the effect that “I used to hate systemd but once I got around to actually looking into it I really started to like it”.

Traditional init will continue to be used by all the mobile developers creating new Linux-based hardware: they will have no choice as simply including the SystemD binary would double the size of the required flash in many of these cases.

We hear that many embedded-system developers really like systemd for a variety of reasons, including fast boot times and the ability to do clean “factory resets”. My mobile phone is running systemd and it works just fine, thank you very much.

Many of the most skilled Linux users will not use SystemD. And we will continue innovating. And we will be fine.

Good for you. But it seems to me that you may be seriously overestimating the number of people who dislike systemd to a point where they feel compelled to run anything else. After all if you're, say, a desktop developer it doesn't really matter all that much what you're running as an init system. For sure whether your system runs on System-V init or systemd has virtually no bearing whatsoever on your ability to write kick-ass desktop applications.

Devuan Jessie beta released

Posted May 2, 2016 10:34 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (40 responses)

Generic desktop developers can certainly run SystemD, yes. If that's all you do, you'll be fine. SystemD will only start to get in your way when you want to do things like manage MythTV boxes' auto-startup and auto-shutdown, or when you want to do FDE using something custom instead of just dm-crypt, or, well, you get the idea.

I don't know what percentage of Linux users will ultimately end up using SystemD in the short term. Rattling off names of distributions isn't an argument; the usage share of Linux distros is and always has been very fluid. What I do know is that there are enough distros keeping the flame alive that, when newbie but enthusiastic hobbyists find SystemD getting in their way, and they will, they'll find the threads comprising "World War SystemD" on the Internet when looking for a solution, and undo the damage by uninstalling SystemD. Just like they used to follow, and sometimes still do follow, the forum post directions on uninstalling PulseAudio when it inevitably flaked out on them.

And those hobbyists are the ones that really matter. Generic desktop developers may give us stuff, yes, like spreadsheet programs and silly games, but those programs won't have any need to depend on SystemD anyway, and so won't. It's people using Linux in non-traditional ways or settings, like with MythTV boxes, RPi things, etc., who will need to do init customization. And SystemD will inevitably get in their way, because they will know shell scripts but not the Satanic invocations comprising SystemD unit files, so they will go online, Google, find instructions on getting rid of SystemD so they can do what they want, and get rid of SystemD.

That's why we'll be fine: most of the important people, the ones who will need to customize their inits, won't use SystemD, because they won't like it. In the cases some hobbyist does like it and makes MythTV or whatever depend on it, there will almost certainly be another hobbyist who wants to use the package in question, but not SystemD, and so will port the package. In the end, then, SystemD won't be necessary for anything, so the anti-SystemD crowd won't be left behind.

You're all excited about SystemD's market share, but that's not what matters. The only people who matter to those who want to use Linux are those who contribute to Linux.

Think of Mork, for instance. Mork is likely the most horrible light database format for web browsers ever designed. It doesn't work right, is fundamentally incompatible with everything that came before it and after it, solves only problems that already had easy solutions, and solves them poorly -- it's basically the SystemD of web browser databases. But, boy did Mork get market share! Anyone who ever used Netscape, Mozilla, Seamonkey, Thunderbird, or old versions of Firefox is a Mork user: it was adopted by Netscape and Mozilla everywhere.

But that didn't matter. Other web browsers eventually got more popular than Firefox, email viewing habits moved away from Thunderbird, and the only lesson other light databases took from Mork was "don't do that". Mork is still today used in Thunderbird -- it hasn't died out yet -- but it clearly wasn't an advance in light database technology, despite the fact that it had powerful corporate backers and got lots of market share for a time, and, in he end, Firefox and most other projects that used Mork in the past switched to sqlite. The people who actually mattered to Mork's long-term health -- developers who needed to use light database -- saw it was a lemon and steered clear. So, in the end, Mork didn't win, even though its market share among users of web browsers and email clients was once quite high.

Market share of the kind you're citing is a mirage.

Devuan Jessie beta released

Posted May 2, 2016 11:36 UTC (Mon) by darwish (guest, #102479) [Link] (19 responses)

> Generic desktop developers can certainly run SystemD, yes. If that's all you do, you'll be fine. SystemD will only start to get in your way when you want to do things like manage MythTV boxes' auto-startup and auto-shutdown, or when you want to do FDE using something custom instead of just dm-crypt, or, well, you get the idea.

The idea of systemd's being only suitable for the desktop, and that it "will only start to get in your way when you want to do things" is a big myth.

It has been outlined, multiple times in this thread, how systemd is really helpful, and actively used, in the domain of embedded development [1][2][3].. Outlined earlier how all the automotive folks actually moved to systemd, etc.

I hope you would trust me when saying that I've been working in the embedded domain for three years and I see systemd everywhere ..

[1] http://lwn.net/Articles/685655/
[2] http://lwn.net/Articles/685666/
[3] http://lwn.net/Articles/685688/

And on the server side, I've seen how systemd with its proper service managemnt, logging, resource limitations, etc. is dominating... How the systemd/PID 1 dbus API [4] is used extensively by both custom and open-source VM/Containers management solutions for better machine handling, etc..

And in the development communities, when you talk to the actual developers, be it GNOME, KDE, Yocto, CoreOS, RedHat, etc.. systemd is just a given .. no one is debating its place anymore, and people are quite happy by what it does provide ..

I'm sorry, the anti- systemd people live in their own bubble

[4] https://www.freedesktop.org/wiki/Software/systemd/dbus/

> What I do know is that there are enough distros keeping the flame alive that, when newbie but enthusiastic hobbyists find SystemD getting in their way, and they will, they'll find the threads comprising "World War SystemD" on the Internet when looking for a solution, and undo the damage by uninstalling SystemD.

systemd is gaining cross-industry collaboration I don't really know what you're talking about .. again, all of what I'm seeing above is your own fantasy futuristic scenarios ..

Don't you know that now systemd has dedicated developers from Canonical, Google, CoreOS, etc. etc. .. plus all the personal contributors in their own spare time? Maybe you should look at the systemd's github pulse graph before making any judgements:

https://github.com/systemd/systemd/graphs/contributors

> Just like they used to follow, and sometimes still do follow, the forum post directions on uninstalling PulseAudio when it inevitably flaked out on them.

As a person who contributes to PulseAudio, this is just more of a confirmation that you're living in your own bubble .. There's no Linux installation these days who does not use pulse (except AudioFlinger on Android and CRAS on ChromeOS .. but that's another story) .. and I'm sorry, people are quite happy with the out-of-the-box experience provided by pulse .. an experience which has taken a lot of hard work, _by a lot of very kind & sincere people_, to achieve ..

> And those hobbyists are the ones that really matter. Generic desktop developers may give us stuff, yes, like spreadsheet programs and silly games,

systemd has no relation to "generic desktop developers .. developing silly stuff"; it's a _core_ Linux component happily used by server, desktop, and embedded Linux engineers everywhere .. The above clearly shows that you're not quite involved in the Linux scene in the past 3 or 4 years ..

> like with MythTV boxes, RPi things, etc., who will need to do init customization. And SystemD will inevitably get in their way

Nonesense future fantasy. Actually systemd is quite helpful in these scenarios and finally provide a clean base to design your embedded system upon .. check the link at [3] for more details ..

> , because they will know shell scripts but not the Satanic invocations comprising SystemD unit files, so they will go online, Google, find instructions on getting rid of SystemD so they can do what they want, and get rid of SystemD.

Now you're becoming funny .. you mean like how systemd service files helps to proper do SMACK labeling? (check [2]), proper resource allocation, etc.?

I just worked on a legacy non-systemd board two weeks ago, and returning back to the shell scripts, custom PID files, custom log files, etc. was just hurrendous ..

> That's why we'll be fine: most of the important people, the ones who will need to customize their inits, won't use SystemD, because they won't like it.

oh, so now you & the anti-systemd crowd are the important people? And those developers contributing day&night to embedded, server, and desktop Linux are crooks ... pretty convincing, I see ..

> You're all excited about SystemD's market share, but that's not what matters. The only people who matter to those who want to use Linux are those who contribute to Linux.

Most of the people _actually contributing_ to the Linux ecosystem are on the systemd side .. this has been a given for 2 years it's no longer funny .. please check all of the abve again ..

Devuan Jessie beta released

Posted May 2, 2016 23:22 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (18 responses)

> And in the development communities, when you talk to the actual developers, be it GNOME, KDE, Yocto, CoreOS, RedHat, etc.. systemd is just a given .. no one is debating its place anymore, and people are quite happy by what it does provide ..

Hey, most people everywhere will go with the flow and up in the drain. Whatever is default gets used by those too lazy or incompetent to change the default. Mork's still in Thunderbird. No argument there.

> Outlined earlier how all the automotive folks actually moved to systemd, etc.

Automotive Linux people kind of live in their own community.

> As a person who contributes to PulseAudio, this is just more of a confirmation that you're living in your own bubble .. There's no Linux installation these days who does not use pulse (except AudioFlinger on Android and CRAS on ChromeOS .. but that's another story) .. and I'm sorry, people are quite happy with the out-of-the-box experience provided by pulse .. an experience which has taken a lot of hard work, _by a lot of very kind & sincere people_, to achieve ..

Well, it's true Pulseaudio's not as bad as it once was. It's still IMO a totally pointless and silly project (not unlike SystemD), but inertia is keeping it alive. Like Mork. But hey if having PulseAudio on your system does something for you, and you enjoyed the work and think it helped people, then good for you. No hard feelings.

I don't use PulseAudio and am the author of the section on removing it from Slackware: http://docs.slackware.com/howtos:multimedia:pulseaudio_no...

Also you don't need to use PulseAudio on Gentoo, so it's not just Android and ChromeOS.

> systemd has no relation to "generic desktop developers .. developing silly stuff"; it's a _core_ Linux component happily used by server, desktop, and embedded Linux engineers everywhere .. The above clearly shows that you're not quite involved in the Linux scene in the past 3 or 4 years ..

"Core Linux component" is meaningless. /bin/true is a core Linux component. And nice ad hominem.

> Nonesense future fantasy. Actually systemd is quite helpful in these scenarios and finally provide a clean base to design your embedded system upon .. check the link at [3] for more details ..

My Slackware MythTV installs work fine without SystemD. A few custom shell scripts to handle BIOS wake timers and done. They also boot pretty fast. What could SystemD have brought to the table there? I just compiled a custom OpenWRT install for a router with 4MB flash. I didn't even have space for LuCI in my image; no way that fat bastard SystemD would have fit. There's more to embedded than high-end tablets nailed into cars' dashboards and ARM systems like the Pi with effectively unlimited disk space.

> Now you're becoming funny .. you mean like how systemd service files helps to proper do SMACK labeling? (check [2]), proper resource allocation, etc.?

No hobbyist anywhere in the world doing anything conceivable with a Pi or home media center is going to give 2 flying kites about SMACK labeling.

> oh, so now you & the anti-systemd crowd are the important people? And those developers contributing day&night to embedded, server, and desktop Linux are crooks ... pretty convincing, I see ..

No one called anyone a crook. The important people for Linux hobbyists are the ones who make the tools they use. Which is themselves. For instance, I don't care at all what anyone at GNOME, KDE, LibreOffice, or Unity does. I haven't used any software from them for any serious purpose for many, many years. I bear them no ill will, but they are, to me and others like me, totally and completely unimportant. If they choose to use SystemD for something, I hope it brings them great joy. But it won't affect me either way.

Who is important? To me personally, the XFCE project, Slackware, MythTV, Python, the kernel, etc. For others in the hackersphere, LXDE, Gentoo, Ruby, Perl, and the like are probably on the list, too. Formerly, Debian was on the list, too. Now Devuan will be instead.

> Most of the people _actually contributing_ to the Linux ecosystem are on the systemd side .. this has been a given for 2 years it's no longer funny .. please check all of the above again ..

I'm sure it takes many, many people to maintain the monstrous, creaking behemoth that is GNOME. And they're certainly part of the Linux community. And I'm glad they have something they like to do and I wish them all the best.

But my "ecosystem"? They're not important to the hacker ecosystem. The ecosystem of Linux newbies and nontechnical folks, sure. Not the ecosystem of Linux hobbyists. Heck, Slackware hasn't even packaged GNOME for ages. It hasn't been missed.

Just recently, there was a story about the KDE packager for Slackware getting increasingly fed up with how KDE's sloppiness was making it difficult to package. Maybe it will be dropped, too. I doubt it would be missed, either.

Devuan Jessie beta released

Posted May 2, 2016 23:30 UTC (Mon) by dlang (guest, #313) [Link] (12 responses)

> They also boot pretty fast. What could SystemD have brought to the table there?

wasn't there just an article or post about boot speed where the systemd advocates were very vocal in saying that boot speed was not a goal of systemd?

Devuan Jessie beta released

Posted May 2, 2016 23:57 UTC (Mon) by anselm (subscriber, #2796) [Link] (8 responses)

AFAIR, increased boot speed is not a primary goal of systemd. The fact that systemd-based machines tend to boot quite quickly is a side benefit of how systemd deals with unit dependencies during bootup, particularly by aggressively starting lots of things in parallel and doing socket activation for services where possible.

For example, in the traditional setup the rc processor would try to start the syslog daemon while every service that wants to use logging is held up waiting for the syslogd init script to finish. Systemd, on the other hand, simply opens the relevant socket(s) itself so other programs that “depend” on the log service can start sending messages to it even though it isn't actually running yet. Systemd launches the actual syslog daemon once messages come in, and then hands the socket and messages over to it so they can be processed. (This is just for illustration; we know that logging in systemd actually works somewhat differently due to the journal, but the main idea is the same.)

For the user, the net result is that boot times for systemd are typically very short, which is nice no matter why it happens. Having said that, systemd does provide tools that admins can use to investigate where time is being spent during the boot process if they want to identify bottlenecks or make optimisations.

Devuan Jessie beta released

Posted May 3, 2016 4:55 UTC (Tue) by dlang (guest, #313) [Link] (5 responses)

no, systemd doesn't just open the socket for the logging daemon to use later, it fires up the logging daemon which then opens the socket receives, buffers, and writes the log message.

systemd isn't magic, you can't just create a socket and have logging happen.

Devuan Jessie beta released

Posted May 3, 2016 5:15 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

I was under impression that data is simply buffered in the default socket buffer? Attempting to read might be counter-productive because of all the possible complications with file descriptors and SCM_RIGHTS.

Devuan Jessie beta released

Posted May 3, 2016 5:20 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

nope, systemd starts journald which processes the message as it is written, does the SCM_CREDENTIALS looup, buffers the data, writes it to disk, and then listens for requests on another socket for things to read the logs.

As the final step it can also write the logs out to a syslog daemon, including forging the SCM_CREDENTIALS in the kernel so that the syslog daemon gets the correct info when it does the queries.

Nothing so mundane as simply buffering the data somewhere until later in the boot process when syslog gets around to reading it.

the kernel kbuf has been doing that buffering of logs to be read later for many years for kernel messages, systemd didn't need to do anything to make those reliable.

Devuan Jessie beta released

Posted May 3, 2016 5:22 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Does it do this for all sockets? It makes sense for syslog, but I don't think you can do it with file descriptors.

Devuan Jessie beta released

Posted May 3, 2016 5:30 UTC (Tue) by dlang (guest, #313) [Link]

for other socket activation, systemd doesn't do anything with the data, it just hopes that the kernel buffers are large enough that the sender doesn't block too long while it starts up the daemon that will actually process the data.

This works fairly well when the thing being activated either isn't too complex, or is doing a complex enough task that the added delay on the first use doesn't add too much to the time (printing for example)

Devuan Jessie beta released

Posted May 3, 2016 7:22 UTC (Tue) by anselm (subscriber, #2796) [Link]

Here's Lennart Poettering on socket activation in systemd.

Devuan Jessie beta released

Posted May 3, 2016 10:55 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

journald is quite nice.

As for systemd making boot faster by aggressively parallelising things, as per another sub-thread, this has the downside of exposing utilities to parallelism that they were never designed to handle, which can actually *severely* _slow_ boot. Again, my experience with systemd is that my boot has gotten *many times* slower.

Even when everything behaves, I've noticed in the past the massively parallel approach can thrash the disk somewhat. I'm not entirely convinced throughput of boot is always as improved by this as it could be. It might be better to limit the number of parallel launches somewhat (if systemd doesn't already know to do this).

Devuan Jessie beta released

Posted May 3, 2016 12:03 UTC (Tue) by pizza (subscriber, #46) [Link]

> Again, my experience with systemd is that my boot has gotten *many times* slower.

I don't doubt that you're seeing these results, but it appears to be a rare exception given the overwhelming body of evidence showing large improvements in boot times -- Including *every* experience I've had, from relatively tiny embedded systems to big servers and everything in between.

I suspect that the problem isn't actually due to systemd itself, or even its aggressive parallelism, instead being a misbehaving component whose failure/delay was effectively ignored in the past. But without additional legwork on your part to identify what's going on, the situation isn't likely to change.

(As an aside, the 12-core workstation under my desk at the office boots up Fedora 23 faster from spinning rust than CentOS6 does on an SSD, despite the former actually starting up more stuff and attaching some network mounts..)

Devuan Jessie beta released

Posted May 3, 2016 8:17 UTC (Tue) by rschroev (subscriber, #4164) [Link] (2 responses)

> wasn't there just an article or post about boot speed where the systemd advocates were very vocal in saying that boot speed was not a goal of systemd?

I seem to recall something like that, yes. But they would be wrong: "Rethinking PID 1" [1], Lennart Poettering's original systemd announcement, is largely about boot speed.

[1] http://0pointer.de/blog/projects/systemd.html

Devuan Jessie beta released

Posted May 3, 2016 10:27 UTC (Tue) by niner (guest, #26151) [Link] (1 responses)

You could get this impression if you stop reading somewhere before the "Keeping Track of Processes" headline which is a bit less than a third into the document.

Devuan Jessie beta released

Posted May 3, 2016 10:50 UTC (Tue) by itvirta (guest, #49997) [Link]

He does pretty much start with the speed issue though. Of course the article is six years old so it might not be representative of what the priorities have been later.

> As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.

Devuan Jessie beta released

Posted May 3, 2016 0:18 UTC (Tue) by johannbg (guest, #65743) [Link] (3 responses)

Ah your a slacker that explains alot.

I suggest you always start introduce yourself as a slacker which will put peoples expectation of you into the right decade.

Actually the maintainer(s) of dropline gnome ( which is or was based on slackware ) did a tremendous work converting/implemented systemd in slackware in a faint hope to attract more/new users to slackware in general but by now they should have realized that it was a futile effort ( both trying to attract new users to it as well as try to "modernize" it ) and have either scrapped dropline project altogether or reverted to slackware native init system.
( which was the foreseeable outcome last time I checked )

Has pat released any new release these days or has he abandoned is cult followers altogether or is he in his awol state ( appears in the linuxquestion.org forum and utter he's alive when rumours of his demise have started circulating ) ?

Devuan Jessie beta released

Posted May 3, 2016 13:40 UTC (Tue) by jrigg (guest, #30848) [Link] (2 responses)

> as pat released any new release these days or has he abandoned is cult followers altogether
That's easy enough to check:
http://www.slackware.com/changelog/

Slackware -current is on the verge of release and is quite useable.

I've been considering switching my remote server to Slackware from Debian (which I've used since 2.2), mainly because of the very long term support and the minimal number of invasive changes between versions. The -current version is a little bleeding edge (in terms of software versions) compared with Debian, but after testing it I've concluded that it's a very nice solid distro.

Devuan Jessie beta released

Posted May 3, 2016 14:45 UTC (Tue) by johannbg (guest, #65743) [Link] (1 responses)

Since there has been over three years from it's last release I have to ask how to you determine that something is on the "verge" of being released since there is no fixed schedule and when you refer to very long term support you are referring to what exactly?

As far as I can tell everything in that community is based on whatever and whenever pat feels like doing something. . .

Devuan Jessie beta released

Posted May 3, 2016 15:08 UTC (Tue) by jrigg (guest, #30848) [Link]

> Since there has been over three years from it's last release I have to ask how to you determine that something is on the "verge" of being released since there is no fixed schedule and when you refer to very long term support you are referring to what exactly?

Slackware -current is in Beta 2 and is in a very useable state, which I would interpret as being close to release (but as you say, it will only be released when PV considers it ready).

By very long term support I'm referring to the fact that security updates are still released routinely back to 13.0, which was released in 2009.

Devuan Jessie beta released

Posted May 3, 2016 14:29 UTC (Tue) by darwish (guest, #102479) [Link]

> Well, it's true Pulseaudio's not as bad as it once was. It's still IMO a totally pointless and silly project (not unlike SystemD), but inertia is keeping it alive ... I don't use PulseAudio and am the author of the section on removing it from Slackware: http://docs.slackware.com/howtos:multimedia:pulseaudio_no...

Yes, but a regular user who wants to have an _out of the box_ audio experience. For example, usb audio, audio redirection to hdmi, power consumption savings due to how pulse is designed to minimize hardware interrupts, etc.. definitely needs an audio server (Windows and Mac also ship with one for similar reasons ..)

> Also you don't need to use PulseAudio on Gentoo, so it's not just Android and ChromeOS.

They are still using a sound server, and CRAS on ChromeOS also use timer-based scheduling like pulse.. (don't know about AudioFlinger)

Devuan Jessie beta released

Posted May 2, 2016 11:54 UTC (Mon) by johannbg (guest, #65743) [Link] (18 responses)

"SystemD will only start to get in your way when you want to do things like manage MythTV boxes'"

Fyi the most popular award winning linux based media center appliance [1] ( which is based on Kodi formerly known as XBMC ) is using systemd and systemd is not getting more in it's way than it's carrying 7 small patches [2], patches which may or may not be applicable upsteram ( Not sure how these things are commonly patch against in the embedded world ) against it.

Another thing worth mentioning regarding OpenELEC is that they successfully update their entire core/baseOS stack ( including the kernel ) with each new release which is more or less completely unheard of in embedded devices ( afaik ).

1. http://openelec.tv/
2. https://github.com/OpenELEC/OpenELEC.tv/tree/master/packa...

Devuan Jessie beta released

Posted May 2, 2016 19:04 UTC (Mon) by rahvin (guest, #16953) [Link] (17 responses)

Like any application running in user space MythTV has no requirement to run sysv init or any init for that matter. Instructions for integrating systemd with MythTV are available on the wiki, this integration is only necessary if you roll your own MythTV from git. If you use a distribution based MythTV the integration has probably already happened because the current version of Mythbuntu is already systemd based.

https://www.mythtv.org/wiki/Systemd_mythbackend_Configura...

Devuan Jessie beta released

Posted May 2, 2016 20:27 UTC (Mon) by johannbg (guest, #65743) [Link]

"Like any application running in user space MythTV has no requirement to run sysv init or any init for that matter."

That's how it works in the real world but apparently MythTV running on an systemd based system has devastating effects in the world linuxrocks123 lives in.

It so bad that systemd must be to blame for the pixelation and glitches in his or her recordings as well ;)

Devuan Jessie beta released

Posted May 2, 2016 23:26 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (15 responses)

Actually, that service file looks pretty cool. A lot less unwieldy than I would have suspected. I'd still prefer shell scripts, but it was good to look at that to see what one of those files looks like. Thanks for linking.

Devuan Jessie beta released

Posted May 3, 2016 10:29 UTC (Tue) by niner (guest, #26151) [Link] (14 responses)

"but it was good to look at that to see what one of those files looks like."

Yeah, it's quite common for systemd haters to not even have had a look at systemd. You're in good company, or company at least I guess.

Devuan Jessie beta released

Posted May 3, 2016 16:36 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link] (13 responses)

Oh I'd looked at it. I knew service files were a config file of some kind you had to create for every daemon you wanted to start, in place of shell scripts, and I knew that was a horrible idea and so didn't have reason to look at the exact syntax they decided to use. But, looking at that file, I see they used the Windows .ini format, which is a good config file format, and that they seem to have done an okay job creating readable and logically placed options. It was still a bad idea from the start, but at least they did an okay job implementing it. That's something at least.

I guess what I was expecting to see, given their general incompetence and aversion to Unix philosophy, was an XML monstrosity of some kind. I thought XML would have appealed strongly to Poettering, given that it's an over-engineered solution to a non-problem.

Devuan Jessie beta released

Posted May 3, 2016 16:51 UTC (Tue) by pizza (subscriber, #46) [Link]

> I knew service files were a config file of some kind you had to create for every daemon you wanted to start, in place of shell scripts, and I knew that was a horrible idea [...]

In other words, you didn't even attempt to understand what they were doing (or why) and pre-judged it solely on your preconceptions.

> I guess what I was expecting to see, given their general incompetence and aversion to Unix philosophy [...]

Aaaand there you go again.

Devuan Jessie beta released

Posted May 3, 2016 19:22 UTC (Tue) by farnz (subscriber, #17727) [Link] (11 responses)

Out of interest, why do you consider using a declarative configuration format worse than a Turing-complete programming language for a task that you want to complete in bounded time?

Devuan Jessie beta released

Posted May 3, 2016 20:13 UTC (Tue) by dlang (guest, #313) [Link] (10 responses)

because the declarative configuration still needs to be processed by a turing complete language, so your theoretical advantage of 'knowing' that it will complete in a bounded time doesn't really exist.

The post earlier about how there are now >100 tags that you can use, but many of them only work for specific modules is an example of why a declarative config format just doesn't work well in the real world. There is always going to be some case that you didn't think of when you designed your config. init scripts give you the ability to handle your special case in a way that makes sense to you without having to get a new option defined and propagated to the whole world.

Devuan Jessie beta released

Posted May 3, 2016 20:50 UTC (Tue) by farnz (subscriber, #17727) [Link]

I don't buy the "it still needs to be processed by a turing complete language" argument; that's basically saying that because systemd (the unit file interpreter) could be buggy, you can't reason about unit files. The same argument applies to any sort of restriction - when you allow the browser to interpret HTML for display, the "theoretical" advantage of doing so instead of running an arbitrary binary in supervisor mode doesn't really exist, because a bug in your processor could result in the browser's HTML parsing code being interpreted as instructions to wipe the disk.

And 100 directives isn't that large, compared to the set of bash built-ins, especially since not all directives can occur in all sections of a unit file - if this file does not have (for example) a [Mount] section, all the directives that only apply in the [Mount] section are errors; you thus only need to know about the directives that apply to each section. Plus, systemd provides the tooling you need to generate units from code at run-time, if you really the flexibility - but the fact that you're asking me to review a generator instead of a unit file tells me that you're writing a special case, and I ought to look in more depth at your code output.

Devuan Jessie beta released

Posted May 3, 2016 21:34 UTC (Tue) by anselm (subscriber, #2796) [Link] (4 responses)

There is always going to be some case that you didn't think of when you designed your config. init scripts give you the ability to handle your special case in a way that makes sense to you without having to get a new option defined and propagated to the whole world.

Which is presumably why systemd lets you use an init script in place of a unit file if you have to. You'll give up all sorts of other helpful systemd features that way, but if you're really keen on doing everything yourself anyway that shouldn't slow you down a lot. As a half-way solution, systemd service units do allow you to specify arbitrary shell commands to execute when a service is to be launched, and those should be able to let you do pretty much anything if you need to.

In actual practice, init scripts are usually 90% or more boilerplate and you pretty much have to compare them side by side to find if there are subtle differences between any two on your system. In spite of the fact that they're all largely identical they're still in separate files, though, so if you want to enable a feature like runtime monitoring of services or private /tmp directories you have to put it into every single init script by hand and carry those modifications yourself across updates of those init scripts. Having these features provided in one central place and accessible via a configuration switch is a lot more convenient and future-proof and the chances that any bugs will be found and stamped out are way higher if the code occurs in only one place instead of a few dozen.

Devuan Jessie beta released

Posted May 3, 2016 21:40 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

if you end up with a separate config file for each service, it's not really much better than a separate script file for each service. You still have to touch every file if you want to add something for every service.

I really don't like the "systemd provides a default file and your custom one gets merged with it" approach, I would much prefer a "the distro provides a default that you can replace" Figuring how the two will get merged, and what changes will be introduced with a new systemd version is much worse than getting flagged at upgrade time that there is a new version of the config that you have to look over and merge.

Devuan Jessie beta released

Posted May 3, 2016 21:49 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

>I really don't like the "systemd provides a default file and your custom one gets merged with it" approach, I would much prefer a "the distro provides a default that you can replace"

You must be aware that systemd allows for either?

Devuan Jessie beta released

Posted May 3, 2016 22:03 UTC (Tue) by anselm (subscriber, #2796) [Link]

if you end up with a separate config file for each service, it's not really much better than a separate script file for each service. You still have to touch every file if you want to add something for every service.

It is if your configuration file is only a dozen lines long in a very simple and robust format, as opposed to a few screenfuls of arbitrary shell script. It would be reasonable to use a script to add a directive to, say, every “[Service]” section of a selection of systemd unit files, but you wouldn't really want to do that to a bunch of init scripts.

I really don't like the "systemd provides a default file and your custom one gets merged with it" approach, I would much prefer a "the distro provides a default that you can replace"

You're perfectly free to do that with systemd, too. Which approach you take would depend on the nature and the size of the changes that you want to make.

Devuan Jessie beta released

Posted May 14, 2016 11:21 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> if you end up with a separate config file for each service, it's not really much better than a separate script file for each service. You still have to touch every file if you want to add something for every service.
And how is that different from what you'd have to do with init scripts? Oh, I know: with a declarative file format it's trivial to automate.

Devuan Jessie beta released

Posted May 14, 2016 11:15 UTC (Sat) by HelloWorld (guest, #56129) [Link] (3 responses)

> because the declarative configuration still needs to be processed by a turing complete language, so your theoretical advantage of 'knowing' that it will complete in a bounded time doesn't really exist.
This sort of non-sequitur really says more about you than about systemd.

Devuan Jessie beta released

Posted May 18, 2016 21:54 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Is anyone really worried about infloops from init scripts trying to exhaustively prove the infinitude of the primes in any case? Not even Red Hat's pre-systemd init scripts went quite that far.

I can understand why being paranoid about infloops in things like systemtap scripts makes some sense, but in init scripts? Seriously, I have at least one intentional one (it avoids kicking off the watchdog before all the things it should be monitoring have started properly -- the sort of thing that systemd could do without effort, of course...)

Devuan Jessie beta released

Posted May 18, 2016 22:10 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Is anyone really worried about infloops from init scripts trying to exhaustively prove the infinitude of the primes in any case? Not even Red Hat's pre-systemd init scripts went quite that far.
You think so?

Try this one: http://anonscm.debian.org/cgit/users/lamont/bind9.git/tre... - see line 92. Granted, that's Debian not RedHat.

Devuan Jessie beta released

Posted May 19, 2016 7:20 UTC (Thu) by farnz (subscriber, #17727) [Link]

Yes, because I caught at least two when I translated an employer's sysvinit scripts to systemd units. In both cases, we'd seen the hang in about 1% of boots, but couldn't diagnose.

Devuan Jessie beta released

Posted May 2, 2016 12:22 UTC (Mon) by anselm (subscriber, #2796) [Link]

I don't know what percentage of Linux users will ultimately end up using SystemD in the short term. Rattling off names of distributions isn't an argument; the usage share of Linux distros is and always has been very fluid. What I do know is that there are enough distros keeping the flame alive that, when newbie but enthusiastic hobbyists find SystemD getting in their way, and they will, they'll find the threads comprising "World War SystemD" on the Internet when looking for a solution, and undo the damage by uninstalling SystemD.

I think that on the whole, people are happy with the default init system in their distribution. In most mainstream Linux distributions, systemd has by now had a few years to mature, and the fact of the matter is that it actually works in the vast majority of use cases.

Which is not to say that people won't ever run into corner cases that are problematic. But people have been running into problematic corner cases before, even on the traditional setup. Systemd's advantage here is that it is a much more coherent system with fewer gratuitous inconsistencies, and that its documentation is quite good (especially compared to the traditional setup). Also, the debugging tools that systemd provides to sort out such problems are really not bad at all. Chances are that people will first try to get their issues fixed within systemd on whichever distribution they're using, rather than install a different init system or Linux distribution (which may come with its own share of problems), and the more systemd is being used, the more resources will be available to help them out.

You're all excited about SystemD's market share, but that's not what matters. The only people who matter to those who want to use Linux are those who contribute to Linux.

Yep. For most users this will in the first instance include those people who contribute to the mainstream Linux distributions they're using, virtually all of which are based on systemd now – and for good and sensible reasons.

Devuan Jessie beta released

Posted May 2, 2016 10:37 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (2 responses)

One other thing: out of curiosity, what phone are you using that uses SystemD as its init, and did it come that way, or did you put it there yourself?

Devuan Jessie beta released

Posted May 2, 2016 12:04 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

Jolla phone running Sailfish OS. Comes with systemd as its native PID 1. While it could be improved in various places (nothing to do with the init system) I like it better than the Android phone I used to have. Apart from not being beholden to Apple or Google, the nice thing about it is that it has a reasonable Linux userland and is amenable to ssh'ing in and hacking in Python. Oh, and it runs for days without recharging ;^)

Devuan Jessie beta released

Posted May 2, 2016 23:29 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link]

Days??? Impressive! I'm lucky if I get one day out of my Android phone.

You can get Python on Android if you want, though: https://play.google.com/store/apps/details?id=com.hipipal...

Devuan Jessie beta released

Posted May 12, 2016 16:05 UTC (Thu) by Nikratio (subscriber, #71966) [Link] (3 responses)

> How many devs do you think Devuan has? I have no idea, but I doubt many. It doesn't strike me as a
> big project. But they won't need many, because they have a good, intelligent plan to leverage as
> much of Debian as possible, continuously, and they have the skills to implement that plan.

A good, intelligent plan would be to work inside Debian as much as possible, and to offer a repository with just the packages for which the desired changes are not accepted into Debian proper. A less intelligent, but still reasonable plan would have been to also include packages that have not been modified, but that have been rebuild without libsystemd.

The least intelligent plan was to fork the entire distribution.

Devuan Jessie beta released

Posted May 12, 2016 19:20 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (2 responses)

Actually, contrary to what is widely said, Devuan does not appear to have fully forked Debian. Their repository software (Amprolla - https://git.devuan.org/devuan-infrastructure/amprolla) seems to provide mainly debian's .debs, with some strategic packages replaced by devuan versions. So it's more like an overlay than full fork, close to what you have called ”intelligent plan”.

Unfortunately devuan's -devel list (https://lists.dyne.org/lurker/list/dng.en.html) is quite light on technical details.

Devuan Jessie beta released

Posted May 12, 2016 23:53 UTC (Thu) by Nikratio (subscriber, #71966) [Link] (1 responses)

> Actually, contrary to what is widely said, Devuan does not appear to have fully forked Debian.
> Their repository software (Amprolla - https://git.devuan.org/devuan-infrastructure/amprolla)
> seems to provide mainly debian's .debs, with some strategic packages replaced by devuan
> versions. So it's more like an overlay than full fork, close to what you have called ”intelligent plan”.

Devuan explicitly says that its repositiories are *not* to be used in addition to the Debian ones, so they are not providing an overlay. The fact that most of the packages are unchanged doesn't change that, but it does make the whole endeavour rather questionable.

If they had actually changed a significant number of packages, providing their own full repository would have made sense. But setting up infrastructure for thousands of packages when you actually only need to touch tens looks like an utter waste of time and money to me.

Devuan Jessie beta released

Posted May 15, 2016 20:08 UTC (Sun) by anselm (subscriber, #2796) [Link]

If they had actually changed a significant number of packages, providing their own full repository would have made sense. But setting up infrastructure for thousands of packages when you actually only need to touch tens looks like an utter waste of time and money to me.

But … but … but they're the Veteran Unix Admins! They're supposed to be better at this than anyone else!

Seriously, it's probably a PR thing. “We have forked Debian” sounds a lot more macho than “We have forked a bunch of Debian packages that looked as if they'd need systemd”. I agree that working within Debian to ensure sysvinit support and providing their own repository for packages that the relevant Debian maintainers didn't want (for whatever credible reason) would have been the more productive approach overall – but of course if you believe systemd is basically the essence of evil, then the Debian project, by virtue of simply allowing it into the distribution (let alone allowing it to become the default init system) has become corrupted beyond repair, a traitor to the One True Unix, and maintaining your “own” distribution, even if most of it actually tracks Debian, can start looking like the only viable option.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds