A Fedora community member releases periodic respins of Fedora stable releases; they're not official releases and they don't go through QA but FWIW I'd trust the guy if I needed a respun image in a pinch. http://jbwillia.wordpress.com/ is his site, you can find the spins at https://alt.fedoraproject.org/... .

well, ultimately the init system launches *everything* if you take a broad enough view of things, but that doesn't mean the init system is somehow responsible for your desktop environment's display configuration.

I mean, if you're really determined to, you can 'configure' things by modifying their init scripts, sure, but it's usually not the right way to do it. X has a perfectly good configuration system already. So does GNOME. If you want to change the DPI at one or other of those levels, go configure it through their configuration systems. That's how it's supposed to work.

That's far too reductionist. For a start, there are many sysv-compatible init implementations that do parallel boot; upstart does it, Mandriva's pinit does it. There's a whole subset of LSB that exists exclusively to provide a way for sysv initscripts to represent dependencies *precisely in order to enable parallel init* - see https://wiki.debian.org/LSBIni... for a good write-up of that.

Secondly, insofar as systemd is intended to improve boot speeds, it wasn't actually just about implementing simple parallelization of sysv-style services using dependencies. If you read http://0pointer.de/blog/projec... it talks a lot about parallelization but it's actually talking about making *more* parallelization possible, not just *implementing* parallelization: the big idea Lennart had back then was the idea that you don't actually have to completely start up a service in order to start up another service that 'requires' it, if you can create the socket it listens on before it's ready, then queue up any requests and pass them on to the service once it's actually done starting up. Lennart was clearly really excited about this idea at the time, but if you look at systemd these days, it's a really pretty small corner of all the things it does.

All the way through the first part of that first post, Lennart is really talking about making more parallelization possible, he's not simply talking about implementing inter-service dependencies.

These days systemd does an awful lot more, and it really isn't just about making boot faster any more. Even in the very first post, once you get past the first half, it starts talking about improved capabilities. I find startup speed the least interesting thing about systemd, really, I'm much more interested in the improved capabilities for units and especially in the improved logging journald provides.

"Since RedHat's obviously the largest major proponent"

For the record, there's absolutely nothing 'obvious' about that. People tend to assume that since Lennart was @redhat.com when he wrote systemd it's 'obviously' a Red Hat project, but it really isn't, and never was. It's a Lennart project: he came up with the idea and he wrote it. Red Hat didn't ask for it, didn't actually have any idea it was coming.

The very first instance of all these battles that get fought every six weeks in some distro or on /. or on Phoronix happened in Fedora, when Lennart first proposed switching to systemd. Around the same time / a bit later, all the same battles happened within Red Hat. Just as with every other distro, systemd's proponents brought the idea and argued for it. systemd wasn't planned from the top down by 'Red Hat authorities' as 'our new init system', Lennart came up with it on his own, and convinced the plurality of significant folks/bodies within Fedora and RHEL that it was a good idea.

Um. What? Display DPI is nothing the system init daemon cares about and never *has* been.

It can be set at the X level or at the desktop environment level. Some desktops respect X's setting, some ignore it.

In GNOME you can set both text scaling and full display scaling (the new thing used for hi-dpi screens) in GNOME Tweak Tool. Text scaling is in Fonts, it's the 'Scaling Factor' - if you think about things in DPI terms, just consider the 'scaling factor' to be a multiple of 96, e.g. if you want to set 110 DPI, set it to 1.14.

If you mean GNOME's decided your display is hidpi and starting scaling *everything*, that's the 'Window scaling' setting on the Windows tab, set it to 1 (which is no scaling).

Again, none of this has the slightest thing to do with init.

The article continues:

"It was described to me by the computer experts I consulted with afterwards that that was purely an attempt to let me know that they could do that, that they were watching, that they were in my computer."

Not saying that interpretation is correct, but it does seem reasonable to point out that she does in fact have a response to your objection.

There's no abuse there. He doesn't say a thing about the presenter personally, just corrects stuff that's in his slide, then says that sometimes what's written on web pages isn't true. Which bit of that did you think was abusive?

It's been running under 'real-world conditions' for years already - do you think no-one runs real-world systems on Fedora, or that Red Hat doesn't run releases in production internally before they go out, or that RH has no customers who test pre-releases?

"Seems to me that's the largest reason it's being pushed"

Nope. I think this impression originally came from Lennart's original post on systemd, years and years ago - http://0pointer.de/blog/projec... - because it starts out talking about boot speed. But even that very first post moves on, in the sections "Keeping Track of Processes" and later, to talk about the really interesting bits of systemd - better service management, and more capable service configuration. As systemd development continued, it's become much more about the latter and much less about boot times - I think that's where Lennart *started* thinking about systemd, but it's really not what systemd is for any more. Red Hat certainly wasn't interested in systemd because it might make servers boot three seconds faster, RH was interested because it can make service management on servers much better.

https://access.redhat.com/docu... is a rather comprehensive and good guide to the changes in RHEL 7 for RHEL sysadmins. One thing you'll learn from it is that RHEL 7 logs to text via rsyslog (as a journald consumer) *by default*.

"anyone sane have to scream NOOOO upon learning it will be Lennart doing the implementation."

Except he isn't. /. is just assuming he is, because they don't understand that more than one person works on systemd.

Because the people doing the damn work to fix it decided systemd was the sensible place to do it. If you'd rather it be somewhere else, why not write it somewhere else?

"The only things I use Linux for anymore is for my personal file server in my basement, and even that is running old Fedora 17."

so...it's running a rather early version of systemd, and apparently working fine, because you haven't seen a need to upgrade it?

"Oh hey, just what I wanted BINARY LOGS THAT BREAK ALL MY EXISTING AUTOMATION."

systemd is designed to make it trivially simple to have text logs if you want that. RHEL 7 is configured by default to do permanent logging in plain text format via rsyslog; the native journald logs aren't even permanently stored by default (this is the config that was in Fedora for a while before journald's native format became the default/primary).

https://access.redhat.com/docu...

I am starting to suspect you're a troll and haven't actually used RHEL 7 at all.

"Systemd by design tries to mount nfs shares, before it even starts up the network, out of the box!"

Um. No it doesn't. Who told you that?

"Systemd supresses everything unless you tell it to."

No it doesn't. Who told you that?

um. what? people have been updating sytems that use systemd for, what, four years now? amazingly enough, it actually works, we don't just all watch our systems crash and reboot every time.