Devuan Jessie beta released

Posted May 2, 2016 11:36 UTC (Mon) by darwish (guest, #102479)
In reply to: Devuan Jessie beta released by linuxrocks123
Parent article: Devuan Jessie beta released

> 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 ..

to post comments

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)