Choosing the Server product on upgrade will install the Server packages, including its firewall configuration and Cockpit, because...that's Server. If you just want to keep the existing packages you have installed, choose 'nonproduct'. You can remove Cockpit if you don't want it.
Correct, it's not considered to be one of the Products. It's just Fedora.
There isn't one, the Cinnamon maintainer doesn't want to make one, for some reason. You can install from the 'Server' netinst and choose the Cinnamon package set, though, that'll work fine.
it doesn't 'clean' anything. it switches to a new file, and whenever you read the journal, reads as much data as it can from the corrupted file.
of course it doesn't. it has sensible maximum file sizes (both in terms of absolute size and percentage of the filesystem they're on).
"This means it wont find and grubify existing OS installs, including windows. "
No, it doesn't. We test that. It works fine. It uses os-prober, see
Fedora Release Day Drinking Game: At least two idiotic comments about systemd in the first five on
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
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?
For God's sake, stop researching for a while and begin to think!
