Devuan Jessie beta released [LWN.net]

does anybody else find it ironic...

Posted Apr 30, 2016 15:02 UTC (Sat) by HelloWorld (guest, #56129) [Link] (2 responses)

... that two of the board members seem to be somehow associated to a computer museum?

does anybody else find it ironic...

Posted Apr 30, 2016 15:48 UTC (Sat) by fratti (guest, #105722) [Link]

Says a lot about sysvinit, doesn't it?

does anybody else find it ironic...

Posted Apr 30, 2016 16:49 UTC (Sat) by andreasn1 (guest, #88420) [Link]

That struck me as a particular detail as well.
A third is part of "European Society for Computer Preservation".

Very weird move to write out those titles in the press release. Their names would have been enough possibly. (unless this all is a really long, far fetched, prank).

Devuan Jessie beta released

Posted Apr 30, 2016 15:15 UTC (Sat) by itvirta (guest, #49997) [Link] (19 responses)

> Init Freedom Lovers... the Veteran Unix Admins salute you... declaration of Exodus

Whoa. Just whoa.

Devuan Jessie beta released

Posted Apr 30, 2016 15:41 UTC (Sat) by pizza (subscriber, #46) [Link] (16 responses)

>> Init Freedom Lovers... the Veteran Unix Admins salute you... declaration of Exodus
> Whoa. Just whoa.

Yeah, I find it ironic that they're celebrating Freedom by actually stripping away choices.

Still credit must be given where it's due; I never expected them to hold things long enough to get to a beta-quality release.

Devuan Jessie beta released

Posted Apr 30, 2016 18:09 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> Still credit must be given where it's due; I never expected them to hold things long enough to get to a beta-quality release.
A beta version is a beta version because somebody declared it to be, not because it reached some objectively-defined state of maturity.

Devuan Jessie beta released

Posted Apr 30, 2016 20:21 UTC (Sat) by freebird (guest, #43129) [Link]

> Yeah, I find it ironic that they're celebrating Freedom by actually stripping away choices.

They are celebrating freedom by creating the distro they want.

What choices are they stripping away? You still have debian if you want it.

Devuan Jessie beta released

Posted Apr 30, 2016 20:53 UTC (Sat) by ballombe (subscriber, #9523) [Link] (13 responses)

> Yeah, I find it ironic that they're celebrating Freedom by actually stripping away choices.

You can still use regular Debian so actually they are providing more choice.
It is just too bad m68k is not supported yet.

Devuan Jessie beta released

Posted Apr 30, 2016 21:53 UTC (Sat) by pizza (subscriber, #46) [Link] (12 responses)

> You can still use regular Debian so actually they are providing more choice.

Yeah, they're providing a choice that's already offered by stock Debian.

The amount of work they undertook by forking an entire distro to avoid polluting the filesystem with 'libsystemd.so' would have been far more productively spent working with various upstreams to help maintain (and/or fix) their non-systemd code paths to provide viable alternatives to the functionality that systemd enables.

But it's their time.... far be it for me to tell someone else what they should or shouldn't do with it.

Devuan Jessie beta released

Posted Apr 30, 2016 22:17 UTC (Sat) by anselm (subscriber, #2796) [Link] (11 responses)

The problem with staying inside Debian is that there is a vast conspiracy of people – led by Lennart Poettering and his minions the Debian systemd maintainers – who are using systemd to make Debian into Fedora, or Windows (it isn't entirely clear which but that doesn't matter). Right now the conspiracy tries to deceive people into believing that System-V init is still a supported option in Debian, but in reality they are secretly working behind the scenes to have it abolished completely.

Everybody knows that Debian is, by design, susceptible to all sorts of cabals and schemery, for example when the perfectly viable a.out binary format was replaced, in one fell swoop, by the newfangled ELF format. Therefore it is clear the Devuan crowd can't rely on Debian supporting System-V init; they need to replicate the entire distribution in order to be sure that the systemd cancer is excised by the root.

Devuan Jessie beta released

Posted Apr 30, 2016 23:00 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link] (9 responses)

> Everybody knows that Debian is, by design, susceptible to all sorts of cabals and schemery, for example when the perfectly viable a.out binary format was replaced, in one fell swoop, by the newfangled ELF format.

Unlike with SystemD, there were actually very good reasons to replace a.out. There were severe issues with shared libraries; most importantly, there needed to be a centralized registry maintained on the Internet listing the virtual memory locations of every shared library, to make sure they didn't conflict.

I can't tell if you're joking (Poe's Law), and I wasn't using Linux when the transition happened in ... *Googles* ... 1995 ... so I can't comment on whether Debian handled the transition well, but a.out definitely had to go.

Also, lol Yggdrasil: http://www.linuxjournal.com/article/80

Devuan Jessie beta released

Posted May 1, 2016 9:44 UTC (Sun) by hummassa (guest, #307) [Link] (4 responses)

> I can't tell if you're joking (Poe's Law),

the "Debian is, by design, susceptible to all sorts of cabals and schemery" part makes me think it's a joke (even if the author is not joking) :D

Devuan Jessie beta released

Posted May 1, 2016 15:53 UTC (Sun) by edmonds42 (guest, #42670) [Link] (3 responses)

I guess it makes slightly more sense if you read "cabal" as "group of people" and "conspiracy" as "group of people doing things together".

Devuan Jessie beta released

Posted May 2, 2016 7:08 UTC (Mon) by ncm (guest, #165) [Link] (2 responses)

Strictly speaking, it's only a conspiracy if a law is or would be broken. No law, no conspiracy. The worst we could have here is colluding. ("Conspire": breathe together; "collude": play together; "cooperate": work together.)

Devuan Jessie beta released

Posted May 2, 2016 16:36 UTC (Mon) by drag (guest, #31333) [Link] (1 responses)

> Strictly speaking, it's only a conspiracy if a law is or would be broken.

I don't think that anybody is claiming that Debian should seek to criminally prosecute the 'systemd cabal' for conspiracy. Using the term can imply attempts to break the law, but it can just as easily be used to describe any group of people acting in secret for evil or immoral reasons. So strictly speaking usage of the term in this context is fine.

To argue against the 'secret conspiracy of Lennart's cohorts' you can choose to claim that there is no secret agreements to undermine non-systemd Debian OR that working together in secret to promote systemd is not malicious, evil, or immoral.

Personally I feel there is no secret conspiracy. Lennart and 'friends of systemd' do work to promote their software, but it's no secret. Anybody who puts this much effort into some undertaking with the hopes of wide-spread adoption is going to work to promote their software if they have any brains at all.

And I don't think it's malicious or evil. Systemd is simply a massive improvement over sysvinit and upstart. There are certainly other ways to accomplish things, but so far nothing has gained traction. A person may disagree with systemd and dislike it, but to argue that a 'systemd cabal' is evilly working to destroy Linux puts you square in the loony-toons camp of 'people who cannot think clearly'.

My opinion is that if people are really concerned about systemd they will find that a much more constructive approach is to work with systemd to establish a standardized API to create a strong division between 'Linux Plumbing' from the rest of the OS. I have a feeling that the biggest problem in the future will be that Systemd project implemented the DBUS apis in a way that that is specific to a particular systemd _implementation_. I don't think that Systemd project is really capable of policing themselves to avoid leaking implementation details into the upper layers. It is not that they are a stupid, but it's a issue of being too close to the project and 'not seeing the forest for all the trees'. So people interested in having the possibility of having systemd alternatives or being able to migrate away from systemd in the future should work to help ensure that APIs are clean and can be implemented by other projects.

Devuan Jessie beta released

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

> It is not that they are stupid, but it's a issue of being too close to the project and 'not seeing the forest for all the trees'.

It's not that either... Basically, you can't ever be sure about how well your API is designed until you have multiple independent implementations of that functionality. That's when you find out if your assumptions are different and what sort "unintentional features" your spec allows for.

> So people interested in having the possibility of having systemd alternatives or being able to migrate away from systemd in the future should work to help ensure that APIs are clean and can be implemented by other projects.

I completely agree, and systemd (the project) has shown it's quite willing to work towards those goals -- But in order to work towards those goals, one has to at least accept the validity of the problems systemd is attempting to tackle. That seems to be where things are (loudly) breaking down.

Devuan Jessie beta released

Posted May 3, 2016 12:15 UTC (Tue) by jubal (subscriber, #67202) [Link] (3 responses)

I can't tell if you're joking (Poe's Law)

Debian being managed by a secret cabal or a whole conspiracy of cabals is sort of a running joke within the project. As we all know, there is no cabal.

Devuan Jessie beta released

Posted May 5, 2016 15:33 UTC (Thu) by stevem (subscriber, #1512) [Link] (2 responses)

There isn't a cabal. There are many cabals. :-)

Devuan Jessie beta released

Posted May 6, 2016 15:47 UTC (Fri) by ghane (guest, #1805) [Link] (1 responses)

> There isn't a cabal. There are many cabals. :-)

Yes, but they are all fronts for the One True Cabal.

Devuan Jessie beta released

Posted May 10, 2016 21:54 UTC (Tue) by nix (subscriber, #2304) [Link]

And that, of course, is here: <https://www.haskell.org/cabal/>.

Devuan Jessie beta released

Posted May 4, 2016 9:11 UTC (Wed) by nix (subscriber, #2304) [Link]

An excellently done work of sarcasm, sir, with the problems with this position superbly stated by the wonderful second paragraph: I salute you.

(And before anyone says that ELF is perfect, unlike the devil systemd, well, um, it really isn't.)

Devuan Jessie beta released

Posted May 1, 2016 15:30 UTC (Sun) by aaron (guest, #282) [Link] (1 responses)

>> Init Freedom Lovers... the Veteran Unix Admins salute you... declaration of Exodus
> Whoa. Just whoa.

Clearly, humorous bombast doesn't fly in these days of Very Serious bombast.

Devuan Jessie beta released

Posted May 1, 2016 20:00 UTC (Sun) by itvirta (guest, #49997) [Link]

Humour is fine. Let's just say that there exists a sort of thin red line separating funny but sane humour from rhetoric that is completely out of this world.

Devuan Jessie beta released

Posted Apr 30, 2016 16:38 UTC (Sat) by flussence (guest, #85566) [Link] (90 responses)

I find it simultaneously funny and sad how much effort has been burned here for the sake of avoiding *learning* *anything*, be it an enterprise system plumbing framework or a new old distro that allows choice.

Well, I wish them the best of luck, and hope they get their mileage out of the serial port UPS support in PID1 they're working so hard to preserve.

Devuan Jessie beta released

Posted Apr 30, 2016 19:40 UTC (Sat) by mgb (guest, #3226) [Link] (64 responses)

Until something better comes along, sysvinit is preferred by those of us who learned from the mistakes of the last half century of software engineering. We are fortunate in a Devuan and other newer distros to have that choice.

"I think some of the design details are insane" [Linus Torvalds]

More I cannot say here as criticism of systemd from lesser lights than Linus is not permitted by Jon.

Devuan Jessie beta released

Posted Apr 30, 2016 19:50 UTC (Sat) by DOT (subscriber, #58786) [Link]

"but those are details, not big issues."

Devuan Jessie beta released

Posted Apr 30, 2016 20:54 UTC (Sat) by flussence (guest, #85566) [Link] (14 responses)

> Until something better comes along, sysvinit is preferred by those of us who learned from the mistakes of the last half century of software engineering.

How about runit, s6, finit, initng, einit, busybox init, or a 10 line C loop? There are a million better alternatives to System V's crusty old /sbin/init and /etc/inittab.

(I sure hope you're not saying they wasted two years of effort because they're too ignorant to tell the difference between init and rc!)

Devuan Jessie beta released

Posted Apr 30, 2016 21:40 UTC (Sat) by anselm (subscriber, #2796) [Link] (13 responses)

Devuan is unique among Linux distributions in that it defines itself primarily by what it doesn't contain.

System-V init was just as much of a “mistake” in the 1980s as systemd is today. Exactly the same sort of people condemned it at the time as overengineered, error-prone and generally unnecessary. It's just that if you've been brought up on the thing you won't necessarily notice this, and yesterday's obvious mistake becomes today's revered tradition. Which isn't always bad – there are loads of mistakes in Unix/Linux that we have learned to live with – but shouldn't preclude the adoption of new, better solutions, especially if the problem space has changed (as it has in the case of 2010s Linux vs. 1980s Unix).

Devuan Jessie beta released

Posted May 1, 2016 1:22 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

Devuan is unique among Linux distributions in that it defines itself primarily by what it doesn't contain.

That's not really true. There are also distributions that define themselves in terms of eliminating all non-free software, including things like firmware blobs. That seems like defining themselves in terms of what they leave out.

Devuan Jessie beta released

Posted May 1, 2016 3:35 UTC (Sun) by sfeam (subscriber, #2841) [Link]

Not to mention the various tiny/damn-small/nano/reduction-of-your-choice linux variants that are designed to leave out as many things as possible while still fulfilling a target niche.

Devuan Jessie beta released

Posted May 1, 2016 12:55 UTC (Sun) by ksandstr (guest, #60862) [Link] (10 responses)

>System-V init was just as much of a “mistake” in the 1980s as systemd is today. Exactly the same sort of people condemned it at the time as overengineered, error-prone and generally unnecessary. It's just that if you've been brought up on the thing you won't necessarily notice this, and yesterday's obvious mistake becomes today's revered tradition.

This implies that systemd is being opposed for not being sysvinit. Nothing could be further from the truth -- it's rather that systemd is so bad, by for example causing things to break and otherwise become worse than before systemd, that it is worse than sysvinit. Regardless of how one rates sysvinit, systemd is worse: things worked before systemd, after systemd they do not.

But as propaganda pieces go it's nearly impeccable. "The same sort of people", indeed. Let's forget the technological details in favour of equivocating not generations-apart instances of overengineering itself, or even claims thereof, but the pundit's stereotype of his opponents! If this is the best-of-breed systemd advocacy, then it must be teetering on its foundation.

Devuan Jessie beta released

Posted May 1, 2016 13:52 UTC (Sun) by anselm (subscriber, #2796) [Link] (9 responses)

This implies that systemd is being opposed for not being sysvinit.

There's nothing wrong with System-V init. It was a great idea in its time, which was the 1980s, and was a huge improvement on what came before. The issue with System-V init today is that it is now 30+ years old, and during these three decades the problem it was designed to solve has changed considerably. System-V init has patently failed to evolve to address these changes in the problem space, and is therefore ripe for replacement by something that was written to work well in the 2010s (and hopefully beyond). By broad consensus this seems to be systemd.

Regardless of how one rates sysvinit, systemd is worse: things worked before systemd, after systemd they do not.

I don't think this is in fact as black and white as you make it out to be. Lots of things work better now than they used to. (Remember how people used to have to put random “sleep” commands into their init scripts to mitigate race conditions, which are now being solved by actual infrastructure.) Things that actually don't work tend to get fixed as bugs. After a number of years of bugfixing there are in fact very few things left that used to work before but now don't, while there are many things that work more consistently or are in fact convenient to do when, before, they were a huge hassle to implement.

This is on top of a number of other advantages of systemd, including (but not limited to):

The various components of systemd actually follow a common design, unlike the traditional setup (System-V init and init scripts, inetd, cron, …), which was assembled out of random pieces from a variety of unrelated sources with no overarching idea of a cohesive design.
Systemd has done a lot to unify “basic plumbing” between Linux distributions, leaving distributions' maintainers free to concentrate on other areas that provide value to users, and making it easier for upstream developers to include systemd configuration files that are more likely to work across a large variety of Linux distributions, thereby reducing distribution maintainers' work even further.
All systemd configuration files “smell” the same, while in the traditional setup no two configuration files have the same format (/etc/inittab vs. /etc/fstab vs. /etc/inetd.conf vs. /etc/crontab vs. …). This is on top of init scripts being essentially free-form shell scripts that consist of 90% boilerplate but are still specific to individual Linux distributions. This makes systemd-based Linux systems a lot easier to learn, teach, understand, maintain, and customise than Linux systems following the traditional approach. (I used to make a living teaching people Linux system administration, and believe me I never met anyone in my classes who didn't like the idea of making Linux system administration easier to learn and understand.)
Continuing from the previous point, all the various components of the traditional setup use different ways of starting processes (e.g., init vs. init scripts vs. cron vs. at vs. inetd). These subprocesses can have wildly different setups (environment, working directory, capabilities, I/O setup, …) depending on which service started them, and a system administrator must be aware of these differences and take them into account when configuring, e.g., cron jobs vs. at jobs. With systemd, the same mechanism is used in every case, which not only makes a subprocess's environment, resource limits, security attributes, … more straightforward to configure but also leads to less code to debug and hence fewer bugs.
Systemd removes the necessity for system services started from init scripts to go through an elaborate song-and-dance routine in order to dissociate themselves from the script that started them and be adopted by the init process. In fact, systemd has a much clearer picture of which services are running and which aren't and is able to restart services that fail, which is something that System-V init ignores completely – a system administrator has to add their own infrastructure, not usually provided by default by Linux distributions, simply to ensure that a service once started by System-V init actually remains up and running.
Systemd is designed to make systems more maintainable by enforcing a clear separation between configuration provided by the distribution and configuration provided by the local administrator. This makes it a lot easier to identify what was in fact changed locally, and to carry local setup across distribution upgrades. The traditional setup has nothing to offer in this regard. For example, if you want to change the way your system starts a service like Apache, then in the traditional setup you are reduced to figuring out the (distribution-specific) Apache init script and customising it to suit your requirements by hacking shell code, even for basically very simple things like running several independent copies of Apache on the same system. These customisations must then be carefully preserved against the case that the distribution ever decides to upgrade Apache (and its init script) because there is only one place on the system where init scripts can go and it belongs to the distribution.

In general, the tradeoff between the traditional setup and systemd tends to come out in systemd's favour, which is the reason why so many distributions decided to base themselves on systemd rather than the traditional setup (they didn't do it because they love Lennart Poettering so much or because Red Hat was bribing them, after all – they did it because they evaluated systemd and liked what they saw). It is of course possible to deny all of this, but doing so is likely to make the deniers look progressively more ridiculous as time marches on.

Devuan Jessie beta released

Posted May 1, 2016 17:08 UTC (Sun) by darwish (guest, #102479) [Link]

Not to mention how KDE and gnome adopted systemd session management and user session bootup (soon), etc.. not because of any "conspiracy" of course, but rather .. guess what, the actual developers who do the actual work find it termendously useful:

http://blog.davidedmundson.co.uk/blog/systemd-and-plasma
https://blog.martin-graesslin.com/blog/2014/10/libinput-i...

Or that we can now run Xorg and other daemons without roout access, thanks to systemd-logind session management:

https://dvdhrm.wordpress.com/2013/08/24/how-vt-switching-...

Or how the Arch Linux developers chose to migrate to it, back in 2012, for very concrete reasons:

https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Or how that finally, after a very long time, the Linux userspace is gaining funding and care by the same companies who contribute to the kernel .. why? Because the "bag of bits" approach, the old-school admins so fond of, does not work in the new world of vertically integrated stacks and containerization (that is, iOS and Android .. by far now the most used computing platform out of the server domain) ..

But the anti- systemd community has just been defind by its "NO" stance.. no to any change or progress.. But progress is always better than standing still, even if we're "progressing" into wrong directions at times ..

Devuan Jessie beta released

Posted May 3, 2016 7:36 UTC (Tue) by alankila (guest, #47141) [Link] (5 responses)

The only real issue I have with systemd is that unit files have become horribly complicated. I would like them to have approximately 10 different directives, max, as opposed to the approximately 100 seen here: https://www.freedesktop.org/software/systemd/man/systemd....

I have a persistent feeling that forking a daemon and keeping it running isn't so complicated that it should need all that flexibility, and I will probably never personally learn except the most minimal set of directives -- just enough to get something up and then to keep it running until I tell it to stop.

Devuan Jessie beta released

Posted May 3, 2016 8:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Perhaps systemd can switch to something like (but not necessarily) JSON for more hierarchical configuration. Additionally, it'd be useful to have a more powerful template engine for command snippets.

But these features can be added backwards-compatibly later, perhaps in a couple of years if the number of options becomes too large.

Devuan Jessie beta released

Posted May 6, 2016 18:29 UTC (Fri) by imMute (guest, #96323) [Link]

You can do this *today*. All you have to do is write a systemd-generator (https://www.freedesktop.org/wiki/Software/systemd/Generat...) that parses your JSON configuration schema.

This is how systemd handles "legacy" configuration files like /etc/fstab (https://www.freedesktop.org/software/systemd/man/systemd-...) and /etc/init.d/ sysv scripts (https://www.freedesktop.org/software/systemd/man/systemd-...).

Devuan Jessie beta released

Posted May 3, 2016 10:06 UTC (Tue) by anselm (subscriber, #2796) [Link] (2 responses)

That list looks more intimidating than it actually should because very many directives are specific to particular types of unit. There is a certain number of directives that potentially apply to all units but the various unit types have their own sets of directives which makes things slightly more logical. Also, some of the directives cover fairly obscure use cases.

Devuan Jessie beta released

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

Well, TBH, hierarchical keyword names might not be bad at that point.

Devuan Jessie beta released

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

Systemd effectively has this to a degree because of the structure of unit files, which are split into “sections” each of which can only contain a certain (limited) set of directives. For example, here's /lib/systemd/system/ssh.service from my system:

[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify

[Install]
WantedBy=multi-user.target
Alias=sshd.service

All units can have the Unit and Install sections, which essentially describe the unit itself (including dependendices and conditions under which it should be considered) and how it is to be installed, respectively. The Service section is specific to services and describes how a background service is supposed to be run. (Socket units, for example, would instead include a Socket section containing directives that talk about communication channels.)

One advantage of this scheme is that it is easy to override individual directives by creating a file under (for example) /etc/systemd/system/ssh.service.d/override.conf that contains just the directives one would like changed, as in

[Unit]
Description=A silly example of overriding a directive

Systemd knows how to piece together the “effective” unit file from the basic version in /lib and any overrides in /etc, and that helps in future-proofing local changes because they are cleanly separated from the default configuration provided by the distribution. (It also includes tools that let you look at the “effective” unit file and how it is assembled.) In my opinion this is a big improvement on the “my way or the highway” approach taken by System-V init's init scripts.

Devuan Jessie beta released

Posted May 3, 2016 21:08 UTC (Tue) by flussence (guest, #85566) [Link] (1 responses)

> All systemd configuration files “smell” the same, while in the traditional setup no two configuration files have the same format (/etc/inittab vs. /etc/fstab vs. /etc/inetd.conf vs. /etc/crontab vs. …). This is on top of init scripts being essentially free-form shell scripts that consist of 90% boilerplate but are still specific to individual Linux distributions. This makes systemd-based Linux systems a lot easier to learn, teach, understand, maintain, and customise than Linux systems following the traditional approach.

I prefer the “different things should look different” approach. Killing off LSB's awful rc script “standard” is a positive change I won't argue with, but there was nothing wrong with the tabular declarative config files elsewhere — the only thing that's been achieved there is making /etc/ smell like a COBOL peg hammered into a .ini hole.

Devuan Jessie beta released

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

I prefer the “different things should look different” approach.

Different types of systemd unit files do look different, to a certain degree, because they support different sections with different directives. There is still an advantage in using the same underlying syntax and semantics since that means the overall cognitive load is less. You only need to learn it once and then you can use it everywhere. (This is basically why general-purpose programming languages such as Python are popular.)

In addition, much of what the traditional configuration files – /etc/inittab, init scripts, /etc/inetd.conf, /etc/crontab and so on – describe isn't really that different, from one file to the next. At the end of the day they are all about starting subprocesses. There is no particular reason why there should be eleven different ways of specifying how a subprocess is to be started, but even so /etc/inittab lets you restart a service if it crashes but init scripts don't. /etc/crontab lets you specify environment variables for services but /etc/inetd.conf doesn't. And so on.

Devuan Jessie beta released

Posted Apr 30, 2016 21:36 UTC (Sat) by HelloWorld (guest, #56129) [Link] (39 responses)

> Until something better comes along, sysvinit is preferred by those of us who learned from the mistakes of the last half century of software engineering.
Haha, good one. Sticking with sysvinit at this point is the *epitome* of refusing to learn from the last 20 years of Unix history.

Devuan Jessie beta released

Posted May 1, 2016 13:43 UTC (Sun) by ksandstr (guest, #60862) [Link] (38 responses)

>Sticking with sysvinit at this point is the *epitome* of refusing to learn from the last 20 years of Unix history.

And what has the systemd project done that benefits from these "last 20 years of Unix history"?

To wit, what failing of sysvinit does, say, systemd's "journal" feature repair? Besides not having corporate-sexy database terminology plastered over a NIH-tastic Java-in-C redoing of worse syslog.

Or for an alternative, what bug, insufficiency, or absence does its "transactional dependency resolver" fix? Aside from the "transactional" characterization, i.e. being built out of a sequence of operations, which the rest of us would call "ordinary software design" rather than some poor coöptation of database terminology.

Yet for a different kind of option, what new features has systemd introduced over the "old and busted" sysvinit? For example the perennially-cited concurrent booting had been solved since insserv's publication in 2000, and features such as waiting until the network is up to mount dependent filesystems were implemented using insserv's features in a manner very similar to what systemd does. Similarly, not launching servers until first TCP connection is a worse re-doing of demand paging because it increases the latency of first response by the time spent in server initialization, and because it adds a heap of userspace code and a mafialike dependency for a half-arsed[0] feature that's been both unnecessary and undesirable since computers started having over 4M of RAM[1].

Certainly it seems that it's systemd's advocates who're ignoring history!

[0] systemd's deferred launching only does the loading half of demand paging; it doesn't shut services down to relieve memory pressure.
[1] which is about the time when we stopped using inetd for mostly that exact reason.

Devuan Jessie beta released

Posted May 1, 2016 14:22 UTC (Sun) by anselm (subscriber, #2796) [Link] (15 responses)

And what has the systemd project done that benefits from these "last 20 years of Unix history"?

What about being able to keep track of a running system service and restarting it when it fails? What about being able to stop all processes belonging to a running service, without explicit help from that service? What about separating distribution-provided configuration from that provided by a local administrator? What about conveniently providing more than four “runlevels”? What about getting, say, the Bluetooth stack launched automatically when a Bluetooth USB dongle is plugged in (rather than on boot, on the off-chance)? What about making it easy to run system services with resource limits or special security attributes? What about providing an infrastructure that easily integrates “containers”? What about doing all of the above in a single, consistent, unified package rather than a number of separate pieces that only work together in limited ways? And so on.

You can argue that it is possible to find (or write) software that does much of this under the auspices of the traditional setup. But it seems that nobody so far has condescended to actually do this in a mainstream Linux distribution. Where is the Linux distribution that lets you specify, out of the box and in a way that automatically persists across package updates, that your Apache processes should not consume more than x% of available memory, or y% of CPU time? Where is the Linux distribution that will, out of the box, restart Apache if it crashes? Being told that you just need to add a few commands to an init script and remember to repeat that whenever an update comes out is kinda lame when with systemd these are basically one-liners in a completely separate configuration file that an upgrade won't touch, and don't require additional software to be installed and configured.

:applause emoji:

Posted May 1, 2016 15:43 UTC (Sun) by louie (guest, #3285) [Link]

👏

Thanks for being a voice of reason here, anselm.

Devuan Jessie beta released

Posted May 1, 2016 19:04 UTC (Sun) by Zack (guest, #37335) [Link] (11 responses)

> What about being able to keep track of a running system service and restarting it when it fails?
> What about being able to stop all processes belonging to a running service, without explicit help from that service?

Those are functionalities provided by cgroups. cgroups was a hot mess that every serious kernel hacker had hoped people would forget about. Until someone sauntered by and thought "This looks awesome! Let's base an important part of infrastructure on this piece of spaghetti for nebulous gains! What could possibly go wrong?"

> What about separating distribution-provided configuration from that provided by a local administrator?

What about separating distribution-provided configuration from that provided by a local administrator in a clear and well known format that everyone is familiar with?

> What about conveniently providing more than four “runlevels”?

So after settling on four runlevels because generally people didn't need more, now it's convenient to have more of them again?

> What about getting, say, the Bluetooth stack launched automatically when a Bluetooth USB dongle is plugged in?

What about having it already running on a machine that has Bluetooth, and not having it at all on a machine without it? That would avoid a lot of complexity, crashy and buggy complexity.

> What about providing an infrastructure that easily integrates “containers”?

Easily as long as someone somewhere agrees with you.
https://lwn.net/Articles/676831/

> What about doing all of the above in a single, consistent, unified package rather than a number of separate pieces that only work together in limited ways?

"a number of separate pieces that only work together in limited ways?" That's a nice way to summarise Software Engineering 101. If only some people would paid more attention to it in class instead of writing unspecced evergrowing solutions in search of a problem.

Devuan Jessie beta released

Posted May 1, 2016 19:33 UTC (Sun) by pizza (subscriber, #46) [Link]

> If only some people would paid more attention to it in class instead of writing unspecced evergrowing solutions in search of a problem.

FYI. Just because you don't have a particular problem or set of problems, don't assume that those problems don't exist or that nobody else suffers from them.

Also, if you're going to try and drag "software engineering 101" into this, I suggest you apply those same standards to the [thankfully rapidly-becoming-] former status quo.

Devuan Jessie beta released

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

anselm provided concrete systemd features that I've personally seen used everyday on production server _and_ embedded systems. And now what was your reply? Striking all of these features down just because they were done using a kernel feature that is not to your liking? And what to do you really propose in place? I guess you'll need to study Neil Brown's series on cgroups here first: https://lwn.net/Articles/604609/

> "a number of separate pieces that only work together in limited ways?" That's a nice way to summarise Software Engineering 101. If only some people would paid more attention to it in class instead of writing unspecced evergrowing solutions in search of a problem.

A number of separate pieces that communicate by text over dumb pipes does not handle the computing challenge of this day and age.. This method has its uses (e.g. quick scriping, tinkering, & administration), sure, but please let go of the 1970s lingua franca of marketing this design pattern as the only solution to all the problems of computing .. Have you looked at GNU autotools 10K+ scripts? They are damn ugly and untracable ..

And no, no .. software engineering classes are not taught with this "trivial tools connected with pipes" design pattern. Almost all of the software you're using right now, from the LWN.net python code written to the billions of iOS and Android devices in the hands of users are written using the concepts of communication buses and object oriented interfaces (just like the systemd dbus interface, btw, which helps systemd being __properly__ integrated in much bigger solutions) .. sorry to break your bubble ..

Devuan Jessie beta released

Posted May 2, 2016 4:10 UTC (Mon) by Zack (guest, #37335) [Link] (5 responses)

> that is not to your liking?

or any serious kernel hackers', but let's reduce it to just one person, because, I don't know? Why do the vocal people who like systemd always do that?

> And what to do you really propose in place?

In order of preference:

1) Something that does what cgroups does, sanely? You know, build quality software on top of quality software? Not starting to build the house before you drained the swamp? Then again, castles in the sky don't really need foundations.

2) Nothing

3) cgroups, but let's not base an important part of infrastructure on it because that would be a really silly idea that, frankly, should be quite self-evident.

> but please let go of the 1970s lingua franca of marketing this design pattern as the only solution to all the problems of computing

Systemd certainly introduced a whole new school of thinking: "Those who do not understand how to poorly reinvent Unix, are condemned to reinvent Plan9, poorly."

> I guess you'll need to study Neil Brown's series on cgroups here first: https://lwn.net/Articles/604609/

A series of articles on how to use it, since it's there anyway, which it shouldn't be, but systemd cemented it there, and now it won't go away.

Now let me in turn quote an objective analysis that refers to the actual quality of cgroups: "What the fuck? The interface in question is optional; it's *NOT* guaranteed to be present in any kernel. Disbelieve all you want, but that fact does depend upon your beliefs. Incidentally, the code behind that interface is a misdesigned piece of shit, best configured out unless there are extremely strong reasons to enable it. Not everything that can be enabled should be."

> "trivial tools connected with pipes"

No, "separate pieces that only work together in limited ways", as opposed to "a big ball of mud that works together in unlimited ways, all alike" but feel free to reduce it ad absurdum some more. Why do you do that again?

> the billions of iOS and Android devices in the hands of users are written using the concepts of communication buses and object oriented interfaces.

Ad numerum, but even if it wasn't, that's actually a pretty decent counter argument to why it would be a good idea.

Devuan Jessie beta released

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

> 1) Something that does what cgroups does, sanely?
That "something" will look almost exactly like cgroups.

> You know, build quality software on top of quality software? Not starting to build the house before you drained the swamp? Then again, castles in the sky don't really need foundations.
Core cgroups have acceptable quality and systemd doesn't need anything more. cgroup controllers are NOT required by systemd at all.

> Now let me in turn quote an objective analysis
No, it's not. Since you obviously have no idea what you're talking about.

> that refers to the actual quality of cgroups: What the fuck? The interface in question is optional; it's *NOT* guaranteed to be present in any kernel.
So is pretty much everything else, including even filesystems. A typical distro depends on multiple optional kernel features.

Devuan Jessie beta released

Posted May 2, 2016 14:05 UTC (Mon) by Zack (guest, #37335) [Link] (1 responses)

> Core cgroups have acceptable quality

Maybe for someone who runs OSX on his desktop/laptop and solely uses containers for deploying software on the servers at his workplace and is firmly opposed to how distributions package software as integrated packages.

I wouldn't readily accept any definition of "acceptable" or "quality," or "acceptable quality" from such a person at face value though.

> No, it's not.

Okay, you got me. It's not, strictly speaking, an objective evaluation, but it's also not mine. It is the evaluation of someone who can be trusted to make an evaluation as close to objective and as far away from politics as is possible and definitely has an idea what he's talking about.

Devuan Jessie beta released

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

> I wouldn't readily accept any definition of "acceptable" or "quality," or "acceptable quality" from such a person at face value though.
So no technical arguments against my statement that systemd doesn't depend on 'bad functionality' of cgroups?

OK.

Devuan Jessie beta released

Posted May 2, 2016 15:51 UTC (Mon) by Doogie (guest, #59626) [Link]

>> that is not to your liking?

>or any serious kernel hackers

Nor any true scotsmans!

Devuan Jessie beta released

Posted May 5, 2016 13:34 UTC (Thu) by glaubitz (subscriber, #96452) [Link]

> or any serious kernel hackers', but let's reduce it to just one person, because, I don't know?

I'm sure you have a source for that you can quote, don't you?

Adrian

Devuan Jessie beta released

Posted May 1, 2016 21:29 UTC (Sun) by andreasb (guest, #80258) [Link]

>> What about getting, say, the Bluetooth stack launched automatically when a Bluetooth USB dongle is plugged in?

>What about having it already running on a machine that has Bluetooth, and not having it at all on a machine without it? That would avoid a lot of complexity, crashy and buggy complexity.

What about a machine without Bluetooth that suddenly stops being without Bluetooth? Like, for example, when a Bluetooth USB dongle is plugged in?

Devuan Jessie beta released

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

> Those are functionalities provided by cgroups. cgroups was a hot mess that every serious kernel hacker had hoped people would forget about.

It's unfair to chastise the systemd developers for using a kernel feature. If it was really that universally maligned by kernel hackers it would never have been accepted in the first place, or hurredly deprecated afterwards. Neither of those things happened, and not only systemd built on top of it but also a whole bunch of container management solutions did too, including Docker and CoreOS/rkt, and now Canonical's LXD thing. And there seems to be rather a lot of interest in containers at the moment.

Devuan Jessie beta released

Posted May 5, 2016 13:31 UTC (Thu) by glaubitz (subscriber, #96452) [Link]

> Those are functionalities provided by cgroups. cgroups was a hot mess that every serious kernel hacker had hoped people would forget about. Until someone sauntered by and thought "This looks awesome! Let's base an important part of infrastructure on this piece of spaghetti for nebulous gains! What could possibly go wrong?"

Well, the people who do High-Performance Computing (HPC) will disagree with that. One of the most popular job schedulers out there, SLURM, uses CGroups to limit the CPU and memory resources users can use when running their jobs. It's extremely useful and I'm sure no HPC admin would want to miss it these days.

> What about separating distribution-provided configuration from that provided by a local administrator in a clear and well known format that everyone is familiar with?

If the simple format adopted by systemd which comes from the FreeDesktop or Windows .ini format is too complex for you, I'm afraid you shouldn't work as a systems administrator anyway.

> What about having it already running on a machine that has Bluetooth, and not having it at all on a machine without it? That would avoid a lot of complexity, crashy and buggy complexity.

Any service that is unused and not running is always an improvement in security and stability. Anything that doesn't run can neither crash nor be exploited due to a vulnerability.

Adrian

Devuan Jessie beta released

Posted May 1, 2016 19:09 UTC (Sun) by darwish (guest, #102479) [Link]

> What about making it easy to run system services with resource limits or special security attributes?

I remember when the SMACK linux kernel security module was released back in 2008, it was so hard for to write appropriate security labels for system services: we had to write our own specific daemon startup tools to do so, and then integrate them in gazillion shell scripts ..

Now all you have to do is to write a SMACKProcessLabel= in the service file and you're done:

https://www.freedesktop.org/software/systemd/man/systemd....

And you can even add ConditionSecurity= to make sure that a service only runs when a certain security module is enabled (or disabled) in the system:

https://www.freedesktop.org/software/systemd/man/systemd....

Now why all of this is dead-simple in systemd but quite hard on older Linux systems? Simply because systemd was appropriately designed to handle *today's* computing use-cases..

Yes, all of these details are a little bit more complex (from an implementation, not system configuration, side) .. but it's much better than hiding our head in the sand pre systemd adoption in 2012 ..

Devuan Jessie beta released

Posted May 13, 2016 8:44 UTC (Fri) by jackb (guest, #41909) [Link]

What about being able to keep track of a running system service and restarting it when it fails?

This is the primary reason that I switched my Gentoo machines to systemd as soon as it was practical. Life's too short to need to manually manage daemons that crashed when the OS could just automatically restart them for you.

An argument could be made that this doesn't address the root cause of your problem - that you're running buggy daemons that should be fixed properly instead of configured to restart automatically - but real life is messy and there's not always enough resources to fix the root cause of every problem in a finite amount of time.

The other reason I switched to systemd was its ability to capture stdout and stderr from running daemons and merge that into the system log. Again sometimes you have to get work done with daemons that don't have syslog support, and life's too short to mess around with a bunch of random log files scattered around the hard drive when the OS could just merge all that information into a single stream for you.

Devuan Jessie beta released

Posted May 1, 2016 15:43 UTC (Sun) by pizza (subscriber, #46) [Link]

> To wit, what failing of sysvinit does, say, systemd's "journal" feature repair? Besides not having corporate-sexy database terminology plastered over a NIH-tastic Java-in-C redoing of worse syslog.

The failing of sysvinit is that it has *no* logging support at all. So if your script fails for whatever reason, you'll have no log record of the failure -- Indeed, you'll have no record of any console (ie stdout/stderr) output at all.

By capturing *everything* a program spits out, and serializing/storing everything in one place with a consistent metadata format, you'll have far more complete (and consequently far more useful) logs than syslog can capture on its own.

Shall I go on?

Devuan Jessie beta released

Posted May 1, 2016 16:17 UTC (Sun) by HelloWorld (guest, #56129) [Link] (1 responses)

You know, at this point I tend to view systemd haters much like creationists. The technical arguments for systemd, just like the evidence for evolution, are out there for everybody to see, and if somebody still denies them that really says more about that person than it does about the arguments.

Devuan Jessie beta released

Posted May 1, 2016 16:48 UTC (Sun) by pboddie (guest, #50784) [Link]

Please keep the discussion civil and on-topic, thanks!

Devuan Jessie beta released

Posted May 1, 2016 18:07 UTC (Sun) by flussence (guest, #85566) [Link]

> Certainly it seems that it's systemd's advocates who're ignoring history!

Nope. You're the one pushing this false sysvinit/systemd dichotomy here. Take the blinders off.

Devuan Jessie beta released

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

> To wit, what failing of sysvinit does, say, systemd's "journal" feature repair?

This is moving the goal posts, a bit, if we're talking about init systems we should only be comparing sysvinit-the-init-system with systemd-the-init-system, and journald would be out of scope. Not least because sysvinit doesn't do logging.

Devuan Jessie beta released

Posted May 3, 2016 17:51 UTC (Tue) by dlang (guest, #313) [Link] (15 responses)

>> To wit, what failing of sysvinit does, say, systemd's "journal" feature repair?

> This is moving the goal posts, a bit,

and this sort of 'moving the goal posts' and defining more and more things must be part of systemd and init that were not part of it before is one of the reasons some people are very leery of systemd

Devuan Jessie beta released

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

Yes, I am one of those people, but journald is neither a hard dependency of systemd nor does it run in PID 1. It's dishonest to raise it when comparing two init systems on their technical merit.

Devuan Jessie beta released

Posted May 3, 2016 19:19 UTC (Tue) by rahvin (guest, #16953) [Link] (11 responses)

No more disingenuous than claiming systemd is a big monolithic binary when it's 68 (last I saw) separate binaries that can be used or not used independently of each other. This seems to rely on the fact that most distributions package all 68 binaries together but ignores that they do so simply for simplicity.

As you will see later in the thread, an opponent of systemd and AFAIK one of the developers of Devuan makes clear they've never even looked at a systemd service file. Personally I'm not sure how you can be opposed to something you've never even evaluated without ignoring logic and hating for the sake of hating.

Devuan Jessie beta released

Posted May 4, 2016 11:28 UTC (Wed) by jond (subscriber, #37669) [Link]

I think you might have got confused and are arguing against someone holding the same position as you...

Devuan Jessie beta released

Posted May 4, 2016 16:47 UTC (Wed) by dlang (guest, #313) [Link] (8 responses)

it doesn't matter how many different binaries there are if the APIs between them are not considered stable and subject to change at any time. The result is still effectively monolithic, you can't substitute anything else because you are always going to be chasing changes and will be broken by each new release.

Devuan Jessie beta released

Posted May 4, 2016 16:59 UTC (Wed) by pizza (subscriber, #46) [Link]

> it doesn't matter how many different binaries there are if the APIs between them are not considered stable and subject to change at any time. The result is still effectively monolithic, you can't substitute anything else because you are always going to be chasing changes and will be broken by each new release.

Then I guess it's a good thing that systemd documents and guarantees stable APIs, eh?

(see https://www.freedesktop.org/wiki/Software/systemd/Interfa... )

Granted, that doesn't cover everything, but I'd love to hear what one is trying to accomplish that isn't covered by that list. (And, for that matter, how the former status quo provided a more stable API that wasn't subject to arbitrary change either)

Devuan Jessie beta released

Posted May 4, 2016 17:06 UTC (Wed) by anselm (subscriber, #2796) [Link] (6 responses)

Then it is surely a good thing that most of systemd's interfaces are actually covered by a stability promise. Note that, by comparison, there is no official interface description at all (let alone a stability guarantee of any sort) for the traditional setup (System-V init and friends); some of its aspects are covered by POSIX, but POSIX, for very good reasons, goes nowhere near things like the init process.

Also systemd's documentation is really quite good (way better than that of the traditional setup at any rate).

Devuan Jessie beta released

Posted May 4, 2016 17:47 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

All of those are the external APIs for systemd communicating with the outside world, show me the APIs for systemd communicating between those 68 binaries that you list as being separate.

If you look, you'll see that the APIs of those binaries are not defined well enough that you could replace them with something else. This is deliberate (and has been stated as being deliberate) on the part of the systemd developers, they want the flexibility to change that at any time, they view them as internal APIs and just like the kernel developers don't want to lock down their internal APIs, the systemd developers are resistant to doing it.

But the fact that they are Internal APIs, means that they are not independent.

Devuan Jessie beta released

Posted May 4, 2016 19:37 UTC (Wed) by pizza (subscriber, #46) [Link]

> If you look, you'll see that the APIs of those binaries are not defined well enough that you could replace them with something else.

Is this somehow limiting a real desire/need to replace/enhance a particular component for additional/changed functionality, or is this a rhetorical complaint?

Even if one accepts what you just stated here, how is it any worse than what systemd has replaced?

After all, there was no real API definition between the (many) moving parts of the former mudball, much less any guarantee of portability or stability across multiple distributions -- or even different versions of a given distribution.

Devuan Jessie beta released

Posted May 4, 2016 22:15 UTC (Wed) by anselm (subscriber, #2796) [Link] (3 responses)

All of those are the external APIs for systemd communicating with the outside world, show me the APIs for systemd communicating between those 68 binaries that you list as being separate.

Most of these are standalone programs and pretty much all of them actually have man pages that explain what they do and how to invoke or configure them (which is presumably what you mean by “API” – that term is more commonly applied to libraries). This is more than can be said for many other open-source software projects of a similar scope, including ones in similarly exposed positions. There's also the source code which is actually quite readable.

As has been mentioned, neither the traditional setup that many people so revere nor most of the other alternative init systems include documentation at the same level of detail as systemd, or for that matter an explicit stability guarantee for their external (let alone internal) interfaces. I don't really see why systemd should be held to a much higher standard than everything else around.

Devuan Jessie beta released

Posted May 6, 2016 20:43 UTC (Fri) by flussence (guest, #85566) [Link] (2 responses)

> As has been mentioned, neither the traditional setup that many people so revere nor most of the other alternative init systems include documentation at the same level of detail as systemd

There's multiple reasons for that, and not all of them boil down to "you suck". One is that the authors of that software don't have a financial incentive to make their systems dense and impenetrable to the average Linux sysadmin, who generally has better things to do than mapping out which of 200+ manpages for a mass of single-purpose software are relevant for any given task.

Let's not be disingenuous here, RedHat is a business selling support and training, not a charity; systemd is *designed* to increase users' dependency on what makes them money directly.

Devuan Jessie beta released

Posted May 6, 2016 20:58 UTC (Fri) by anselm (subscriber, #2796) [Link]

Let's not be disingenuous here, RedHat is a business selling support and training, not a charity; systemd is *designed* to increase users' dependency on what makes them money directly.

The only problem with that hypothesis is that people who are new to Linux system administration tend to find systemd significantly easier to understand than the – overcomplicated and inconsistent – traditional setup. (Until very recently I taught Linux system administration to people for a living and you can take it from me.) From that POV systemd is a singularly stupid and counterproductive idea because people no longer have to deal with the string-and-baling-wire approach of the traditional setup (I think we talked about having to stick “sleep 5” commands into init scripts to make them work).

Also, systemd isn't actually a Red Hat product, and in fact they don't have a lot of influence on its design, especially now that the systemd developer community includes people from all major distributions. People seem to be seriously overestimating the amount of control that the employers of folks like Linus Torvalds or Lennart Poettering exert on what these guys spend their time on – they seem to be generally happy with providing them with food and shelter and otherwise letting them do whatever they find useful. People who seriously believe that systemd is Red Hat's method to grab control of Linux probably also think contrails are used to poison us and 9/11 was an inside job.

Devuan Jessie beta released

Posted May 8, 2016 0:22 UTC (Sun) by johannbg (guest, #65743) [Link]

"Let's not be disingenuous here, RedHat is a business selling support and training, not a charity; systemd is *designed* to increase users' dependency on what makes them money directly."

Consolidation in the core/baseOS is not a Red Hat idea or strategy and as the opposite effect of a single vendor lock in if that's what you are afraid of.

And if you are truly interested to see where Red Hat misuses community then take good hard look into Fedora since you wont find that upstream. If you want to find what problem Red Hat customers are faced with and are being fixed upstream follow the trail of the RHEL maintainers committing upstream.

Those individuals that are calling the shots there in Red Hat's ivory tower in phoenix are perfectly aware of the fact as soon as they start twisting upstream arm to do their bidding those upstream developers will simply walk away and straight through door of their competitors or Intel, Samsung, Google, Facebook you name it.

Devuan Jessie beta released

Posted May 4, 2016 22:18 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link]

I'm not a Devuan developer and have nothing to do with the project.

I already explained the logic of why I hadn't bothered to look at unit files before later in the thread.

Devuan Jessie beta released

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

Actually, journald is a required component. You cannot run systemd without running journald.

There are methods to bypass journald for normal logging, but you still have to run it.

Devuan Jessie beta released

Posted May 4, 2016 11:28 UTC (Wed) by jond (subscriber, #37669) [Link]

I was not aware of that, thanks for clarifying.

Devuan Jessie beta released

Posted May 12, 2016 12:13 UTC (Thu) by HelloWorld (guest, #56129) [Link]

journald is a mandatory dependency of systemd-the-init-system, so i don't think this is unfair.

Devuan Jessie beta released

Posted May 1, 2016 4:05 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> "I think some of the design details are insane" [Linus Torvalds]
Just as Einstein had often been saying: "One shouldn't think".

Devuan Jessie beta released

Posted May 1, 2016 20:12 UTC (Sun) by itvirta (guest, #49997) [Link] (6 responses)

I for one would be happy to read a well-written piece about the technical problems people have met with systemd. Just so that I might know how to work around them
if I happen to meet any myself. And I mean _technical_ problems, not political ones. The original text of the announcement only mentions "problems introduced by systemd"
without specifying any such. All I see is senseless rhetoric, closing on the type one sees in the real world regarding, well, any sensitive subject where feeling and fear-based arguments are the only ones you have.

The funny thing is, I tried browsing through the Devuan web site and still didn't see any technical arguments. One assumes there would be some listed,
prominently, given that avoiding the use of certain software is the main selling point of the whole project.

Devuan Jessie beta released

Posted May 1, 2016 23:14 UTC (Sun) by larryr (guest, #4030) [Link] (4 responses)

http://blog.darknedgy.net/technology/2015/10/11/0/

Devuan Jessie beta released

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

> http://blog.darknedgy.net/technology/2015/10/11/0/

Thanks for posting that link. The article makes heavy reading due to the verbose writing style, but it's worth the effort IMHO. I guess from the lack of other comments following the link that not many have read it all the way through.

Devuan Jessie beta released

Posted May 3, 2016 3:33 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (1 responses)

It's really heavy reading... but rum helps... aye matey... rum helps.

It's actually a rather refreshing critique.. and spends more time on contrasting systemd with everything but the existing status-quo...
its just a little dense.. or maybe I'm the dense one,,,or maybe the rum is dense..it is dark rum...so its hard to see through....
regardless... it took a couple of readings.

After a sidebar conversation with my friend Commodore Morgan, I think the most interesting bit to me in that long analysis is the repeated theme concerning systemd's dependency graph and the inability to snapshot the state of the graph for the purposes of debugging the types of loops that can be created via misconfiguration of units, especially the discussion of how implicit deps interact with the graph.

-jef

Devuan Jessie beta released

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

The guy could profit a lot from taking a technical-writing course.

Devuan Jessie beta released

Posted May 4, 2016 10:04 UTC (Wed) by khim (subscriber, #9252) [Link]

It's just a bit different.

Let me put an analogy. You've used a sled with a pile of random things attached to it for years. Various sticks are picking in random direction but copious application of duct tape and bailing wire sticks everything together. You could pull it along with a few good horses but must be really careful to not destroy it. That's the current situation.

Somone comes along and proposes a nice car. Some people argue that it's not a nice thing to have because "everyone knows how to operate sled" and some like it "because you could easily do things which you couldn't do before".

And then comes this article. It explains in rather heavy writing why your design of that car is bad one, why tiller is a bad way to drive a car and that four wheels are not ideal, six would be better. This may very well be so—or not. But to give meaningful answer (indeed steering wheel is better than tiller but four wheels are usually Ok) you need to think a lot more then when you've chosen car over sled!

I, personally, am not qualified enough to give a meaningful answer for that article. I'm just not sure how severe are the problems and/or how hard and disruptive would be to change systemd to address them. I just note that sysvinit is not even mentioned in that article—and for good reason: it's dead, Jim. It's just so inadequate in today's world it's not even funny.

Systemd may not be an ideal system (what system is?) but it's so much better that what we had before that said article does not even try to fight that battle which was lost long ago. Instead if compares systemd to other, more modern systems—and, indeed, some of these have nice properties and solve some problems better than systemd. Which is nice: it means that systemd could be improved. Will it be improved? I have no idea—but this discussion does not belong to the thread where "let's preserve the sled!" Devuan distribution is discussed.

Devuan Jessie beta released

Posted May 2, 2016 18:32 UTC (Mon) by davidstrauss (guest, #85867) [Link]

I gave a talk on this at last year's systemd summit: https://www.youtube.com/watch?v=wVk-NWtiIZY

Most of the issues we've encountered don't affect lighter use, though. They're issues with scale, not correctness.

Devuan Jessie beta released

Posted Apr 30, 2016 23:12 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link] (5 responses)

Did you just make up the serial port UPS thing, or is there actually an issue with SystemD not supporting that?

If SystemD did somehow manage to break support for server shutdown on power failure, do you see why that would be an extremely serious regression for many people?

Devuan Jessie beta released

Posted Apr 30, 2016 23:43 UTC (Sat) by anselm (subscriber, #2796) [Link] (4 responses)

Did you just make up the serial port UPS thing, or is there actually an issue with SystemD not supporting that?

No, there isn't. Why should there be an issue?

If anything, serial-port UPSes are handled more elegantly in systemd because support for them isn't special-cased like it is in System-V init – there is simply a sigpwr.target that is activated in the usual manner when systemd receives a SIGPWR, rather than Sys-V init's bunch of one-off lines in /etc/inittab. This means that UPS control actions can depend on arbitrary systemd units in exactly the way all other targets do, while in Sys-V init you're reduced to cobbling together your own system-specific shell scripts.

Devuan Jessie beta released

Posted May 1, 2016 9:18 UTC (Sun) by linuxrocks123 (subscriber, #34648) [Link] (3 responses)

> This means that UPS control actions can depend on arbitrary systemd units in exactly the way all other targets do, while in Sys-V init you're reduced to cobbling together your own system-specific shell scripts.

Oh wow, shell scripts. The horror. How did we ever live having to write shell scripts?

*Googles* ... Looks like SystemD did manage to screw that up for some people:
https://lists.fedoraproject.org/pipermail/users/2012-Augu...
https://lists.freedesktop.org/archives/systemd-devel/2011...
https://lists.freedesktop.org/archives/systemd-devel/2013...
https://forums.opensuse.org/showthread.php/479499-apcupsd...

But I'm sure it's all user error and totally their fault. I mean people who bought UPSes, hooked them up to their systems with serial/USB, and scripted the computer to turn off the UPS after syncing to disk to preserve wake-after-power-fail behavior from the BIOS are almost certainly clueless n00bs, amiright?

Devuan Jessie beta released

Posted May 1, 2016 9:50 UTC (Sun) by anselm (subscriber, #2796) [Link] (2 responses)

Looks like SystemD did manage to screw that up for some people

Let's see.

It's not as if people weren't having problems integrating an UPS in their setup before systemd. The fact that the details of System-V init's configuration vary from distribution to distribution doesn't really help a lot here, either. At least with systemd things are more uniform, which makes it easier for UPS vendors to provide documentation and configuration files applying to more distributions.
This is seriously the best you can do? None of the postings you cite is even halfway recent, and on the whole the problems they show have nothing to do with systemd not supporting UPS interaction. In particular, we have no idea of the number of people who managed to get their UPS running with systemd without a hitch, because these people don't tend to show up on mailing lists. Considering that most modern distributions default to systemd and that probably more than four people in the world are using a Linux server with a UPS, systemd doesn't seem to be doing so badly.

Devuan Jessie beta released

Posted May 1, 2016 11:01 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> In particular, we have no idea of the number of people who managed to get their UPS running with systemd without a hitch, because these people don't tend to show up on mailing lists.

*raises a hand* I currently have five different machines with UPSes running systemd, with no problems at all.

Devuan Jessie beta released

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

I've got one as well as well as a freebsd based pfsense box hooked up as well (hooked up via network monitoring). Seems the UPS likes to send out a powerfailure notice when it does a system test and I was waking up to servers that are shutdown every 14 days. Both the Debian Jessie and the pfsense.

(I shut down the testing after the second time confirmed it wasn't a once off) Unfortunately I have to shutoff power from the UPS to upgrade the firmware, which has delayed my effort to fix the problem.

Devuan Jessie beta released

Posted May 1, 2016 15:56 UTC (Sun) by Zack (guest, #37335) [Link] (18 responses)

> be it an enterprise system plumbing framework

Exactly. Sometimes you need stuff to just work. Not everyone has the time to mess about with those enterprise systems because someone somewhere has read it's the new hot thing to have.

Devuan Jessie beta released

Posted May 1, 2016 21:13 UTC (Sun) by edomaur (subscriber, #14520) [Link] (17 responses)

ergo, systemd is nice.

Devuan Jessie beta released

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

No, he meant the contrary.

Devuan Jessie beta released

Posted May 2, 2016 7:26 UTC (Mon) by ovitters (guest, #27950) [Link] (15 responses)

The most popular enterprise distributions use systemd and have used it for a pretty long time. If he meant something else, his argument ('enterprise') is not supporting it.

Devuan Jessie beta released

Posted May 2, 2016 7:37 UTC (Mon) by dlang (guest, #313) [Link] (14 responses)

given that Ubuntu's first LTS release with systemd t came out in the last week or so, this seems to be stretching it a bit.

Un;ess you are being rather selective in your definition of enterprise distros.

and there is a lot of inertia in what distros people run in enterprises, just because RHEL7 switched to systemd, it doesn't mean that most users have switched yet, let alone that they like the change.

Devuan Jessie beta released

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

RHEL and openSUSE. I haven't seen Canonical being used in enterprise while RHEL and openSUSE is very common.

Devuan Jessie beta released

Posted May 2, 2016 10:56 UTC (Mon) by dlang (guest, #313) [Link] (10 responses)

While I admit it's not as common, I am seeing Ubuntu show up more and more in the Enterprise.

It's getting there for the same reasons that RedHat got into the Enterprise, people who were using Linux at home want to use what they are familiar with, and with the Ubuntu LTS releases, they have something as 'enterprise' class as any other distro.

When I am looking at Enterprise Linux software, I do see RedHat as teh most common distro to be supported, but I am seeing Ubuntu as the next most common distro, not Suse.

As always, you experience may differ.

Devuan Jessie beta released

Posted May 2, 2016 13:04 UTC (Mon) by johannbg (guest, #65743) [Link] (3 responses)

To be able to provide enterprise support companies must be active in the upstreams community for the components they provide their customer base with right. So has canonical enterprise support evolved beyond simply providing moral support to it's customer base through a hot line number which boils down to the same service as a priest or psychiatrist could provide their customer's administrator with when shit hit's the fan and the infrastructure is melting down?

Devuan Jessie beta released

Posted May 2, 2016 21:54 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

Do you really want to start going down the path of arguing how good RedHat's support is for old versions of things?

Or how involved they are in all the upstream projects?

Or make the same arguments for Suse?

I don't think that would be a wise thing to do.

I've used RedHat, Debian, and Ubuntu "Enterprise" releases at different times, and I haven't seen significantly better results in dealing with problems related to older versions in any of them.

Devuan Jessie beta released

Posted May 2, 2016 22:03 UTC (Mon) by johannbg (guest, #65743) [Link] (1 responses)

Do you agree or disagree with the assumption that to be able to provide enterprise support companies must be active in the upstreams community for the components they provide their customer base with?

Devuan Jessie beta released

Posted May 2, 2016 22:53 UTC (Mon) by dlang (guest, #313) [Link]

I disagree, because after the first few months the things that an "Enterprise" distro does have little to no impact on the upstream community, because that upstream community has moved on to new releases and isn't going to spend a lot of time working on the old version.

Devuan Jessie beta released

Posted May 2, 2016 19:04 UTC (Mon) by drag (guest, #31333) [Link] (5 responses)

> While I admit it's not as common, I am seeing Ubuntu show up more and more in the Enterprise.

This is true.

The wait from CentOS 6 to CentOS 7 was a big driver in this. Ubuntu was increasingly seeming as a viable alternative to Redhat because Redhat 'EL' release was getting so crusty and unpleasant to use.

RHEL 7 and CentOS 7 reverse this trend for my company. However we are still looking at Ubuntu for various reasons. Applications dictate the OS, not other way around. If the application says to use Ubuntu we are not going to argue with it.

on a side note:

For my personal setup I am re-re-re-learning how to setup Openstack in the 'correct' manner. As far as I can tell the easiest way to do this (which is generally the best) is by installing Ubuntu 14.04. And, holy shit, it was a culture shock. I have been using systemd-based distros for longer then most, since I use Fedora exclusively for my desktops, and going back to pre-systemd days was, to put it bluntly, very unpleasant.

One terrible bug that had me clawing at the walls was triggered by editing /etc/network/interfaces. I install Ubuntu 14.04 on my servers, but the installer defaults to DHCP. This is fine, but I want static IPs. I have a range of ips that are 'static' and range that are 'dynamic'. So I log into them, edit the network/interfaces file, and then ifdown/ifup and finished.

I go to bed, wake up, and later that afternoon I find that every single of one of my servers is now unaccessible.

Why? Because ifdown'ng the interface didn't kill the dhclient process. The Debian interfaces file has been around for, what?, 15 years? 20 years now? And it's still not mature enough to handle re-configuring eth0 correctly yet. This sort of stuff is a bit flabbergasting to run into.

This sort of stuff is why distro-specific management and configuration interfaces need to die. It's very hard to get right and if every distro does it's own thing then it needs to get done right in a hundred different ways by a hundred different projects. Chances of that happening is just about zero.

Devuan Jessie beta released

Posted May 2, 2016 20:58 UTC (Mon) by rahvin (guest, #16953) [Link] (2 responses)

That's a weird error. Having only recently went to systemd with Jessie the network shouldn't have called the DHCP client after you edited the interfaces file. That could be something related to Ubuntu but the only time I ran into something like that was when the system was installed as a "desktop" and Ubuntu installed network manager, which takes over network management and still leaves the interface file there to screw everything up when you go to edit it. I broke networking so bad I gave up trying to fix it and just trashed the VM and reinstalled.

Devuan Jessie beta released

Posted May 2, 2016 21:26 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (1 responses)

> Having only recently went to systemd with Jessie the network shouldn't have called the DHCP client after you edited the interfaces file.

The original configuration was with DHCP, and the interface was up, so dhclient was already running. After editing the interfaces file the configuration was static, so at that point ifdown didn't expect dhclient to be running and consequently failed to terminate it.

The problem is modifying the configuration file while the interface is up, combined with scripts that use the *current* interfaces file for ifdown rather than the configuration which was in place when ifup was executed.

Under systemd any background processes like dhclient associated with an interface (in the corresponding cgroup) would automatically be terminated when the interface is stopped, regardless of the current configuration. This is not a perfect solution to the problem of changing configurations, but it does mitigate the specific issue of ifdown failing to stop dhclient.

Devuan Jessie beta released

Posted May 3, 2016 19:23 UTC (Tue) by rahvin (guest, #16953) [Link]

Now I understand what happened. Thank you. These are the type of errors that make you want to tear your hair out and make me quite glad that sysv init is being replaced by a sensible program that actually monitors dependencies in daemons.

Devuan Jessie beta released

Posted May 2, 2016 22:52 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

>> While I admit it's not as common, I am seeing Ubuntu show up more and more in the Enterprise.

> This is true.

> The wait from CentOS 6 to CentOS 7 was a big driver in this. Ubuntu was increasingly seeming as a viable alternative to Redhat because Redhat 'EL' release was getting so crusty and unpleasant to use.

Actually, where I see Ubuntu making the biggest penetration isn't where there is an existing RHEL setup, but rather in the smaller companies just introducing Linux, or moving from 'joe set something up' to a more format setup. At that point there isn't an installed base to compete against, and so the choices are based on what people know.

How distros get picked

Posted May 3, 2016 8:22 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

That's roughly why there's RHEL on all our gear today, certainly. We had Fedora boxes when we first started, to get (by Enterprise standards) bleeding edge features, at that point some of the hardware was physically in someone's home. Then we had CentOS machines, by now everything was in an actual data centre in racks and we were hiring sysadmins. When we were purchased by a huge corporation obviously it needed to be an Enterprise offering that their teams of operations people would run for us, somehow, so RHEL. But it all starts with two key people running Fedora on their own machines before the business even existed.

Anyway, companies doing this stage will tend to be smaller, and the choices will get made by technical or semi-technical people, rather than by suits who need to see words like "enterprise" and "commitment" and want to feel as though they can phone up somebody who also wears a suit and yell at them if it breaks, as if that'll actually help. Also of course in 2016 the choice will often actually be "cloud", or at least leaving the hardware problems to somebody else, whether with the actual "cloud" or some managed private servers.

Devuan Jessie beta released

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

Is Ubuntu LTS considered an Enterprise distribution, these days?

Devuan Jessie beta released

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

it depends who you ask (for some people, nothing but RHEL will ever be considered an "Enterprise Distro" :-), but I don't see any good reason not to include it.

Devuan Jessie beta released

Posted Apr 30, 2016 16:58 UTC (Sat) by tzafrir (subscriber, #11501) [Link] (193 responses)

Can anybody give a summary of changes from Debian proper?

What I see is:

* Forked packages: https://devuan.org/os/packages/list/forked-from-debian (a long list)
* New packages: https://devuan.org/os/packages/list/native-to-devuan (devuan-baseconf and a jenkins-glue package)
* Blacklisted packages: https://devuan.org/os/packages/list/blacklist (systemd, systemd-sysvinit).

Where can I find more information about those changes without going through all the source packages?

Is udev being used? Is it optional? (I saw some material about 'vdev': a udev replacement, and some tutorials about avoiding it altogether).

Is there any init system besides SysV init that is supported?

XFCE is the default. Which of the other major desktops included in Jessie is functional as well?

(Please don't reply claiming that Devuan is pointless or whatever. I want to understand the actual changes)

Devuan Jessie beta released

Posted Apr 30, 2016 17:17 UTC (Sat) by lkundrak (subscriber, #43452) [Link] (94 responses)

GNOME doesn't seem to be supported. It's offered in the installer, but fails on missing dependencies. Perhaps that's the "beta" part.

Devuan Jessie beta released

Posted May 1, 2016 19:46 UTC (Sun) by ddevault (subscriber, #99589) [Link] (93 responses)

GNOME probably won't be supported. They tend to drink the systemd kool-aid pretty hard.

Devuan Jessie beta released

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

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/

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.

Devuan Jessie beta released

Posted May 2, 2016 6:56 UTC (Mon) by lkundrak (subscriber, #43452) [Link]

"Enter your comment text below. Please try to be polite, respectful, and informative"

Devuan Jessie beta released

Posted Apr 30, 2016 17:43 UTC (Sat) by hunger (subscriber, #36242) [Link]

Package wise much time was spent on removing the dependency on libsystemd0 and every other package with systemd in its name. Upower removing support for pm-utils for hibernate/suspend was another set back. IIRC that got reverted to an older version, but maybe they patched in that support into the current version again. I did not follow that.

Udev is still from systemd.

Vdev is at this point in time not up to the task of replacing udev. Using eudev was considered too big a deviation from Debian for the first release.

My understanding is that much work went into the infrastructure. I did not bother to follow that closely though.

Devuan Jessie beta released

Posted Apr 30, 2016 17:45 UTC (Sat) by hunger (subscriber, #36242) [Link] (1 responses)

Oh, sorry, forgot the init system part: Default is sysv init. Any other packages by Debian is supported, but you are basically on your own getting the required configuration files to actually start anything.

Devuan Jessie beta released

Posted May 4, 2016 11:08 UTC (Wed) by khim (subscriber, #9252) [Link]

You message is inconsistent. It looks like they really spent a lot of work to make sure systemd wouldn't be usable (similarly to how I've found PAM unusable many years ago when I first tried it: it was installable as a package, sure, but there was no way to actually use it for authentication… that was long ago and PAM was new back then… I have no idea why then want to reproduce that problem so faithfully WRT systemd in today's world).

It's their world and their work, they could do that, I'm just not sure why you need to sugar-coat such stuff: yes, they are doing an awful amount of work to make their distribution worse in all practically-applicable respects, but so what? gNewSense does the same—but at least the latter actually says clearly about what they are doing…

Devuan Jessie beta released

Posted Apr 30, 2016 20:08 UTC (Sat) by mgraesslin (guest, #78959) [Link]

we (KDE Plasma) got a bug report some time back because suspend/hibernate no longer working. You cand find that on slashdot.

Given that I would say Plasma is not supported unless the deficits in the stack got fixed.

Devuan Jessie beta released

Posted May 1, 2016 0:09 UTC (Sun) by BenHutchings (subscriber, #37955) [Link]

* Forked packages: https://devuan.org/os/packages/list/forked-from-debian (a long list)

It's a long list of binary packages, but I suspect the number of source packages is significantly smaller (about 200 of the packages are built from tasksel, for example).

Devuan Jessie beta released

Posted May 1, 2016 6:36 UTC (Sun) by lkundrak (subscriber, #43452) [Link]

Notably, network-manager is not installable, since it seems to require pam-systemd.

Devuan Jessie beta released

Posted May 1, 2016 10:07 UTC (Sun) by jaromil (guest, #97970) [Link] (41 responses)

Hello there, first of all thanks to the LWN community for hosting this conversation. Just reading a few lines one can really tell where the adults hang-out, compared to reddit or ycombinator...

As a general response to the question if Devuan is really needed, I think the best answer was already provided by this forum years ago here https://lwn.net/Articles/626169/

As a specific response to this question: have a look here https://git.devuan.org/groups/devuan-packages this is the git repository where source changes are detailed. From this gitlab installation our CI pulls and builds in a semi-automatic way trough a git -> jenkins -> amprolla -> iso/img pipeline. It is true we have spent a lot of work on infrastructure before getting busy with actual changes, which will come in testing and even more in the next release after ascii. For us systemd is just the last drop, there are more changes we want to operate on Debian and we were never able to because of puerile and overly political processes.

So, in Devuan Jessie we are changing as little as possible from stock Debian, we are really holding our horses there. Also with GNOME, we rather drop it instead of .. fixing it (?!) The only major deviation one can experiment with is running vdev in place of udev, which already covers many functionalities including running X11. If you have time, have a look at vdev, is really worth: just think that events are handled as they should be: not registering callbacks using an obscure syntax as in udev, but catching filesystem events via inotify.

ciao

Devuan Jessie beta released

Posted May 1, 2016 11:14 UTC (Sun) by tzafrir (subscriber, #11501) [Link] (3 responses)

Looking at a random change there:

https://git.devuan.org/devuan-packages/slim/commit/f5a730...

What's wrong with a package that builds --with systemd #? What is the actual overhead? You could easily have had your own "systemd" dh addon (that does nothing). All it takes is (in the worst case, maybe there's even a way to avoid it) slightly patching debhelper.

Is it worth the extra maintenance overhead of diverging from Debian? Or is it that you don't really mind diverging from Debian?

Devuan Jessie beta released

Posted May 1, 2016 11:25 UTC (Sun) by jaromil (guest, #97970) [Link] (2 responses)

You are right it could be done with less overhead wrapping the dh, but as a general strategy we prefer forking and not wrapping.

So its your second guess: we don't mind diverging from Debian at all, because we cannot depend anymore from its decisions, because we consider them unreliable.

Devuan Jessie beta released

Posted May 3, 2016 15:01 UTC (Tue) by jond (subscriber, #37669) [Link] (1 responses)

You could fork dh, and avoid having to fork every dh_systemd user, I think that was the point that was being made.

Devuan Jessie beta released

Posted May 4, 2016 8:31 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

No need for that. dh-systemd comes in its own binary package:
https://packages.debian.org/sid/dh-systemd .

As you can see from the list of files there, it also includes the potentially handy systemd2init. All you need to do is have a package that has the same name, includes /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm but is actually even shorter.

Devuan Jessie beta released

Posted May 1, 2016 11:35 UTC (Sun) by pizza (subscriber, #46) [Link] (36 responses)

> It is true we have spent a lot of work on infrastructure before getting busy with actual changes

I admit to having no knowledge about Debian's build infrastructure, but I'm going to go out on a limb here and assume that this is a more modern, slicker approach than what Debian utilizes.

Would this make sense for Debian itself to adopt?

Meanwhile. I again wonder why all of this couldn't have been accomplished within the existing Debian umbrella. Keeping non-systemd paths working is a matter of developer (either Debian or Upstream) interest/effort, and all of the high-profile "systemd is effectively required" stuff is actually due to upstream project (eg GNOME) changes.

So far, Devuan's modus operandi has been to "remove anything that so much as mentions systemd" -- which is equivalent to sticking one's head in the sand, and over time will only result in Devuan becoming less and less useful as more upstreams decide to take advantage of systemd's features.

Devuan Jessie beta released

Posted May 1, 2016 12:14 UTC (Sun) by jaromil (guest, #97970) [Link] (23 responses)

> I admit to having no knowledge about Debian's build infrastructure, but I'm going to go out on a limb here and assume that this is a more modern, slicker approach than what Debian utilizes.

Of course starting from scratch makes it easier to innovate, so yes we have what can be considered a more modern infrastructure, based on gitlab, jenkins, amprolla (our own repository software) and a new SDK to generate images for embedded and virtual machines, taking a novel approach to Zsh based scripts engineered as an interactive consoles.

Do you think that with the actual leadership and political processes in Debian, also considering how the quality of debate has degraded with systemd, nurturing Debian with our skills would have been possible?

I don't. And Bruce Perens understood it well already: https://linux.slashdot.org/comments.pl?sid=5852295&ci...

Devuan Jessie beta released

Posted May 1, 2016 12:59 UTC (Sun) by anselm (subscriber, #2796) [Link] (22 responses)

Do you think that with the actual leadership and political processes in Debian, also considering how the quality of debate has degraded with systemd, nurturing Debian with our skills would have been possible?

Generally, the way Debian works is you build stuff and convince the project that it is a good idea. Much of the current project infrastructure was arrived at in this way, rather than be being decreed from above by the “leadership”. If your skills are such that you can implement a better build framework for the distribution, why not present a prototype at DebConf and wow everybody?

Devuan Jessie beta released

Posted May 1, 2016 15:27 UTC (Sun) by jaromil (guest, #97970) [Link] (19 responses)

Wait a sec, isn't the wow presentation a format adopted by systemd? ;^)

I'm not really sure whom of us has such an ambition, of doing the 'wow' presentation in front of everybody at DebConf.
Thinking of it, the only real 'incentive' for us would be to.. drain brains from Debian. Then why DebConf should host us?

In any case, we still have more work to do to be ready to stand the criticism with something we consider complete.

Devuan Jessie beta released

Posted May 1, 2016 15:31 UTC (Sun) by pizza (subscriber, #46) [Link] (18 responses)

> Thinking of it, the only real 'incentive' for us would be to.. drain brains from Debian. Then why DebConf should host us?

This is not a zero-sum game.

The infrastructure you've put into place could be of great value to Debian, which in turn would get more people working on it, which in turn would benefit Devuan, allowing you to focus on what you care about -- which, as far as anyone can tell, consists solely of ridding the world of libsystemd.

Devuan Jessie beta released

Posted May 1, 2016 16:17 UTC (Sun) by jaromil (guest, #97970) [Link] (17 responses)

Ehrr, no. I can assure you 'ridding the world of libsystemd' is definitely not what we care about.
Let's say we are pro-choice :^) and all developers involved have a life and many more projects to care about.

The incentive you mention stands somehow, we'll see.

Devuan Jessie beta released

Posted May 1, 2016 16:23 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> Let's say we are pro-choice
Yeah, except when people choose systemd.

Devuan Jessie beta released

Posted May 1, 2016 20:20 UTC (Sun) by bronson (guest, #4806) [Link] (15 responses)

> Let's say we are pro-choice

Debian certainly appears to be pro-choice since the user can choose which init system to run.

I don't understand your terminology... How is Devuan pro-choice?

Devuan Jessie beta released

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

Have you actually tried what you mention as possible?

Debian developers should actually be honest with their users and drop sysvinit because is not a viable choice as of release 8. The intertwined network of dependency from systemd creeps in at any stage from init to desktop, omitting one of these stages is not a solution. Because of these dependencies, Debian Jessie became unusable in production unless systemd is adopted. I mean production, not a lab situation when init can be choosen at install.

I used Debian in production on a vast range of diverse appliances for more than 10 years and some senior members of my organization are DDs. Believe me I'm not making it up, nor have fun when writing this.

Devuan Jessie beta released

Posted May 2, 2016 7:55 UTC (Mon) by anselm (subscriber, #2796) [Link] (10 responses)

I used Debian in production on a vast range of diverse appliances for more than 10 years and some senior members of my organization are DDs. Believe me I'm not making it up, nor have fun when writing this.

I have been a DD since the mid-1990s and have used and supported Debian on a wide range of servers, desktop and mobile systems. Speaking for myself, I have yet to experience any problems with the transition to systemd in Debian Jessie. In fact I am convinced that making systemd the default init system for Debian is entirely in tune with the project's quest to provide its users with the best operating system.

Having said that, converting a distribution that is the size of Debian and used in many different contexts to a different init system is not a trivial task to be undertaken lightly. While the DDs involved have been, and are, doing sterling work, problems are to be expected, but their impact must be seen in comparison to the impact of the problems to be expected when sticking to the traditional setup which is becoming more and more obsolete – not only because better technical solutions (like systemd) are available but also because Debian would deliberately remove itself farther from the Linux mainstream, for little benefit. On the whole, the Debian project has proved perfectly capable of dealing with problems that switching to systemd has caused, and there are no grounds for the assumption that this would not be the case going forward. As far as I'm concerned the effort to move Debian to systemd has been thoroughly worth it, and will pay off even more in the future as systemd is improved further and more software packages are adapted to take advantage of its features.

I don't deny that you may have had problems with systemd in Debian, and that forking the entire distribution is something that you're perfectly entitled to do if you want to. I still wonder whether the effort incurred would not have been better spent helping to improve systemd-based Debian, or for that matter systemd itself. What I definitely don't buy is the notion that Debian, having adopted systemd as the default, is now terminally broken, because in my personal experience (and that of many others) the opposite is actually the case.

Devuan Jessie beta released

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

Thanks for your prose. I still miss the answer. It is just between the lines that you seem to admit that its factually impossible to opt-out systemd in Debian Jessie.

I do not intend to diminish your work, your goals and the usefulness of having systemd in your environment. I would just like to mark this mutual understanding, if there is some.

Devuan Jessie beta released

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

It is just between the lines that you seem to admit that its factually impossible to opt-out systemd in Debian Jessie.

As far as I know System-V init is still a supported init system within Debian Jessie. The release notes for Debian Jessie document in detail how to prevent a system from being switched over to systemd when upgrading to Jessie. I haven't tried this myself because I'm happy with systemd and frankly could not care less about System-V init at this point.

Devuan Jessie beta released

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

Right. I see the chapter 5.6 of release Debian Jessie release notes recites:
"/!\ Caution: Be advised that some packages may have degraded behavior or may be lacking features under a non-default init system."

I hereby confirm that Debian 8 "Jessie" running sysvinit behavior is so degraded that cannot suit any production use. That is why we had to fork and started Devuan in 2014.

For the sake of intellectual honesty, I'd greatly appreciate if you and others would stop denigrating Devuan saying "it is not needed", as I believe we can well understand it is. Of course such manipulative arguments coming from the mouth of a DD are doing nothing else but eroding the trust between members of our projects.

And I wish you happy hacking with systemd.

Devuan Jessie beta released

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

I hereby confirm that Debian 8 "Jessie" running sysvinit behavior is so degraded that cannot suit any production use. That is why we had to fork and started Devuan in 2014.

That doesn't follow. The obvious action to take if you run into “degraded behaviour” on the part of a Debian software package with a non-default init system is to file a bug report on the package in question, preferably with a patch that will fix the problem, not to fork the entire distribution. Also note that the “degraded behaviour/lack of features” packages include things like GNOME, where the systemd dependency is basically an upstream requirement that Debian can't realistically be expected to work around, and which in many contexts where Debian is used aren't required or wanted anyway.

The main reason the release notes include the passage in question is essentially CYA against the case that something has not been tested with every non-default init system in Debian (which include not just System-V init but also Upstart and a few others). The number of users who run non-standard init systems on Debian is expected to be fairly small, and while it would be great if the maintainers of relevant Debian packages made a point of testing their packages against every single init system in Debian, we can't realistically force them to do that. Therefore the people who do use a non-standard init system are encouraged to share the work to make sure that bugs are fixed, i.e., to help scratch their own itches.

Devuan Jessie beta released

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

> file a bug report on the package in question, preferably with a patch that will fix the problem, not to fork the entire distribution.

I haven't tried that, but know people who have done that and it was leading to nothing. There are traces of such interactions on your bugtracker.

> The number of users who run non-standard init systems on Debian is expected to be fairly small

This assumption as been proven wrong by a deeper and independent analysis lead by Distrowatch.
I'm not just talking about this poll: http://distrowatch.com/polls.php?poll=8
But also of the analysis made on current updates to Debian 8 and packages used in there, as reported in this article http://www.pcweek.ru/foss/article/detail.php?ID=174973

Devuan Jessie beta released

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

I haven't tried that, but know people who have done that and it was leading to nothing. There are traces of such interactions on your bugtracker.

[Citation needed]

But also of the analysis made on current updates to Debian 8 and packages used in there, as reported in this article http://www.pcweek.ru/foss/article/detail.php?ID=174973

The only thing that analysis seems to prove is that people are generally happy with the default init system that their distribution provides. Also as I said, right now systemd and System-V init are both supported init systems within Debian, and it is totally possible to upgrade a Debian system to Jessie without having to move to systemd, so there's really nothing to see here. Some people may just be deferring the move, for whatever reason, even though they upgraded to Jessie. (The other thing the article seems to do, at least in Google's translation to German, is to call into question the necessity of a Debian fork à la Devuan, but maybe the original Russian says something else – my Russian isn't good enough to be able to tell.)

Devuan Jessie beta released

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

> But also of the analysis made on current updates to Debian 8 and packages used in there, as reported in this article http://www.pcweek.ru/foss/article/detail.php?ID=174973
I speak Russian.

This article simply tells that people do not touch the default setting and very few people running oldstable (where sysv init was the default) had switched to systemd.

Duh.

Devuan Jessie beta released

Posted May 2, 2016 18:06 UTC (Mon) by andreasb (guest, #80258) [Link]

> Right. I see the chapter 5.6 of release Debian Jessie release notes recites:
> "/!\ Caution: Be advised that some packages may have degraded behavior or may be lacking features under a non-default init system."
>
> I hereby confirm that Debian 8 "Jessie" running sysvinit behavior is so degraded that cannot suit any production use. That is why we had to fork and started Devuan in 2014.

The major causes for "lacking features" would be desktop environments like GNOME or KDE. I don't see how Devuan helps with that, especially since further up in the comments it was mentioned that in Devuan, GNOME works… not at all.

As someone who had to do a non-systemd upgrade to Debian 8 on a virtual root server I rent[1] I can say that in my experience there is no problem for server environments and I wouldn't expect any if you're not a desktop user. And again, if you are, you'd probably still be better off with Debian.

[1] Because I don't know what containerization thingymabob it uses and it's running a Redhat 2.6.32 patched-all-the-way-to-hell-and-back kernel.

Devuan Jessie beta released

Posted May 3, 2016 6:39 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> I hereby confirm that Debian 8 "Jessie" running sysvinit behavior is so degraded that cannot suit any production use. That is why we had to fork and started Devuan in 2014.
Non sequitur. The issues could have been fixed within the Debian project. It's not a matter of policy, there's apparently just not enough interest in sysvinit any longer.

Devuan Jessie beta released

Posted May 3, 2016 15:57 UTC (Tue) by raven667 (subscriber, #5198) [Link]

> "/!\ Caution: Be advised that some packages may have degraded behavior or may be lacking features under a non-default init system."
> I hereby confirm that Debian 8 "Jessie" running sysvinit behavior is so degraded that cannot suit any production use. That is why we had to fork and started Devuan in 2014.

That is a very maximillist interpretation bordering on absurd, of course if you depend on a feature that the default init system has that other systems don't then your behavior will be different or degraded on other systems, this is not the same as saying that the system is failing at _any_ production use, that's just gross hyperbole. Do you have any specific examples of the complete brokenness you describe or is this entirely theoretical.

Devuan Jessie beta released

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

>>> Let's say we are pro-choice
>>
>> Debian certainly appears to be pro-choice since the user can choose which init system to run.
>> I don't understand your terminology... How is Devuan pro-choice?
>
> Have you actually tried what you mention as possible?

I have not, but sysvinit support is still required for packages in Debian. So you can rely on Debian giving you a choice between systemd and sysvinit - with all packages being configured to support both.

Devuan, on the other hand, doesn't seem to give you much choice at all: if you don't use sysvinit, you're own your own. There's not a single supported alternative. Instead, packages have been deliberately modified to prevent some alternatives from working. Sure, you can install openrc or any of the others, but you can do the same in Debian, and none of the packages will work with it out of the box.

It seems when it comes to init system choice, so far Debian is the better choice.

Devuan Jessie beta released

Posted May 12, 2016 17:36 UTC (Thu) by johannbg (guest, #65743) [Link] (1 responses)

"Devuan, on the other hand, doesn't seem to give you much choice at all: if you don't use sysvinit, you're own your own. There's not a single supported alternative."

Well according to those enlighten devuans [1] "Devuan uses sysvinit, offers openrc, runit, sinit" that's their definition of "Init freedom" but I would take that with a grain of salt what's written on that page since they are for example referring to Gentoo "Gentoo uses openrc (see Gentoo without systemd)" in the "GNU/Linux Distributions without systemd" and link to a wiki page subjected for removal [2] "This article has been flagged as dirty for not conforming to the wiki guidelines. " ( which begs the question if this wiki page was actually written by the Gentoo community ) when in fact Gentoo offers both ( and have done so since more or less systemd inception ) [3][4] along with comparisons of init systems [5]

As people can see if they read devuans own page that distribution is built on factual incorrectness and propaganda against systemd despite " jaromil" claiming they are not waging any crusade against systemd.

1. https://www.devuan.org/os/init-freedom/
2. https://wiki.gentoo.org/wiki/Gentoo_Without_systemd
3. https://wiki.gentoo.org/wiki/OpenRC
4. https://wiki.gentoo.org/wiki/Systemd
5. https://wiki.gentoo.org/wiki/Comparison_of_init_systems

Devuan Jessie beta released

Posted May 12, 2016 17:45 UTC (Thu) by Nikratio (subscriber, #71966) [Link]

>> Devuan, on the other hand, doesn't seem to give you much choice at all: if you don't use sysvinit,
>> you're on your own. There's not a single supported alternative."
>
> Well according to those enlighten devuans [1] "Devuan uses sysvinit, offers openrc, runit, sinit" that's
> their definition of "Init freedom" but I would take that with a grain of salt [...]

Yes, the other systems are *packaged*. But if you install them, they won't start any services. You have to configure them all on our own. In other words, only the easy work has been done, and the majority of the work required to use e.g. sinit is the same for Debian and Devuan.

Devuan Jessie beta released

Posted May 1, 2016 16:01 UTC (Sun) by pboddie (guest, #50784) [Link] (1 responses)

Why do they need to present anything? Can't people from Debian decide whether there's something worth adopting without the need for anyone to have to go somewhere and pitch things to them?

Devuan Jessie beta released

Posted May 5, 2016 14:13 UTC (Thu) by glaubitz (subscriber, #96452) [Link]

> Why do they need to present anything? Can't people from Debian decide whether there's something worth adopting without the need for anyone to have to go somewhere and pitch things to them?

Because that's how it usually works in the open source community or any scientific community. If you have created something nice and you want to share it with others, you give a presentation.

Adrian

Devuan Jessie beta released

Posted May 1, 2016 16:00 UTC (Sun) by jaromil (guest, #97970) [Link] (11 responses)

> So far, Devuan's modus operandi has been to "remove anything that so much as mentions systemd" -- which is equivalent to sticking one's head in the sand, and over time will only result in Devuan becoming less and less useful as more upstreams decide to take advantage of systemd's features.

I realise having skipped this remark in my previous answer. You make an important point here.

Its true that upstream adoption is crucial to determine the success of systemd. But not all upstream and not all industries will adopt it.
For instance, the security implications of systemd are huge. As well its impact on embedded development.
To not even mention enterprise dynamics like the one described here https://www.reddit.com/r/linux/comments/4gzho2/devuan_a_f...

So my opinion is that the scenario we have ahead will not be as compact as you depict it, but rather fragmented.
And this fragmentation, or better purpose-driven differentiation, was evident already 15 years ago in the distro world.
Even with massive upstream adoption of systemd I don't believe we'll all be dragged into its snowball.
And BTW, how hard it is to code a smaller program to replace specific parts of systemd and satisfy specific upstream needs?

So well, back to Devuan, even if we fail at making a universal base distribution, we'll have at least satisfied our own needs with a base distribution we can rely on to do our work.
And I'm rather sure we have opportunities ahead to ally with more people, organisations and industries that share our needs. It's already happening ;^)

Devuan Jessie beta released

Posted May 1, 2016 16:32 UTC (Sun) by pizza (subscriber, #46) [Link] (4 responses)

> For instance, the security implications of systemd are huge.

You're going to have to qualify this...

(From my own understanding, at worst systemd is no worse than the legacy sysvinit model, and typically fares better due to exposing a smaller attack surface)

> As well its impact on embedded development.

Dunno; I've gone on record several times in the past saying that if systemd had been available when I was building BSPs for access points and whatnot, it would have saved my employer a couple of man-years of effort compared to us having to invent (and maintain) our own wheels.

Beyond that, 'embedded' means a lot of things these days, many of which are far larger and complex than a desktop from a decade ago. Heck, systemd is even in cars now.

> To not even mention enterprise dynamics like the one described here [ snipped reddit url ]

I'm sorry, but a random reddit poster cannot speak for the enterprisey world, especially when he does not appear to understand how enterprise operating systems are actually chosen.

Nobody pays money for RHEL unless they need to -- The OS is chosen to support the applications, not the other way around (presuming commodity hardware, anyway). For example, my employer uses RHEL because the upper-five-digits-per-seat-per-year EDA tools they utilize are only supported by their vendors on a specific version of RHEL.

The purchase price for the hardware, the OS license, and even the sysadmin costs are insignificant when one considers that our yearly licensing costs for our local office (20ish engineers) were in excess of 2 million USD a couple years back.

> So well, back to Devuan, even if we fail at making a universal base distribution, we'll have at least satisfied our own needs with a base distribution we can rely on to do our work.

That's the beauty of Free Software. I'm glad it's working well for what you need!

Devuan Jessie beta released

Posted May 1, 2016 17:13 UTC (Sun) by jaromil (guest, #97970) [Link] (3 responses)

> You're going to have to qualify this...

no, I don't 'have to' write anything I don't want to write, especially considering I have no time for it.

>> As well its impact on embedded development.
>Dunno;

I do, having worked on embedded system for more than 10 years now. systemd is clearly impacting uclibc and musl.

>> To not even mention enterprise dynamics like the one described here
>I'm sorry, but a random reddit poster cannot speak for the enterprisey world

Sorry, but then what am I doing here, speaking to a random LWN poster called 'pizza'?

> That's the beauty of Free Software. I'm glad it's working well for what you need!

Nono, no kumbaya yet my friend. We have to work hard to avoid an imposition and a limitation of our freedom.

What is happening is not the "beauty of Free Software", but a last-chance catch by the safety belt of FSF licensing.

Now I'm sorry but I don't have more time to follow this conversation. Ciao.

Devuan Jessie beta released

Posted May 1, 2016 18:53 UTC (Sun) by pizza (subscriber, #46) [Link]

> no, I don't 'have to' write anything I don't want to write, especially considering I have no time for it.

Okay, but if you're going to make assertions, it's up you to support them with at least anectodal evidence.

Ciao, indeed.

Devuan Jessie beta released

Posted May 1, 2016 20:39 UTC (Sun) by bronson (guest, #4806) [Link] (1 responses)

This is a disappointing response. Back in the oughts I spent some time working on embedded Linux set-top boxes. The number of workarounds we had to stick in our init scripts just to get a sub-1-minute boot time was out of hand. I can only imagine how much easier it would have been with systemd.

So, I was looking forward to hearing nonobvious ways that systemd makes embedded harder. Except in extremely memory-constrained environments (which tend to use hand rolled rc scripts anyway), it seems like a clear win to me.

I hope you'll explain your evidence at some point. I'm still curious.

Devuan Jessie beta released

Posted May 1, 2016 21:31 UTC (Sun) by pizza (subscriber, #46) [Link]

> So, I was looking forward to hearing nonobvious ways that systemd makes embedded harder. Except in extremely memory-constrained environments (which tend to use hand rolled rc scripts anyway), it seems like a clear win to me.

I too was interested in this, as my experience was remarkably similar to yours.

Incidentally, classic rc scripts turned out to be pretty bad memory-wise too; we had to do a lot of custom coding to ensure we didn't spawn too many things at once. We actually integrated some extra stuff into busybox to save memory (and yes, delivered the complete corresponding source code as per the GPL). As it turned out this also greatly sped up boot times by eliminating much shell script parsing and many forks that were now all handled internally to busybox's shell. The price was a slightly higher baseline idle memory usage, well worth the effort.

We also had to play (not always successful) games to capture console logging, had to write our own service status/monitoring/respawning tools, had endless fun trying to ensure clean shutdowns so we could perform firmware upgrades, and yes, even had to modify a few daemons so that they would properly detach from the console or otherwise behave better. Oh, and handle dynamic events, restarting/reinitializing whatever services were affected (of course, respecting all dependencies) depending on which operational mode we were in.

Systemd wouldn't have necessarily solved all of these issues for us -- we'd still have had to dynamically generate a set of unit files based on the system configuration (aka our own "business logic") but we wouldn't have had to [re-]invent and maintain so much low-level infrastructure.

Then again, the fact that this stuff was so complicated is what kept us in business... so maybe it's a good thing that systemd didn't come along until well after the company shut down.

Devuan Jessie beta released

Posted May 1, 2016 17:43 UTC (Sun) by darwish (guest, #102479) [Link] (5 responses)

> As well its impact on embedded development.

At work, it was kind of easy optimizing an embedded systemd-based Linux system to boot in less than one second.

Moreover, the features of on-demand activation proved very useful. Thanks to systemd bus-activation and service files, it was quite easy for example not to start the bluetooth stack except when bluetooth was needed by the user..

And this was done in a simple manner: the QT application just requests bluetooth using bluez dbus APIs.. systemd launches bluez using bus activation.. dead-simple bluez service files was then used to appropriately boot the kernel+userspace bluetooth stack.

Yes, systemd had some automatic builtin services that delayed our boot speed for a while .. but as in any engineering project or task, we've read the excellent manuals and devised service files that made systemd boot time overhead minimized __to the 100 millisecond range__ without writing a single line of code (on an ARM cortex core) ..

*****

Moreover, __ALL__ of the embedded Linux automotive folks has adopted systemd in their base specifications.

This is true for the BMW-led GENIVI alliance:

http://www.genivi.org/sites/default/files/GENIVI%20Lifecy...

And also for the Linux Foundation's AGL (Automotive-grade Linux).

******

So when someone says systemd is so-and-so because of "embedded" I get very wary and wonder what domain of embedded they're talking about.

If you're talking about the dead-simple embedded use cases, these developers actually do not use an Init system and just runs a quick init=my_script.sh as their init sequence ..

Devuan Jessie beta released

Posted May 1, 2016 18:24 UTC (Sun) by jaromil (guest, #97970) [Link] (4 responses)

Yes I mean the simple, but not dead, cases. I may be wrong in using the term 'embedded', since what I mean is perhaps more specific to use cases.

Devuan Jessie beta released

Posted May 1, 2016 18:37 UTC (Sun) by darwish (guest, #102479) [Link]

I see. Thanks for the clarification :-)

Devuan Jessie beta released

Posted May 2, 2016 20:02 UTC (Mon) by rahvin (guest, #16953) [Link]

So you probably shouldn't call it blanked embedded and refer to it as specific use case as it's highly deceptive and overselling the conflict immensely.

Devuan Jessie beta released

Posted May 5, 2016 15:12 UTC (Thu) by glaubitz (subscriber, #96452) [Link] (1 responses)

> Yes I mean the simple, but not dead, cases. I may be wrong in using the term 'embedded', since what I mean is perhaps more specific to use cases.

I'm running Debian with systemd on an Amiga 4000 with an 68060 CPU with 50 MHz, 2 MiB ChipRAM and 128 MiB FastRAM. I would consider that at the very lower end of anything that could be considered a small system.

And it runs fine.

Adrian

Devuan Jessie beta released

Posted May 10, 2016 21:53 UTC (Tue) by nix (subscriber, #2304) [Link]

Wow!

... er, why? "Because it was there"? (Which is a valid reason. Running something like this on something as small as that is impressive!)

Devuan Jessie beta released

Posted May 1, 2016 12:46 UTC (Sun) by ksandstr (guest, #60862) [Link] (49 responses)

> XFCE is the default. Which of the other major desktops included in Jessie is functional as well?

Devuan carries MATE, the fork of GNOME 2. Combined with a display manager not married to systemd such as slim, it's on par with GNOME 2 before it was destroyed by CADT. Additionally, MATE's components are as reusable outside of GNOME 2 (i.e. with minority window managers such as Fvwm2, Notion, Awesome, Window Maker, etc.) as those from a pre-systemd revision of GNOME 3.

history of CADT

Posted May 1, 2016 15:31 UTC (Sun) by louie (guest, #3285) [Link] (47 responses)

"on par with GNOME 2 before it was destroyed by CADT"

Since Devuan is so interested in Unix history, a quick lesson: CADT was a complaint about GNOME *1* being destroyed by the incompetent idiots who developed GNOME 2, not about GNOME 2 being destroyed by the incompetent idiots who developed GNOME 3.

~~ the more you know ~~

history of CADT

Posted May 1, 2016 16:19 UTC (Sun) by ebassi (subscriber, #54855) [Link] (43 responses)

Also, considering the overlap of people that made GNOME 1, 2, and 3, I think we can't really call them "teenagers" any more. GNOME itself is not going to be a teenager any more, next year. ;-)

history of CADT

Posted May 1, 2016 19:04 UTC (Sun) by josh (subscriber, #17465) [Link] (42 responses)

I doubt it was all that accurate when jwz first said it, either; it just seems like a generic insult, about as meaningful as "young whippersnappers". For that matter, "CADT" was originally used to describe the case of marking bugs in an old system obsolete because a new system exists that (probably doesn't) have those bugs, rather than triaging them; it doesn't represent a completely general catch-all for every gripe about GNOME 3 differences.

I do find it rather amusing, having followed the GNOME 1 to GNOME 2 transition, how remarkably similar the complaints are. If the complaints about GNOME 3 have seemed more voluminous, I think it might just be because GNOME 2 had far more users than GNOME 1 ever did.

history of CADT

Posted May 1, 2016 19:21 UTC (Sun) by hitmark (guest, #34609) [Link] (1 responses)

The basic problem though is that if those bugs had been fixed, one now had assurance that they were fixed. But by rewriting the relevant components, one do not know that. And the rewrite is likely to hide a whole pile of new bugs.

history of CADT

Posted May 1, 2016 19:44 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

>The basic problem though is that if those bugs had been fixed, one now had assurance that they were fixed

Hardly the case. There are no assurances that a bug will not popup again due to mere code changes. It doesn't require a rewrite to introduce regressions at all. Testing can help reduce such instances but don't eliminate it.

history of CADT

Posted May 1, 2016 19:46 UTC (Sun) by louie (guest, #3285) [Link]

Yeah, I should have added sarcasm tags - sorry for any confusion. I am literally the CADT so I Have Opinions. ;)

history of CADT

Posted May 1, 2016 20:32 UTC (Sun) by epa (subscriber, #39769) [Link] (38 responses)

I understand 'Cascade of Attention-Deficit Teenagers' to refer to the process where an older release of some software is marked 'out of support' and all bugs in the bug tracker filed against that version are automatically closed (unless someone explicitly reopens them or updates the version). This is particularly noticeable with Fedora, where a release goes out of support a year and a bit after it first came out. All the bug reports, which could contain useful information and more likely than not(*) are still applicable to the latest release, are essentially dropped. That may be an unavoidable choice if there just isn't the manpower to triage and fix bugs properly, but it is certainly dispiriting to file a bug, see it sit around in the tracker for a few months, and then be closed with some automated message.

(*) Even in the fast-moving world of Linux and Fedora in particular, code doesn't get thrown out and rewritten in one year. The half-life of code, and bugs, is much longer than that.

If there are legitimate reasons to believe that old bugs will have been fixed (or at least rendered unreproducible) by a rewrite of some component, then it's fine to go and close them en masse. If the distribution moves from SysV init to systemd, to pick an example entirely at random, it might make sense to close bugs filed against the older init system. But not to just spray the whole bug tracker with CLOSED because Fedora 22 is now out and so Fedora 20 is no longer 'supported'. Bugs are not requests for support and need not follow a 'support' cycle. For sure there are lots of useless bug reports but the good ones are invaluable information by someone who has taken trouble to send it to you. If you do get so overwhelmed that you have to throw away all reports older than a certain point, this should be a case by case decision.

history of CADT

Posted May 1, 2016 21:56 UTC (Sun) by pboddie (guest, #50784) [Link] (37 responses)

That may be an unavoidable choice if there just isn't the manpower to triage and fix bugs properly, but it is certainly dispiriting to file a bug, see it sit around in the tracker for a few months, and then be closed with some automated message.

Indeed. I just read Luis's blog post admitting his role in the JWZ rant on the topic, but the point of the rant is not that some specific fault existed somewhere in the code and thus didn't exist any more because that code was gone: it is that a problem was observed with the software and suddenly an assertion is being made that the software no longer has the problem, with no effort made to check whether this is really the case.

It's like claiming that some gadget, having had a component replaced, will no longer suffer from a problem purely because a new component has been used, while it is possible that the new component has precisely the same design defects that caused the reported problem. As an end-user, having bugs closed ostensibly for housekeeping purposes gives the impression that you care more about the design and architectural issues of the software than the people supposedly responsible for writing it.

history of CADT

Posted May 2, 2016 3:20 UTC (Mon) by pizza (subscriber, #46) [Link] (36 responses)

> [...] it is that a problem was observed with the software and suddenly an assertion is being made that the software no longer has the problem [...]

No, the tickets were marked as NEEDINFO, with a message that basically amounted to "hey, let us know if this problem is still relevant."

> As an end-user, having bugs closed ostensibly for housekeeping purposes gives the impression that you care more about the design and architectural issues of the software than the people supposedly responsible for writing it.

Or, perhaps, it's a sign that the developers need to know if this problem still exists (and thus still worth looking into) when they already have a ton of other stuff to do that they already know is important.

(Incidentally, if you want someone to be responsive to your bug reports on any sort of guaranteed schedule, that's called a service level agreement and requires forking over a non-trivial pile of money on an ongoing basis)

history of CADT

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

To add to this: http://yarchive.net/comp/linux/bug_tracking.html, as written by Linus Torvalds on Mon, 30 Apr 2007:

> On Mon, 30 Apr 2007, Adrian Bunk wrote:
> >
> > My ideal was always that reported bugs should be fixed.
>
> ..and this is where we differ.
>
> OF COURSE bugs should be fixed. But you seem to think that there is
> something magical and special about every single bug-report.

The entire conversation is worthy to read and goes way more into detail than some black/white view on things. This thread changed my view on things. Before this one, I was in the "never ever close a bugreport unless it is fixed" camp.

history of CADT

Posted May 2, 2016 9:29 UTC (Mon) by pboddie (guest, #50784) [Link] (34 responses)

No, the tickets were marked as NEEDINFO, with a message that basically amounted to "hey, let us know if this problem is still relevant."

My problem with this, and I've noted this a few times previously, is that such things can be far easier to check for the people developing the software: it may well be a case of the end-user having to upgrade large parts of their distribution the hard way, whereas the developers are actually building and presumably running the software themselves on a frequent basis. I know that end-users are often perceived to be whiners with an entitlement complex, but asking them to go through substantial inconvenience, just to verify what might be regarded as a mere assertion of a problem that supposedly doesn't affect anyone else, is only going to elicit the kind of rant that brought us the CADT label.

In addition, checking certain things and not "needing info" would also be part of any kind of release validation process. You can't check everything, but automated testing is a lot more widespread than it was when JWZ coined the CADT label. Asking end-users to "beta test" software is somewhat optimistic: it assumes that those people are as enthusiastic about the development of the software as the developers when they may actually depend on the software for real-world use. Indeed, the end-users may in some cases be more serious users of the software than the developers, but that doesn't mean that their seriousness should be called into question because they aren't willing to break their setup just to run an errand.

(Incidentally, if you want someone to be responsive to your bug reports on any sort of guaranteed schedule, that's called a service level agreement and requires forking over a non-trivial pile of money on an ongoing basis)

Well, sure. And they can even still ignore those bug reports, anyway, if my experience with one enterprise distribution is any indication. Maybe my employer wasn't paying enough money or something. Meanwhile, if people want high-quality bug reports, they should at least preserve a culture in which those reports are considered to have some value. Otherwise, what's left is just a mountain of reports that might as well be swept off the desk, whose owners have probably moved on to using something else, anyway.

history of CADT

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

> Meanwhile, if people want high-quality bug reports, they should at least preserve a culture in which those reports are considered to have some value.

The sad fact of the matter is that the overwhelming majority of bug reports are of very low quality and have even less intrinsic value. Raising those up to a level in which they are actually useful (if that is even possible) takes a great deal of time and effort. Time and effort that most developers don't have to spare. Heck, more time and effort than even the reporters themselves seem to have.

And yes, that "time and effort" includes translating that bug report into an automated test. If it's something that can even be automated. How do you test something on a platform you don't personally have access to, or in the case of OSX, can't even *compile* for?

Sure, you can claim that developers have some sort of moral obligation to care about each and every every special snowflake of a reported bug, but that is a naive view utterly divorced from reality.

I can't even count the number of bugs I've personally closed after after effectively sitting in a NEEDINFO state for months; quite frankly if the reporter doesn't care enough to actually answer basic questions, then there's no point in my taking time away from something that is already actionable.

history of CADT

Posted May 2, 2016 12:49 UTC (Mon) by pboddie (guest, #50784) [Link] (3 responses)

Sure, you can claim that developers have some sort of moral obligation to care about each and every every special snowflake of a reported bug, but that is a naive view utterly divorced from reality.

I'm not saying that at all. What you quoted even indicates that I said pretty much the opposite of that:

Meanwhile, if people want high-quality bug reports, they should at least preserve a culture in which those reports are considered to have some value.

There will always be reports that are incoherent, incomplete or even incorrect. But developers should realise that they are missing an opportunity to reassure themselves of the quality of their work if they bulk-close bugs because the high-quality reports will be lost. And not taking such opportunities tends to store up problems for later.

You can say that developers have priorities and that they might have better things to do with their time. That, and the closely-related "nobody is paying me to do this" phenomenon, are separate topics with the latter being a particular area of concern because it shows how the investment priorities around Free Software development (and software development in general) can be misguided and self-defeating.

history of CADT

Posted May 2, 2016 14:05 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> it shows how the investment priorities around Free Software development (and software development in general) can be misguided and self-defeating.

If by "investment priorities" you mean someone in a suit making funding decisions for other people's employment, then yes, I'd agree with you. Such is the disappointing reality of commercial concerns. But for the majority of Free Software developers/projects, even the higher-profile ones, "investment" means "donating their time."

My F/OSS, first and foremost, is written to meet my own personal needs, but it is released to the public "in the hope it will prove useful, but without any warranty whatsoever..." Anything beyond that will require someone to convince me the effort is worthwhile. Sometimes it is, sometimes it isn't. It's not that I necessarily expect to get paid, but rather a matter of opportunity cost and attempting to have a healthy work/life balence.

I'll end this by pointing at a recent _On the Fast Track_: http://comicskingdom.com/on-the-fastrack/2016-03-17

history of CADT

Posted May 2, 2016 17:05 UTC (Mon) by pboddie (guest, #50784) [Link] (1 responses)

If by "investment priorities" you mean someone in a suit making funding decisions for other people's employment, then yes, I'd agree with you. Such is the disappointing reality of commercial concerns.

Indeed.

But for the majority of Free Software developers/projects, even the higher-profile ones, "investment" means "donating their time."

And this is where everybody gets short-changed, although I'm not currently sure of the strategy required to transform the environment from "work for free to impress some random company to hire you to work on something else/proprietary" and "it's a labour of love and they don't expect to get paid for it" to one where companies might actually understand that properly investing in Free Software helps keep them and their economic venue viable in the long term.

My F/OSS, first and foremost, is written to meet my own personal needs, but it is released to the public "in the hope it will prove useful, but without any warranty whatsoever..." Anything beyond that will require someone to convince me the effort is worthwhile. Sometimes it is, sometimes it isn't. It's not that I necessarily expect to get paid, but rather a matter of opportunity cost and attempting to have a healthy work/life balence.

Sure. If someone says that "it would be really nice if you added this or I'll have to stop using it" but doesn't actually offer any incentive, which is a classic guilt-tripping technique pulled by random Internet people, then after a while you get to learn that you let those people go. Then again, some people might want to persuade other people that their work is hot stuff: there, the level of pandering to random strangers might need to be somewhat different, but nothing I've written falls into that category and I don't have any aspirations for it to do so any more, either.

I'll end this by pointing at a recent _On the Fast Track_: http://comicskingdom.com/on-the-fastrack/2016-03-17

(After a script-induced trawl of the Internet instigated by the page concerned...) Well, there's some truth in that. But when my work involved such activities, I did find that some of the more frustrated people did have a point, even if I had to sit and listen to a lengthy rant in a language I did not learn as a child which mostly reflected that person's fairly legitimate frustration with something I probably only had some involvement in delivering.

history of CADT

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

> And this is where everybody gets short-changed, although I'm not currently sure of the strategy required to transform the environment from "work for free to impress some random company to hire you to work on something else/proprietary" and "it's a labour of love and they don't expect to get paid for it" to one where companies might actually understand that properly investing in Free Software helps keep them and their economic venue viable in the long term.

The OpenSSL fiasco is a good example of what happens when critically important Free Software gets short-changed. ("Which fiasco," you might ask? And that is exactly my point)

Fortunately, it seems to have accomplished quite a lot of good. At least now more folks are aware that software doesn't grow on trees..

history of CADT

Posted May 3, 2016 16:09 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (28 responses)

You're right that bug reports are often of low quality. For example last night I read the original post in this thread:

https://community.letsencrypt.org/t/error-creating-new-au...

... and just now I popped back to see "whoops" the user reporting the problem omitted to mention that they had set up a cron job that was repeatedly issuing authorizations. When they got an error about too many authorizations they just couldn't conceive that this might be related, and so they just didn't even mention it at all. Such people aren't able to help themselves, it's a huge burden to try to help them with even the simplest problems they run into...

But the thing that gets projects a reputation for CADT isn't that, it's where a project does rewrites _rather_ than even examine bugs. That's a huge problem with Free Software, but it's one that we could do a LOT more to resist. Today if you say you're making Version 2 of program X and it's a rewrite so you won't be reading any of the old bug reports, we package up Version 2 as if it's somehow an improvement. We may even say people should move to Version 2 because the prior software is "unsupported" which implies Version 2 will be supported. But that's a lie. The decision to not read the old bug reports is a tacit acceptance that Version _2_ is unsupported, that in fact you don't support software at all, whatever the version. Which is fine, it's your time to spend as you please, but packaging the Version 2 software up and telling people to upgrade makes this error look like success and so the distributions are doing their users a disservice by encouraging it.

The persistent belief that if only we could start over from a clean slate things would be better is not a disease unique to Software Engineering, you'll find it in town planning, in product marketing, all over the place. You have to learn to stop thinking that way, and for the teenagers who are often most enthusiastic about "burn it down and start fresh" projects that's not going to happen overnight. But as I wrote, we should be _discouraging_ this, not encouraging it.

history of CADT

Posted May 3, 2016 16:18 UTC (Tue) by louie (guest, #3285) [Link] (27 responses)

GNOME had a paid full-time person working on "examining bugs" at the time we closed Jamie's bug (me!), as well as a small-but-quite-active community of bug-reviewing volunteers. It was all we could do to keep up with new, incoming bugs, much less bugs that were years old and applicable to a completely different codebase. The assertion by anyone that we simply didn't want to review bugs is insulting to all the hard work we did to make GNOME 2 successful.

On the code side, rewriting for rewriting's sake is of course a bad idea, but that wasn't the case for either GNOME 2 or GNOME 3: there were deep technical and design debts that had to be addressed comprehensively in order to provide a modern desktop experience. That required, as I said in another comment, pretty comprehensive rewriting of both underlying technology and user interfaces. So even if the bugs had been high quality when they were written, they still likely would not have applied.

Maybe to put the whole thing another way: there is an assumption of bad faith/incompetence in the CADT claims that is deeply corrosive to healthy communities. It places a burden on volunteers who've made this their passion project for years that is somewhere between insulting and hurtful, and presumes knowledge of a complex problem space that many of the critics don't actually have. Perhaps no surprise that it came up in this thread, then, since the same threads - lack of respect for the hard work of others, failure to actually understand the problem space - come up a lot around systemd.

history of CADT

Posted May 4, 2016 0:19 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (26 responses)

_Everybody_ who sets out to burn things down and start from scratch convinces themselves that _this_ time they're doing it for the right reasons. Perhaps some of them are even correct. But certainly most of them are wrong, yet no less convinced anyway. I have worked on several "burn it down and start from scratch" projects, some of which are GPL'd and some not, and the only one that I'm even somewhat convinced was appropriate after decades of experience was the one which most resembles Brooks' "build one to throw away" pilot system approach.

In particular your apparent belief that if roughly the same group of people write a program again it will have completely different and unrelated bugs is pure wishful thinking. Those people are going to keep making the same mistakes, they're going to keep forgetting the same basic use cases, keep testing only the scenarios that apply to them and not other scenarios, and keep tripping over the same misunderstandings of their language, their libraries, and their environment. But now instead of ten unread bug reports over five years saying that app X can't do Y properly, you can start "fresh" and discover a remarkable thing - app X version 2 can't do Y properly either. Huh, who'd have thought? Only everybody who has been paying attention :/

history of CADT

Posted May 4, 2016 5:58 UTC (Wed) by louie (guest, #3285) [Link] (25 responses)

I agree with your general skepticism of rewrites - they're often done by inexperienced developers for bad reasons, and (as with most software) often take longer than they planned. But they're also often done for good reasons, and they're almost always criticized by people who have no idea about the underlying user needs or suitability of the technology.

I think in the case of GNOME, history bears out that we were generally right to make the decisions we did. Projects tried to fork what was left of GNOME 1, and went nowhere; they found that both the old infrastructure was hard to modernize (i18n, a11y, etc.) and that there wasn't actually much interest despite some very loud complainers. (Again, sounds familiar!)

The main fork of GNOME 2 (MATE) has done somewhat better - there are a lot more happy MATE users than there ever were of GNOME 1, which is a great credit to the MATE developers! Still, Fedora and Debian have kept GNOME as their default, and debian popcon suggests 6x as many people have GNOME 3 installed as MATE (based on the installs of the respective file and window managers). In terms of developer activity, the 20th most-active MATE module on github was modified 26 days ago; the 20th most-active module on GNOME 3 was modified 9 hours ago. (You have to go through 240+ projects to find the GNOME module modified more than 26 days ago.) And the 600+ extensions in extensions.gnome.org shows that the decision to move to a scriptable shell interface (the biggest "rewrite" of GNOME 3) is both drawing developer interest and empowering users. So, yes, perhaps incremental improvement of GNOME 2 could have been successful, but a group of folks are literally trying that and not doing well by most reasonable metrics as the main core contributors.

history of CADT

Posted May 4, 2016 6:46 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

> I think in the case of GNOME, history bears out that we were generally right to make the decisions we did.
You guys _REALLY_ need a reality check.

history of CADT

Posted May 4, 2016 7:33 UTC (Wed) by louie (guest, #3285) [Link] (10 responses)

Because the old code bases (or similar ones) are doing so well, or...? I mean, obviously we're not Android or iOS, but if that's your standard for success pretty much all open source is a failure. So what's the alternative path we should have followed? Would we somehow have become Android if only we'd stuck with GTK 1? Would we somehow have become OS X if only we'd kept our 1.4 preferences dialog? I think it's pretty clear that, even if they didn't take over the whole world, the big gambles we made were a lot better than sticking with what we already had. The one metric that suggests otherwise is application uptake: maybe if we'd stuck with GTK 1 we'd have more apps? (We certainly seemed to have more Back In The Day.) But I suspect even there, the answer was that we needed to be more bold and do more rewriting (mono or Java), not stick with the old stuff.

history of CADT

Posted May 4, 2016 8:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Because the old code bases (or similar ones) are doing so well, or...?
I'm talking about achieving your goals.

From what I see, there are now more desktops running Unity than GNOME3. And even RedHat ships GNOME3 with Classic mode. The fact that people are still using (and actively developing!) MATE built on GTK2 released back in 2002 speaks volumes.

You've also lost applications. Many projects actually switched from GTK2 to QT rather than to GTK3: https://blog.wireshark.org/2013/10/switching-to-qt/ , https://subsurface-divelog.org/ , Unity, http://wiki.lxde.org/en/LXDE-Qt and so on.

And it doesn't appear that all that pain has attracted new users in great numbers - desktop Linux marketshare still hovers around 1%.

history of CADT

Posted May 4, 2016 23:12 UTC (Wed) by bronson (guest, #4806) [Link]

> But I suspect even there, the answer was that we needed to be more bold and do more rewriting

I have to ask... Do you really think Gnome's problem is not enough rewrites?

I'd guess that would have encouraged me to leave earlier. Even less stability doesn't seem like a winning strategy to me. But, admittedly, I'm not in Gnome's target audience.

history of CADT

Posted May 10, 2016 8:15 UTC (Tue) by paulj (subscriber, #341) [Link] (7 responses)

Your 1.4 prefs dialogue is using the stock widget look. If you were trying to make 1.4 look bad, that's what you'd choose. I doubt anyone shipped with stock/no-theme as the default theme. There were a lot prettier themes. E.g. "ThinIce" still looks fairly good today.

history of CADT

Posted May 10, 2016 15:37 UTC (Tue) by raven667 (subscriber, #5198) [Link] (6 responses)

That is a very weird thing to say, that showing the default operation of a particular software would be considered "trying to make it look bad" and that this would be considered a defense of the software in question. Are you saying that the people who built this software and chose the default look were "trying to make it look bad" ??!! My head goes all 'splody trying to understand what you are implying here.

history of CADT

Posted May 10, 2016 15:46 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

Louie seemed to be arguing that the GTK look from GNOME 1.4 days was ugly and using that as evidence for some greater argument about need for GNOME to rewrite stuff. I agree the /default/ GTK library look from those days, as shown in the example, was indeed a bit ugly. However, I don't think any distro shipped with the stock/no-theme default widget set as the distro-default. I don't know why the library default was ugly, but that library default look was *not* what users got anyway in those days - so using a screenshot of that library-default seems unrepresentative, and hence not a good support for whatever argument louie was making.

history of CADT

Posted May 10, 2016 16:00 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

> Louie seemed to be arguing that the GTK look from GNOME 1.4 days was ugly

That isn't it at all. The image shown is the control center setting overloaded with geeky options. The look of the toolkit is irrelevant to the point being made there.

history of CADT

Posted May 10, 2016 16:11 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

I think the point wasn't the actual widget appearance, but the complexity of the preference dialog and the implications it had for both usability and testability of GNOME 1.x as a whole.

history of CADT

Posted May 10, 2016 16:36 UTC (Tue) by paulj (subscriber, #341) [Link]

Ah. :)

Ok. On that, I'd whole-heartedly agree. GNOME 2 was a huge improvement in that regard. It should be noted that, a factor in the (eventual) success of GNOME 2 was that the changes were driven by empirical HCI studies carried out by Sun Microsystems. The results of which led to the GNOME 2 HIG.

GNOME 2 wasn't just arbitrary change. It was change based on objective evidence.

history of CADT

Posted May 10, 2016 16:12 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

> Louie seemed to be arguing that the GTK look from GNOME 1.4 days was ugly

I didn't get that at all, I didn't see this as making a comment about the aesthetic qualities of grey, which I think is largely irrelevant, but as a comment about the organization and number of preferences, which was greatly simplified in the move to GNOME 2, so that every user didn't have to wade through a cacophony of irrelevant sliders and tabs, to change the few options that were most likely to be changed, while still retaining many of the variables exposed in a more advanced interface for those who want it.

This was a major change and rewrite that most people seemed to like better than the old tool in time, you could make the same kind of comparison between Sawmill and Metacity, would GNOME be stronger today if Sawmill had stayed as the default, to maintain compatibility, same as if the original Control Center had stayed?

history of CADT

Posted May 10, 2016 21:41 UTC (Tue) by nix (subscriber, #2304) [Link]

I would certainly be hugely happy if Saw{mill,fish} had stayed alive, rather than its main developer being hired by Apple on the condition he stopped working on it. It was and is the best Lispy WM out there, bar none.

history of CADT

Posted May 4, 2016 6:46 UTC (Wed) by louie (guest, #3285) [Link]

Sorry, not doing *as* well. They're definitely doing pretty well overall, and again - serious kudos to them. I'm glad they're using the freedom our licenses granted them and successfully empowering users that way.

history of CADT

Posted May 4, 2016 7:48 UTC (Wed) by johannbg (guest, #65743) [Link] (10 responses)

"600+ extensions in extensions.gnome.org"

Does windows have "extensions"
Does MacOS X have "extensions"
Does Android have "extensions"

It goes without saying desktop environment should be growing application not extension to workaround it's poor design.

+If memory serves me correct then extensions were never planned to be part of Gnome but grew out of necessity to their keep end user base.

Now the fundamental problem with Gnome is the instability of it's UI design and always has been ( 1.x, 2.x 3.x does not matter ).

That was the thing novices end users complained most to me about when I was Fedora Ambassador.

Those end user did not what shiny new things with "effects" and gazillion default applications to be confusion about.

They wanted a boring stable UI with the exact same applications in the exact same place as before so they did not have re-learn where applications and system configuration was placed or start using new applications they where entirely unfamiliar with.

And that was why novice end users did not use Fedora which ironically is to many ( Red Hat ) people it's "target audience" and why the Red Hat desktop team is forcing Fedora's release cycle in sync with the Gnome one again ( despite 10 years of history telling them not to but hey let's tear the community a new one with now with no mass rebuilds to achieve that impossible goal! Fracking idiots )

history of CADT

Posted May 4, 2016 10:53 UTC (Wed) by pizza (subscriber, #46) [Link] (8 responses)

> Does windows have "extensions"
> Does MacOS X have "extensions"
> Does Android have "extensions"

FYI -- Yes, Yes, and Yes.

> +If memory serves me correct then extensions were never planned to be part of Gnome but grew out of necessity to their keep end user base.

Extensions were *always* part of the plan and were a core feature of Gnome-Shell. Specific extensions, on the other hand, may not have been. Which leads me to...

> It goes without saying desktop environment should be growing application not extension to workaround it's poor design.

No, it's called designing sufficient flexibility so that functionality use cases not part of the core design can be added by those who want or need said functionality. There's quite a lot of stuff that doesn't rise to the level of an "application" or by necessity needs information only known to the shell itself.

> They wanted a boring stable UI with the exact same applications in the exact same place as before so they did not have re-learn where applications and system configuration was placed or start using new applications they where entirely unfamiliar with.

Users want nothing to change except for the things they want to change, then loudly complain when the changes they want require changes elsewhere.

Meanwhile, if you wanted a "Boring stable UI" then we'd all still be using CDE. Heck, one of the "enterprise" applications I have to use would look right at home on that platform. It's also a festering pile of swill.

history of CADT

Posted May 4, 2016 11:09 UTC (Wed) by johannbg (guest, #65743) [Link] (7 responses)

> Does windows have "extensions"
> Does MacOS X have "extensions"
> Does Android have "extensions"

"FYI -- Yes, Yes, and Yes."

Please provide me with links to documentation to the extension framework those other OS provide.

history of CADT

Posted May 4, 2016 11:24 UTC (Wed) by pizza (subscriber, #46) [Link] (6 responses)

> Please provide me with links to documentation to the extension framework those other OS provide.

Okay, I'll do this, even though what you're asking is literally as simple as plugging "X shell extensions" into google and pressing "I'm feeling lucky".

"windows shell extensions" returns: "creating shell extension handlers" on MSDN:

https://msdn.microsoft.com/en-us/library/windows/desktop/...

"Finder shell extensions" returns "App extension programming guidelines" on Apple's developer site:

https://developer.apple.com/library/ios/documentation/Gen...

Now Android's a little more complicated; "extensions" in the classical sense are really a per-application thing, and there are many applications which implement their own extension mechanism. However, the Android core is built around the concept of "intents" which allow arbitrary code to implement various activities. For example, every application in the "Send to..." list is there because it's registered an intent that can be used by anyone). Here's the "I'm feeling lucky" link returned from searching for "android intents", called "Intents and Intent filters" on the android developer site:

http://developer.android.com/guide/components/intents-fil...

history of CADT

Posted May 4, 2016 14:10 UTC (Wed) by johannbg (guest, #65743) [Link] (4 responses)

"Okay, I'll do this, even though what you're asking is literally as simple as plugging "X shell extensions" into google and pressing "I'm feeling lucky"."

You where the one that was claiming that the other OS had extensions and it's framework and their implementation was comparable with Gnome so it goes without saying you refer to what exactly you yourself are referring to so one can make the same comparison and reach the same or different conclusion as you did.

I view extension or "plugins" as highlighting underlying design deficiency ( the more extension people install or the higher usage of specific extension indicate something that should be the part of the default design since from my point of view people should not have to install extension or plugins to get the functionality they require from the desktop environment but providing the framework to overcome limitation of the desktop environment is not something I'm against ) so our opinion on that topic differ.

And the boring stable UI conclusion comes from being Fedora Ambassador for 8 years installing Fedora on those novice end users hardware and helping them with problems they experienced running and using Fedora as their day to day desktop in the process. These where regular technology challenged individual not tech savy people who know or want spending hours setting up, tweak (or otherwise fight the desktop environment to be able to use it.

In the end of the day what matters the most is what works for the end users, ( them, they are the ones who will be using that computer on a day to day bases not me, not you or anyone else which often seems to be forgotten ) and makes their life easier and helps them get their work done and is least in their way in doing that.

If Microsoft Windows works for them good, if OS X works for them great, if Linux works for them fantastic but in reality Linux on desktop is failing to work for 98.35% [1] people using computers as their desktop on the planet that's undisputed fact otherwise it would be more popular and would be more widely used.

1. https://www.netmarketshare.com/operating-system-market-sh...

history of CADT

Posted May 4, 2016 15:14 UTC (Wed) by anselm (subscriber, #2796) [Link] (1 responses)

I view extension or "plugins" as highlighting underlying design deficiency ( the more extension people install or the higher usage of specific extension indicate something that should be the part of the default design since from my point of view people should not have to install extension or plugins to get the functionality they require from the desktop environment but providing the framework to overcome limitation of the desktop environment is not something I'm against ) so our opinion on that topic differ.

Sometimes it is difficult to figure out before the fact what functionality people would actually like to have. In that sense, providing an extension framework is like sowing a huge lawn in the town square and then later paving over those paths where people have been walking a lot, rather than paving a bunch of footpaths first and hoping that people will follow them and not walk on the grass. Similarly, the most popular extensions can then be made part of the core product.

It would be great if a large and complex piece of software like GNOME could be all things to all people from the get-go, but that's not what usually happens. In view of this, an extension framework is the next-best thing because it lets users scratch their itches in all the places that the original designers didn't foresee or didn't consider important. On the other hand, deliberately omitting basic functionality that is obviously desirable to a large proportion of known users, and relying on extension developers to put it back (which I hear is something the GNOME developers subscribe to – I'm not a GNOME user myself so don't have first-hand experience) is probably not the wisest approach.

history of CADT

Posted May 4, 2016 17:49 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> Sometimes it is difficult to figure out before the fact what functionality people would actually like to have

It also makes niche but very useful extensions possible. The existence of extension frameworks is a good thing.

history of CADT

Posted May 4, 2016 15:34 UTC (Wed) by anselm (subscriber, #2796) [Link]

but in reality Linux on desktop is failing to work for 98.35% people using computers as their desktop on the planet that's undisputed fact

I don't think it is quite correct to say that desktop Linux is “failing to work” for all those people when the reasonable assumption is that the vast majority of them has never actually tried a Linux system in the first place. Something “failing to work”, in my opinion, implies a reasonable attempt to make that something work to begin with. (Incidentally, arguably there are many people whose entire computer needs could be adequately covered by Firefox and LibreOffice, and it would probably not matter in the least to them whether these run on Windows or Linux.)

As long as virtually all desktop PCs come with a pre-installed operating system that isn't Linux, and only comparatively few people actually care enough to install Linux, talking about Linux “failing to work” for everyone who stays with their factory-provided (non-Linux) default operating system is unreasonable. In any real sense, Linux has only “failed to work” for those people who actively installed it, gave it a try, and then went back to whatever they used before, and that will be considerably fewer than 98.35% of all desktop PC users.

history of CADT

Posted May 4, 2016 15:51 UTC (Wed) by pizza (subscriber, #46) [Link]

> In the end of the day what matters the most is what works for the end users, ( them, they are the ones who will be using that computer on a day to day bases not me, not you or anyone else which often seems to be forgotten ) and makes their life easier and helps them get their work done and is least in their way in doing that.

End-users want absolutely nothing to change. Except for the things they want changed. And then it needs to be exactly the same, only different.

...Yes, I've been through this quite a few times. Suffice it to say that I have very strong feelings on the subject.

> If Microsoft Windows works for them good, if OS X works for them great, if Linux works for them fantastic but in reality Linux on desktop is failing to work for 98.35% [1] people using computers as their desktop on the planet that's undisputed fact otherwise it would be more popular and would be more widely used.

I don't doubt that Desktop Linux is insignificant (Steam claims ~1% of their users do so on Linux, for example) but that Netmarketshare.com's claim that *Windows 3.1* comprises of 0.45% of the installed base makes me distrustful of the quality of their other figures.

I also wonder where they're slotting in Chromebooks, which on their own would account for more than Linux's total reported share.

history of CADT

Posted May 4, 2016 17:28 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> "windows shell extensions" returns: "creating shell extension handlers" on MSDN
Shell extensions are not really comparable with GNOME plugins. They were used to do stuff like virtual filesystems in Explorer or additional toolbars, not to change the way Windows looked.

Now, since Windows tried to preserve binary compatibility, lots of products hooked into the deep levels of system and provided lots of customizations.

Mac OS X had even less customizability.

history of CADT

Posted May 4, 2016 11:49 UTC (Wed) by nye (subscriber, #51576) [Link]

>Does windows have "extensions"

Yes, in unimaginable numbers. First literally - shell extensions are extremely common, and a great many applications come with them.

Also less literally there are a huge number of utilities which aren't technically 'shell extensions' but which are functionally the moral equivalent in that they are programs that adjust the behaviour or functionality of bits of Windows. For example, simple utilities like 7+ Taskbar Tweaker do the kind of thing that might be done by a Gnome extension, and you might also consider larger scale things like Classic Start Menu or DisplayFusion to be comparable.

history of CADT

Posted May 5, 2016 18:52 UTC (Thu) by sionescu (subscriber, #59410) [Link]

Having to install 16 extensions to make gnome-shell useable, that are sometimes incompatible even among themselves and break with updates, that does not "empower" me, just makes me curse at GNOME devs for not having those features in the base distro.

history of CADT

Posted May 1, 2016 19:19 UTC (Sun) by hitmark (guest, #34609) [Link] (1 responses)

Not so much destroyed, as it being about rather than fixing reported bugs they were marked as invalid because the relevant component had been rewritten or replaced.

In essence, the originator of the term, JWZ, seems to hold the opinion that it is better to maintain existing code rather than rewrite from scratch at (ir)regular intervals.

history of CADT

Posted May 2, 2016 16:31 UTC (Mon) by louie (guest, #3285) [Link]

Sometimes that's appropriate, sometimes it isn't. And sometimes the rewrite is such that previous tests, bug reports, etc., have a very low probability of being relevant. (In the case of GNOME 2, in most cases, it was both a significant tech rewrite and a more-or-less complete UX rewrite, so this was doubly true.)

So when developers have very little bandwidth (because they are typically volunteers), they can stop development for a year or two to review tens of thousands of low-value bugs, or they can ask tens of thousands of people to spend a very small amount of time to help out. If we really are community-driven development, the latter is a no-brainer.

history of CADT

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

Indeed it was, which makes it even more sad reading IMHO, since basically the same thing seemed to happen again.

Devuan Jessie beta released

Posted May 1, 2016 18:38 UTC (Sun) by ovitters (guest, #27950) [Link]

> it's on par with GNOME 2 before it was destroyed by CADT

On Reddit Devuan supporter (likely Devuan developer) is a bit agitated that people criticize Devuan. At the same time, there are loads of personal comments from Devuan towards GNOME _contributors_. The first response already highlights the not so good reputation that Devuan has.

Devuan Jessie beta released

Posted Apr 30, 2016 18:33 UTC (Sat) by bronson (guest, #4806) [Link] (2 responses)

> Debian GNU+Linux is a fork of Debian without systemd

That's a typo, right? They meant Devuan GNU+Linux?

Devuan Jessie beta released

Posted May 1, 2016 6:34 UTC (Sun) by lkundrak (subscriber, #43452) [Link] (1 responses)

Now that's a rather embarrassing typo...

Devuan Jessie beta released

Posted May 1, 2016 10:56 UTC (Sun) by jaromil (guest, #97970) [Link]

Freudian lapsus, a poignant suggestion on how we feel about this whole story.

PulseAudio?

Posted Apr 30, 2016 20:25 UTC (Sat) by epa (subscriber, #39769) [Link] (2 responses)

What about PulseAudio? Aren't they going to remove that too? And Mono?

PulseAudio?

Posted Apr 30, 2016 21:17 UTC (Sat) by tjc (guest, #137) [Link]

Pulseaudio is in the forked-from-Debian list.

https://devuan.org/os/packages/pulseaudio

PulseAudio?

Posted May 1, 2016 18:43 UTC (Sun) by darwish (guest, #102479) [Link]

PulseAudio has no hard systemd dependencies :-)

AFAIK, there were some talk about replacing rtkit-daemon (which is used by pulse to gain real-time scheduling priority without wrecking the entire system if pulse messed it up) with systemd facilities, but there's nothing concrete about this effort so far ..

Devuan Jessie beta released

Posted Apr 30, 2016 21:55 UTC (Sat) by jwilk (subscriber, #63328) [Link] (2 responses)

The article says:
>- Roger Leigh (Debian) :: maintainer of sysvinit package in Debian

But Roger retired from Debian almost year ago.
sysvinit doesn't have a Debian maintainer at the moment.

Devuan Jessie beta released

Posted May 1, 2016 13:13 UTC (Sun) by jrigg (guest, #30848) [Link] (1 responses)

> sysvinit doesn't have a Debian maintainer at the moment

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811377

Devuan Jessie beta released

Posted May 5, 2016 15:57 UTC (Thu) by glaubitz (subscriber, #96452) [Link]

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811377

If you bothered to read the bug report, you'd realize the package is still orphaned.

There are people in the discussion who are showing interest, one of them being the maintainer of the openrc package in Debian, but so far, nothing concrete has resulted from that.

Adrian

Devuan Jessie beta released

Posted May 1, 2016 19:13 UTC (Sun) by hitmark (guest, #34609) [Link] (16 responses)

Dear deity the systemd evangelists are out in force.

You would almost think that it had been hand coded by Steve Jobs...

Devuan Jessie beta released

Posted May 1, 2016 20:15 UTC (Sun) by bronson (guest, #4806) [Link] (15 responses)

Or... you think a lot of people just like systemd?

Nah, it's gotta be a conspiracy.

Devuan Jessie beta released

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

It's wise to realise that the majority of people are not forum posters. I don't mean to deflate your enthusiasm in systemd, but please realize online activity is not even directly proportional to the reality of followers.

Believe me when I say in the specific case of Devuan we are experiencing an overwhelming success and attention, without much fanfare and especially from non-english media.

About the embedded: in my previous post I did give evidence of my argument, naming two specific projects that are extremely relevant to embedded development especially when security oriented. You can follow their online interaction with systemd for more details.

I promise I will take the time to explore more in detail the security implications of systemd I mention, but please understand forum comments aren't the best format for such a tractation. I'm also eager to wait for actual events to occur, to have a factual representation of my arguments.

Devuan Jessie beta released

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

> naming two specific projects that are extremely relevant to embedded development

It would be nicer if you'd just be clear.

I guess the things you're talking about is uclibc and musl. This argument has been raised many times in the past. Systemd requires more from a libc and those projects lacked various things glibc does provide. Instead of working around the lack of libc support in systemd and various other projects, it is way easier to have libc's provide what projects want to use. This argument is super old and rehashing it seems unnecessary.

Devuan Jessie beta released

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

You can ignore the argument for N reasons valid to you, but thes facts hold:
1- It is not possible to use uclibc or musl-libc with systemd.
2- There is a vast number of people out there who need or even prefer to use these, or slightly modified versions of them.
3- I'm one of them and this was one of the good reasons for me to join forces with Nextime and start Devuan.
4- Both of us, current lead developers of Devuan, sources maintained in Debian on ARM and MIPS platforms for projects where security and reliability are critical factors.
5- Most of us learned (sometimes the hard way) that minimalism and simplicity is a factor for the reliability of a project.

As you are involved in GNOME, I can well understand we don't share point 5, yet I recommend talking to people at FermiLab about these matters. As I previously stated I'm happy you reached out and would be even happier to understand you can separate the interwebz noise from actual opening to dialogue. What I'm not sure of as of now is whether this dialogue would be of any interest for us.

Devuan Jessie beta released

Posted May 2, 2016 9:28 UTC (Mon) by anselm (subscriber, #2796) [Link] (5 responses)

You can ignore the argument for N reasons valid to you, but thes facts hold:
1- It is not possible to use uclibc or musl-libc with systemd.
2- There is a vast number of people out there who need or even prefer to use these, or slightly modified versions of them.

I'm not an embedded-system developer, but a quick Google search turned up patch sets that according to their developers made it possible to run systemd with either, so it doesn't appear to be an intractable problem.

In general it seems to me that patching the libraries in question, or writing an additional library that would contain whatever these are missing that systemd needs, or even changing systemd to better accommodate these libraries would be a better approach overall than forking an entire distribution, but of course you're free to decide what you want to spend your time on.

Devuan Jessie beta released

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

Emil's patches for musl-libc are admittedly not complete nor production ready, while I doubt there is any grade of even minimal understanding with upstream to make such a patchset maintainable.

Now I'm sorry to put up more mirrors to climb, but well if our references are just web searches now, please do not ignore this big elephant in the room: https://developers.slashdot.org/story/15/11/01/0051216/bu...

Now I think it would be best to use this discussion space, gracefully provided by the openness and politeness of LWN editors, to have some mutual understanding and wrap up this thread as gentlemen. Years have passed and we can look at things with much better understanding now. To keep diminishing and denigrating Devuan by ignoring or manipulating the reasons for it to be born will not help anyone. Let me give you a friendly reminder that I'm really not making up my arguments, but they represent the position of a vast amount of professionals who are rejecting systemd for their own reasons and have been overly mistreated because of airing them in public.

Devuan Jessie beta released

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

Now I think it would be best to use this discussion space, gracefully provided by the openness and politeness of LWN editors, to have some mutual understanding and wrap up this thread as gentlemen.

Fair enough. I'll stop putting forward technical arguments in favour of systemd the instant you stop claiming that systemd is worse than the traditional setup for production use.

Devuan Jessie beta released

Posted May 2, 2016 10:16 UTC (Mon) by jaromil (guest, #97970) [Link] (2 responses)

There is no universal "production use".

Systemd is not just worse, is absolutely not viable for most production uses I contemplate.
I think I explained enough already and provided enough references about what I contemplate as production use and why I draw this conclusion.

Systemd is catering to completely different needs that are often and obnoxiously ignored and denigrated by its advocates. The reasons for such a vehement denigration to take place are obscure to me. Before systemd I have never met anyone in our communities that would be so incline to ignore and denigrate other people's needs even when not affected. Anyway, I'm not referring to you at least until now, but I spot reasons to be deluded if we continue our conversation. Plus we are left mostly alone in this discussion and I suspect some readers may get bored past this point.

Therefore with your permission and the unsatisfied need for a rational conclusion, I must depart now.
Ciao

Devuan Jessie beta released

Posted May 2, 2016 14:20 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

> There is no universal "production use".

Maybe. Just like when you say testing or staging, people have a general understanding of these terms. You can speak purely from a niche case that is production for you but it is not necessarily going to be relevant for a general discussion about whether something is suitable for production usage.

Devuan Jessie beta released

Posted May 5, 2016 16:05 UTC (Thu) by glaubitz (subscriber, #96452) [Link]

> I think I explained enough already and provided enough references about what I contemplate as production use and why I draw this conclusion.

Except that you didn't.

When asked, what the huge security implications were that systemd had, you just left the discussion like a little child that was huffy [1].

How is anyone here supposed to take you serious?

Adrian

> [1] http://lwn.net/Articles/685654/

Devuan Jessie beta released

Posted May 2, 2016 12:57 UTC (Mon) by pboddie (guest, #50784) [Link] (2 responses)

It is not possible to use uclibc or musl-libc with systemd.

This is useful to know because uclibc appears to be used with OpenWrt, which also appears to have its own technologies corresponding to various systemd-related components, and because there is interest in Debian being a sensible alternative to OpenWrt on embedded devices. This tends to lead me in the direction of exploring the choices of OpenWrt and seeing how their choices (and those of Debian) might affect Debian in the embedded space.

Devuan Jessie beta released

Posted May 3, 2016 16:19 UTC (Tue) by ballombe (subscriber, #9523) [Link] (1 responses)

So far Debian only support glibc anyway (even the Freebsd kernel variant).

Devuan Jessie beta released

Posted May 5, 2016 16:07 UTC (Thu) by glaubitz (subscriber, #96452) [Link]

> So far Debian only support glibc anyway (even the Freebsd kernel variant).

We have dietlibc in Debian and the rebootstrap people are working with musl, too [1]. They have direct support from upstream.

Adrian

> [1] https://jenkins.debian.net/view/rebootstrap/

Devuan Jessie beta released

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

> 1- It is not possible to use uclibc or musl-libc with systemd.
Actually, it is possible with musl. I'm doing this RIGHT NOW and the required patchset is pretty tiny (around 200 lines). I haven't tried uclibc, though.

> 4- Both of us, current lead developers of Devuan, sources maintained in Debian on ARM and MIPS platforms for projects where security and reliability are critical factors.
LOL.

Critical factors

Posted May 3, 2016 9:06 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

Security and reliability being "critical factors" doesn't by any means imply that they're being treated seriously or that all reasonable steps are being taken to assure these "critical factors".

If the CFO of a big corporation says they're resigning because they "No longer have confidence that the company's reported financial position matches reality" the markets tank, key stockholders demand answers, the board will be obliged to make a statement (even if it only reinforces the doubt created by the CFO). But if their key security person, who may not even report directly into the board, but only to some VP or executive somewhere in the pyramid, reports that they're resigning because they've lost all confidence in the security precautions it passes almost without comment, indeed it may not even be reported in the financial press.

Security _Theatre_ is important to big corporations. Smart security guard uniforms, branded login warnings, frequent messages reminding all employees that security comes first (to be followed by messages saying the customer comes first, quality comes first, and safety comes first ...) these things are important, but actual security is at best an afterthought. If you thought individual humans were affected by the Dancing Pigs problem, you'll be amazed by how much it impacts a big corporation.

Devuan Jessie beta released

Posted May 5, 2016 16:00 UTC (Thu) by glaubitz (subscriber, #96452) [Link]

> Believe me when I say in the specific case of Devuan we are experiencing an overwhelming success and attention, without much fanfare and especially from non-english media.

All of these remarks you are making are nothing but hot air.

How about you actually provide sources to *any* of the bold claims you have made?

If you are maintaining your distribution the same way you are holding a discussion, then good night.

Adrian

it's amazing how threatened systemd advocates are by people who don't use systemd.

Posted May 2, 2016 20:38 UTC (Mon) by dlang (guest, #313) [Link] (3 responses)

It's not like Devuan is trying to prevent you from using systemd on your distro of choice, they are taking a distro (Debian) that offers systemd and making a variation that doesn't

Why is this such a Horrible/Evil thing for them to do?

Because it means that the systemd developers won't be able to change the entire Linux ecosystem at their whim??? If so, that by itself seems like a good enough reason for Devuan to exist.

it's amazing how threatened systemd advocates are by people who don't use systemd.

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

I don't think Devuan as a distribution is worth worrying about. Either they will happily continue in their niche or the effort will peter out eventually due to lack of interest from developers or users. One way or other, Devuan is not likely to change the world.

What annoys me more is the FUD the Devuan guys are trying to spread about systemd. They're basically rehashing myths that have been debunked over and over again, and trying to give a reasonable and useful (even if not perfect) piece of software a bad name just because they can't be bothered to look at it with an open mind (like many other people did, including the people who put together most mainstream Linux distributions). Of course by now they have put a lot of work into Devuan and cognitive dissonance probably prevents them from admitting to themselves that systemd might just possibly have something going for itself, but IMHO that doesn't really justify dissing it all over the place.

it's amazing how threatened systemd advocates are by people who don't use systemd.

Posted May 2, 2016 21:31 UTC (Mon) by dlang (guest, #313) [Link]

If you want to start discussing FUD, you'll have to also accept that systemd advocates/developers have produced at least their fair share as well.

You are far better leaving it alone and letting it die quietly (if that's what's going to happen) than by giving it all the attention of attacking it any time it's mentioned, just because you deem some of their opinions wrong, or based on incorrect arguments.

it's amazing how threatened systemd advocates are by people who don't use systemd.

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

I think part of it is that some people who work with or on systemd are upset by FUD that is being spread by some people, and there might be perceived overlap with folks who are running efforts like Devuan. So they don't object to a distro that chooses to exclude systemd per-se, but they do object to people spreading FUD.

systemd. dbus, udev, etc are sometimes a really nad idea

Posted May 2, 2016 22:52 UTC (Mon) by dps (guest, #5725) [Link] (20 responses)

On my laptop I use systemd, network manager and dbus. I have severe doubts about the utility of the latter because I just don't use facebook or twitter (but do use linkedin). Connecting to the local network and devices appearing when I insert a USB device are genuinely useful features.

I actively don't want kernel modules, dbus and udev within a mile radius of a stripped down firewall system. Anything that need dbus and udev can be ruled out, and that includes systemd. Unfortunately standard debian binaries need libdbus even on systems where is provably useless. A version of debian without dbus might offer a smaller minimum installation.

systemd. dbus, udev, etc are sometimes a really nad idea

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

Uhm, what does dbus has to do with Twitter?

systemd. dbus, udev, etc are sometimes a really nad idea

Posted May 3, 2016 0:47 UTC (Tue) by viro (subscriber, #7872) [Link]

*snerk*

Not sure what the original poster meant, but twitter *does* seem to be the mental model behind the dbus - event has happened when some berk has announced it, with its followers consuming the announcement (and possibly regurgitating it). Announcements are small, pointless, quite likely already obsolete, generally full of shit and the information obtained from those could normally be had in much easier ways than by sniffing the turds being propagated. Social shmedia at its usual, IOW...

systemd. dbus, udev, etc are sometimes a really nad idea

Posted May 4, 2016 20:44 UTC (Wed) by nix (subscriber, #2304) [Link] (17 responses)

I'm wondering why dynamic device discovery is something that's bad on a firewall, personally. They don't seem to connect.

systemd. dbus, udev, etc are sometimes a really nad idea

Posted May 4, 2016 21:30 UTC (Wed) by dlang (guest, #313) [Link] (16 responses)

> I'm wondering why dynamic device discovery is something that's bad on a firewall

attack surface.

If the firewall goes out and autodetects (and worse, automounts/enables) anything that gets plugged into it, you end up with a lot of new classes of potential vulnerabilities that don't exist if it just ignores the devices until told to look for them.

In theory, this won't make a difference, because your firewall is someplace that it physically protected...

"In Theory, Theory and Practice are the same, In Practice they are not"

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 4, 2016 22:01 UTC (Wed) by rahvin (guest, #16953) [Link] (15 responses)

Your firewall is absolutely worthless if random people can plug things into it. The first rule of computer security is physical security and no amount of software security can protect you from nefarious persons with direct and unfettered access to commodity hardware. It's just not designed for it.

That's beside the fact that you can blacklist certain hardware including everything that's not already there such that no driver or device will be loaded. And if you are going to that extreme you don't want to use a distribution, you want to hand roll everything to reduce your attack surface to minimal levels (no unneeded binaries) and if you need to do that you might as well go custom hardware as well and add secure memory and ASIC's that monitor the hardware. Honestly, you'd need some very good reasons (like DOD reasons) to do this because of the amount of work involved.

But for normal residential or small business (no credit card) you are probably fine with physically secured custom hardware and FW distribution, either one of the many Linux based ones or pfsense. The attack surface is reduced to the point that you aren't worth the time. It kinda like a zombie apocalypse, you don't need to be super fast, just faster than the other guy that's a better target (cardio).

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 4, 2016 23:28 UTC (Wed) by dlang (guest, #313) [Link] (14 responses)

quoting myself

> In theory, this won't make a difference, because your firewall is someplace that it physically protected...

> "In Theory, Theory and Practice are the same, In Practice they are not"

especially in a home or small business, you need to defend against people who don't know enough to not plug things into a device that you cannot practically lock away.

In datacenters, it's belt-and-suspenders protection. The type of thing that if you do it, you never needed to, but if you skip it, it would have saved you.

> That's beside the fact that you can blacklist certain hardware including everything that's not already there such that no driver or device will be loaded.

Isn't it easiest to just disable auto-probing rather than blacklisting the world?

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 0:26 UTC (Thu) by pizza (subscriber, #46) [Link] (13 responses)

> especially in a home or small business, you need to defend against people who don't know enough to not plug things into a device that you cannot practically lock away.

What exactly is the threat vector here?

Maybe I lack sufficient imagination, but all I can come up with is that if someone already knows enough information about your firewall box's software configuration to know how to pwn it by merely getting someone to plug in a particular USB widget, then it's far too late; someone has already pwn3d you.

Meanwhile, If someone's going to break into your [home]office to go after your specific data (as opposed to something more generally valuable, like cash/jewelry/etc), they're going to just take the equipment with them. Or maybe image the drives if they want to be sneaky. Or plant recording devices to get your login information if they want to get sneakier. Or just beat it out of you if they're in a hurry.

> Isn't it easiest to just disable auto-probing rather than blacklisting the world?

It seems to me that the most bang-for-the-buck approach is to properly secure the door to your server/telecom closet and be quite stingy with the keys.

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 8:35 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

What exactly is the threat vector here?

Come on. Have someone revoked your Google access? First link I've found. Second one. Third. And more recent.

Some of these could be prevented by refusal to talk to some random hardware, some couldn't, but the general flaw is always the same: it's always the battle of "security vs convenience" and security rarely wins.

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 10:38 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

What do any of those examples have to do with an attack that requires *physical* access to your firewall? And, going back to my point, an attack that, in order to be successful, requires knowledge only obtainable if you have already completely compromised everything already?

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 19:45 UTC (Thu) by dlang (guest, #313) [Link]

so you say that people should not be able to defend themselves against an attach scenario that you deem invalid.

Why should your judgement trump everyone else's?

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 8:47 UTC (Thu) by dlang (guest, #313) [Link] (9 responses)

if you want me to spin scenarios, preventing your <insert non-technical relative> from taking a USB stick they picked up off the sidewalk and plugging it into the AP in the living room and having it hack your firewall.

not all firewalls live in a "server/telecom closet"

In small businesses, the router/firewall probably lives on the owner's desk in the back office.

You need to be substantially larger, or a computer-centric business to have things organized enough to have your servers in a dedicated space rather then just on/under someone's desk.

plugging things into servers

Posted May 5, 2016 10:17 UTC (Thu) by itvirta (guest, #49997) [Link] (8 responses)

If they're bound to plug random attack sticks in, they'll just do it with some application server or a workstation
even if the firewall is locked away or ignores any plugged-in devices. Those probably have easier access to any
sensitive data you may have, anyway, so I'd say the main problem is the fact that someone can/will plug nefarious
devices in.

Sure, the firewall is special in that it could block any traffic going outside, but can you do any work then if WWW doesn't work?

plugging things into servers

Posted May 5, 2016 10:56 UTC (Thu) by pizza (subscriber, #46) [Link] (7 responses)

> If they're bound to plug random attack sticks in, they'll just do it with some application server or a workstation
even if the firewall is locked away or ignores any plugged-in devices. Those probably have easier access to any
sensitive data you may have, anyway, so I'd say the main problem is the fact that someone can/will plug nefarious
devices in.

My point exactly. The firewall is nowhere near the most attractive target for clandestine nefarious activity, and not worth even bothering with if the attacker is willing (or able) to be overt about attacking you.

plugging things into servers

Posted May 5, 2016 13:13 UTC (Thu) by jrigg (guest, #30848) [Link] (6 responses)

> The firewall is nowhere near the most attractive target for clandestine nefarious activity

So the fact that it carries all traffic in or out of the internal network doesn't it make it attractive?

plugging things into servers

Posted May 5, 2016 17:51 UTC (Thu) by edgewood (subscriber, #1123) [Link] (5 responses)

For someone with physical access to the computers of a personal or small business (ie, an entity that doesn't have a "server closet")? What's the motive of someone who has that physical access to the location, but doesn't want to steal, clone, or subvert the computers with the actual personal or business data on them?

plugging things into servers

Posted May 5, 2016 20:37 UTC (Thu) by jrigg (guest, #30848) [Link] (1 responses)

> What's the motive of someone who has that physical access to the location, but doesn't want to steal, clone, or subvert the computers with the actual personal or business data on them?

Surveillance?

plugging things into servers

Posted May 5, 2016 22:06 UTC (Thu) by dlang (guest, #313) [Link]

take control of the firewall so that they can get in remotely later to do other stuff??

plugging things into servers

Posted May 6, 2016 14:06 UTC (Fri) by itvirta (guest, #49997) [Link] (2 responses)

Apart from the boring legal stuff like doing the work you are paid to do, one could
- steal everything that looks valuable, including the hardware
- burn the place down just out of spite
- analyse traffic passing through the firewall to see how much they use Facebook from work. The connections are probably encrypted,
so you can't get anything interesting about the contents. Unless there's a TLS-decrypting middleman on the firewall already,
but people who worry about udev on their firewall don't strike me as the type to do that...

plugging things into servers

Posted May 6, 2016 16:17 UTC (Fri) by jrigg (guest, #30848) [Link] (1 responses)

One person's paranoia is another's sensible caution. Maybe we should just leave it there.

plugging things into servers

Posted May 9, 2016 21:59 UTC (Mon) by pizza (subscriber, #46) [Link]

I don't disagree, but either way it strikes me as wise to perform a risk assessment.

There's a very real cost to implementing security measures, and one should focus on the measures that mitigate the attacks most likely to occur, and the ones most costly to recover from. (And don't forget the "from what/whom" question too..)

From:		Veteran Unix Admins <onelove-AT-devuan.org>
To:		dng-AT-lists.dyne.org
Subject:		Devuan Jessie - beta release announcement
Date:		Fri, 29 Apr 2016 13:32:25 +0200
Message-ID:		<20160429113225.GA7559@reflex>
Archive‑link:		Article

Devuan Jessie beta released

don't feed the trolls

don't feed the trolls

don't feed the trolls

don't feed the trolls

don't feed the trolls

don't feed the trolls

don't feed the trolls

don't feed the trolls

don't feed the trolls

don't feed the trolls

don't feed the trolls

does anybody else find it ironic...

does anybody else find it ironic...

does anybody else find it ironic...

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

:applause emoji:

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released

Devuan Jessie beta released