"I'll give it another test later in a VM but so far as I could see I couldn't precreate the partitions as I wanted via gparted/parted and tell it to use those either which would help advanced cases..."
Actually you can: existing partitions are shown on the left hand side of the custom partitioning screen, you can select them and change settings for them on the right hand side, including setting a mount point for them. You can just pick one and set '/' or '/home' or whatever as the mount point, and it will do what you'd expect. When you hit Update Settings you should see the partition appear as part of the 'new Fedora 19 installation' group.
" Specifically it being mandatory to have/boot and/boot/efi on different partitions was painful on my Macbook Pro 8,2 (admittedly an edge case)"
that's a requirement of the UEFI spec. The EFI system partition is quite carefully defined in there. You can't just have it be shared with a Linux/boot partition.
"Oh come now. journalctl is nothing but a tool to format up a snapshot of the journal so it looks like a proper ASCII logfile."
I think you misunderstood what I was demonstrating - I was both running journalctl and showing a 'normal' ASCII log file to demonstrate that journald and rsyslog can (and do) happily run together.
"And the point that if you are doing forensics you have to find the RIGHT VERSION of journalctl to parse the binary files is well taken."
It's not correct, though. In fact, exactly the opposite is true: they're aiming to ensure that just about any version of journalctl can parse any version of the log file. The case where you need to analyze logs from a different system was explicitly considered in the initial design.
Don't you want to know whether the processes associated with a service are running, exited successfully, exited unsuccessfully, etc? sysv is bad at that ('service foo status' is very basic and dependent on the initscript in question). systemd is much better.
Don't you want to be able to start services or not conditionally? This is fantastically useful; we're using it all over the place in Fedora. We only start the iscsi service if there are actually iscsi nodes available, for instance. You can make service startup conditional on the presence or absence of a file, directory or command line parameter, or whether the system is running under virtualization or not, or various other conditions.
Don't you want to be able to say 'let me see all the logs associated with this service'? systemd and journald together allow you to do that.
Don't you want to be able to have services activate on demand rather than just all running at startup? systemd does that. services can be set to activate when they're accessed, via a port or a socket.
and on, and on, and on. Really, just read up on the various blog posts, systemd website pages etc which explain the oodles of features systemd brings to the table. They are really useful.
F19 anaconda is massively improved from F18's. I do wish people would quit moaning about F18's in a thread about F19 and just try the damn F19 installer already...
"If I have a sysv deamon that has to start AFTER service X and BEFORE service Y, and X and Y is now started by systemd, I can't do that without editing the startup for X and/or Y. A prime example is network before nis before av software before mta before daemons that use the mta. Change the AV software to one that uses sysv init, and you have a headache."
Well, sure, but that's impossible to fix for the numerical ordering case, really. systemd is a dependency-based init system, not an ordering-based one.
What you should check, though, is whether systemd respects the LSB dependency extension to sysv init scripts (where you specify Provides, Default-Start, Default-Stop, Required-Start, Required-Stop etc in comments at the top of the init script). If so, it should be possible to express dependencies on native systemd units from sysv init scripts, probably. If not, perhaps the feature should be added...
Lots of RHEL admins *love* the new features of systemd and have been demanding them for years. systemd is as useful or more useful for 'servers' than for any other use case. Why do you think RH is pushing the development of systemd if not to benefit our customers?
"When Sun or Microsoft introduce(d) something they fix the rest of the OS properly as a condition of it being added."
We (RH) have not shipped a RHEL release with systemd included yet. Fedora has shipped several releases with systemd included, progressively improving its features, fixing bugs, and improving compatibility with key use cases as it has gone along.
"But F18 was a disaster from the first second I began with it, when I discovered they would not allow F16 to upgrade when they've always supported two versions back"
"This is the recommended method to upgrade your Fedora system to Fedora 18 and newer. Note that FedUp is only available in Fedora 17 and later. Thus users who are currently running Fedora 16 or earlier, will first need to upgrade to Fedora 17 using another method before being able to use FedUp to upgrade to Fedora 18 or later."
"and then I discovered it wouldn't boot from the DVD and I had to leave my computer downloading a million RPM files overnight when I had burned a DVD image"
Yes, of course, Fedora 18 doesn't boot from a DVD. That's why there were all those outraged news articles about it and the pitchfork-toting mobs in the street.
Wait, no, F18 boots fine from a DVD. We tested it. No news articles. No mobs. I can believe there might be some weird bug which prevents it working properly on some specific hardware, but generally, the F18 DVD boots just fine. I tested it myself.
"Until a few minutes ago, when I had a kernel panic and a reboot after updating 900 packages this morning. I thought I'd waited long enough for a buggy kernel to be replaced with a good one."
Fedora, being a cutting-edge distro, rebases the kernel on currently stable releases to the latest stable upstream kernel each time a new upstream release happens. Yes, this can occasionally cause problems, and sorry it did so for you. But it fits in with the nature of what Fedora is for, it does not cause problems for most users (in fact on balance it usually fixes more problems than it causes), and the kernel team does work hard to fix any bugs that are reported at the time of the rebase. See e.g. http://codemonkey.org.uk/2013/05/21/a-day-in-the-life/ "Looked at bugzilla backlog. Swore a lot. 3.9.x rebase bugs started to trickle in" and http://codemonkey.org.uk/2013/05/24/daily-log-may-24th-2013/ "Looked at a bunch of “can’t boot” bugs that came in since F18 got rebased to 3.9. Found a thread upstream that seems to be discussing the same bug."
If you want a long-term stable distribution for production use in critical cases, Fedora is probably not the distribution for you. But no, it is not "a perverse, sadistic force of pure evil". I don't wake up in the morning and go 'aha, who can we piss off today'. We are trying to drive forward the development of F/OSS, constantly, and that requires a level of churn and major change.
"If you run an installer that you've been running for years that plops the appropriate symlinks into rcN.d, will it start working? No, you have to jump through hoops to get it to work."
It should, yes. What was 'N' in this case? What hoops are you referring to? systemd is designed to start up sysv init scripts that are in the appropriate locations, in the order specified.
"And how are runlevels not broken when I type "init 2" and network services continue to run?"
Ah, I see. Let's say something that is more accurate than what either of us said initially: systemd is partly but not entirely backwards compatible with sysv runlevels. To be specific, it implements runlevels 1, 3 and 5, which were by far the most commonly used sysv runlevels. systemd's equivalent of 'runlevel 1' is basic.target , and if you do 'init 1' you'll get that. Its equivalent of 'runlevel 3' is multi-user.target, and init 3 will get you that. Its equivalent of 'runlevel 5' is graphical.target, and init 5 will get you that. But yes, you are correct to say that there is not an equivalent to / compatibility for runlevel 2, AFAIK.
".ini files also defeat standard system tools like grep and sed. Parsing them without a dedicated parser is non-trivial, because the context changes based on the section."
I'm not sure what you're trying to say here. It gets annoying when criticisms of systemd are extremely non-specific and seem to boil down to 'I can't use it exactly the way I used sysv'. What precisely is it that you're trying to achieve that you don't think you can achieve with systemd?
"Mr. Poettering seems to make many of the same choices over and over again -- not because they're in any way the obvious choice, but because it's what he's used to."
Again, this seems kind of slippery. Can you provide some kind of detail? What choices are you talking about? And what do you mean by 'used to'? It's not like systemd existed, Lennart got used to using it, and then he forced it on everyone else. He wrote it. He wasn't 'used to' it either.
"If this flies in the face of 20-30 years of sysadmin experience he then refuses to consider why things were done a certain way"
Well, no, he certainly does. If you read any of the background to systemd's design, it is very clear that he is intimately familiar with how sysv works, and there are specific justifications for all of systemd's design choices.
The 'flies in the face of 20-30 years of sysadmin experience' thing is a trap. It is very similar to the scientific convention that a hypothesis that cannot be falsified is useless. *Any* new init system will by definition 'fly in the face of 20-30 years of sysadmin experience', so by bringing out this argument, you are effectively saying 'we must use SysV forever because we have used it for so long': you are denying the possibility that we could possibly ever design a better init system than SysV, for no reason other than 'we've been using SysV for a long time'.
"it's always his way or the highway, with less choices as the end result."
I don't see that at all. Lots of changes have been made to systemd in response to feedback, and systemd offers vastly _more_ 'choices' than sysv ever did; that's the point of the complexity that people are always moaning about, to allow it to _do more stuff_. If your request is 'stop making systemd and make sysv instead', then yes, it's 'Lennart's way or the highway'.
Sure, I'm not debating that there's a bug with your specific use case, or even that the devs said they wouldn't fix it. I'm not familiar with the details of your case. I'm just saying that you generalized out far too much from your experience. If you provide a link to the bug report or whatever where you were told this wouldn't be fixed, I'll have a look.
It's just not true to generalize from your experience and say that NM doesn't work with or care about anything other than ethernet/wifi, though, because that's just not true. Heck, I use it to connect via my phone using Bluetooth sharing.
ah, OK. try it with qxl/Spice if that's possible. It'll probably go better (though it'll depend on what your host is to a degree). I don't know if the behaviour of virt-install is planned to be changed.
1. All progress bars are lies. 2. The anaconda re-design was prompted precisely by the fact that the old anaconda had terrible usability. It was neither simple nor easy-to-use. As you're interested in usability, please read all posts here:
If you go back a ways, you will find lots of detailed explanation on the usability problems of oldUI. Moving forward you will find lots of detailed discussion on the process of designing newUI and the reasons it was designed the way it was. The old partitioning screen had substantial problems, and many of the results you could get from it were by no means obvious at all.
3. GNOME is gradually converting its applications to put some menu actions in the 'global' menu on the top panel; this is where you will find the actions you thought were 'missing'. Indeed this will mean some apps are inconsistent with others until the conversion is completed. Fedora ships upstream GNOME with virtually no configuration changes at all. If you don't like GNOME, there are many other options to choose from in Fedora. KDE is supported on an equal basis with GNOME in Fedora.
"It uses old MSDOS ini files (who the fsck thought that was a good idea?)"
It is a very good idea, because it allows the status of a service to be tracked reliably, and it allows all sorts of configuration of the behaviour of services which is not possible, or possible only in very ugly and hacky ways, using pure shell scripts.
See 'man systemd.unit'.
I really don't understand why people assume that the systemd developers just decided to invent complexity for the hell of it, or something, in the face of the extensive evidence to the contrary. If you're going to criticize systemd, at _least_ read its documentation and understand the reasons for the way it is designed the way it is designed. Just saying 'it's designed differently and that's obviously bad!' is ludicrous.
"I agree that systemd is very bad, but even worse is journald which replaces traditional syslog with a binary logging format."
No, it does not.
[root@adam tmp]# journalctl -- Logs begin at Fri 2013-03-08 13:04:50 PST, end at Tue 2013-05-28 13:18:06 PDT Mar 08 13:04:50 localhost systemd-journal[116]: Allowing runtime journal files t Mar 08 13:04:50 localhost kernel: Initializing cgroup subsys cpuset
(etc etc etc)
[root@adam tmp]# head -5/var/log/messages May 26 10:39:15 adam rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="559" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
(etc etc etc)
journald is *an* implementation of a system logging daemon. It is not the only implementation. It is not an exclusive implementation.
You can run as many system logging daemons as you like. Fedora is currently configured to run both rsyslogd and journald. System log messages go to both and you can inspect them however you like.
In future we may configure Fedora to only run journald by default, but this does nothing to prevent you running rsyslogd as well as journald, or instead of journald, or running any other system logging daemon that you like. The Linux system logging infrastructure is explicitly set up so that logging daemons are interchangeable and can be run concurrently. journald is written to respect that: it is one system logging daemon among many and works fine alongside others, and systemd works fine without journald if you decide you don't want it.
"Then, they changed to systemd - a dual layer abstraction abomination for services and configurations, incompatible with the runlevel and init.d scripts that admins have and rely on."
That's impressive; you've written a two line description of systemd which is incorrect in every particular.
It is not a 'dual layer abstraction', it is not incompatible with runlevels, and it is not incompatible with init.d. On the contrary, it was explicitly written with compatibility for both of those things.
"As for Network Manager, try running it with any USB networking (direct connect, like with a phone, rather than an USB-connected ethernet card): it will kill the interface every roughly 30 seconds. Its upstream refused to fix that saying they don't aim to support every possible device."
That's a massive over-simplification. NM works very hard to support connections over phones, 3G/LTE modems and the like, as Dan Williams' blog makes very clear, if you bother to read it.
"Its upstream refused to fix that saying they don't aim to support every possible device. Or, bridged setups. Or, basically anything more complex than a plain ethernet or wifi interface."
This is not correct at all. As Dan wrote on devel list just May 16th:
"It didn't used to be very compatible with server-type networking, but that's exactly what we've been working hard on for the past year or so. Bonding, bridging, VLANs, an Infiniband are all supported by the current NetworkManager 0.9.8, though it doesn't (yet) cooperate well when external tools touch things. That's going to get a lot better quite soon. The 0.9.8 GUI and nmcli both have support for all of the aforementioned interface types."
Seriously: you really think *Red Hat* would bother spending several years of engineer time writing a network management layer which didn't support 'anything more complex than a plain ethernet or wifi interface'? We're not that idiotic.
What graphics configuration did you have in your KVM? We test it on qxl/SPICE, mostly, because that's by a long way the best option. the old-school cirrus/VNC doesn't get a lot of testing and can be broken at times. vga/VNC worked okay last time I tried it.
F19 has GNOME, KDE, LXDE, Xfce, MATE and Sugar live spins, and Cinnamon available from the DVD. NetworkManager is still optional, as it has been since its introduction. And systemd is awesome.
" The cool kids are moaning about the half-assed and feature-very-much-incomplete FirewallD (from essentially the same people that brought you SystemD)"
by which, presumably, you mean 'entirely different people'? Since systemd was started by Lennart Poettering and now maintained by him, Kay Sievers and a few others, while firewalld was started by Thomas Woerner and is now maintained by him and Jiri Popelka? So, you know, zero overlap.
firewalld has been in Fedora since F17 and was made the default in F18, so it's hardly the fashionable new thing to bitch about either. It is still entirely optional: if you don't like it, just remove it and you can happily use iptables (or nothing) instead. I'm not sure where you see it as being 'half-assed and feature-very-much-incomplete' as it stands in F19, firewall-cmd in particular appears to be capable of just about everything under the sun, including passing arbitrary config statements through to iptables.
Slashdot Mirror
OP said "Nicolas Sarkozy, the worst criminal this country has ever known". Nothing about 'president', 'Emperor' or elections was specified.
And yet the original wasn't called humanball, and whatever drugs are involved, the game still definitely involves bases.
"I'll give it another test later in a VM but so far as I could see I couldn't precreate the partitions as I wanted via gparted/parted and tell it to use those either which would help advanced cases..."
Actually you can: existing partitions are shown on the left hand side of the custom partitioning screen, you can select them and change settings for them on the right hand side, including setting a mount point for them. You can just pick one and set '/' or '/home' or whatever as the mount point, and it will do what you'd expect. When you hit Update Settings you should see the partition appear as part of the 'new Fedora 19 installation' group.
" Specifically it being mandatory to have /boot and /boot/efi on different partitions was painful on my Macbook Pro 8,2 (admittedly an edge case)"
that's a requirement of the UEFI spec. The EFI system partition is quite carefully defined in there. You can't just have it be shared with a Linux /boot partition.
"Oh come now. journalctl is nothing but a tool to format up a snapshot of the journal so it looks like a proper ASCII logfile."
I think you misunderstood what I was demonstrating - I was both running journalctl and showing a 'normal' ASCII log file to demonstrate that journald and rsyslog can (and do) happily run together.
"And the point that if you are doing forensics you have to find the RIGHT VERSION of journalctl to parse the binary files is well taken."
It's not correct, though. In fact, exactly the opposite is true: they're aiming to ensure that just about any version of journalctl can parse any version of the log file. The case where you need to analyze logs from a different system was explicitly considered in the initial design.
More powerful than sysv, at least. For instance:
Don't you want to know whether the processes associated with a service are running, exited successfully, exited unsuccessfully, etc? sysv is bad at that ('service foo status' is very basic and dependent on the initscript in question). systemd is much better.
Don't you want to be able to start services or not conditionally? This is fantastically useful; we're using it all over the place in Fedora. We only start the iscsi service if there are actually iscsi nodes available, for instance. You can make service startup conditional on the presence or absence of a file, directory or command line parameter, or whether the system is running under virtualization or not, or various other conditions.
Don't you want to be able to say 'let me see all the logs associated with this service'? systemd and journald together allow you to do that.
Don't you want to be able to have services activate on demand rather than just all running at startup? systemd does that. services can be set to activate when they're accessed, via a port or a socket.
and on, and on, and on. Really, just read up on the various blog posts, systemd website pages etc which explain the oodles of features systemd brings to the table. They are really useful.
F19 anaconda is massively improved from F18's. I do wish people would quit moaning about F18's in a thread about F19 and just try the damn F19 installer already...
"If I have a sysv deamon that has to start AFTER service X and BEFORE service Y, and X and Y is now started by systemd, I can't do that without editing the startup for X and/or Y. A prime example is network before nis before av software before mta before daemons that use the mta. Change the AV software to one that uses sysv init, and you have a headache."
Well, sure, but that's impossible to fix for the numerical ordering case, really. systemd is a dependency-based init system, not an ordering-based one.
What you should check, though, is whether systemd respects the LSB dependency extension to sysv init scripts (where you specify Provides, Default-Start, Default-Stop, Required-Start, Required-Stop etc in comments at the top of the init script). If so, it should be possible to express dependencies on native systemd units from sysv init scripts, probably. If not, perhaps the feature should be added...
Lots of RHEL admins *love* the new features of systemd and have been demanding them for years. systemd is as useful or more useful for 'servers' than for any other use case. Why do you think RH is pushing the development of systemd if not to benefit our customers?
"When Sun or Microsoft introduce(d) something they fix the rest of the OS properly as a condition of it being added."
We (RH) have not shipped a RHEL release with systemd included yet. Fedora has shipped several releases with systemd included, progressively improving its features, fixing bugs, and improving compatibility with key use cases as it has gone along.
I think you can see where I'm going with this.
I know what you mean, dude. 36 years ago the supermarket down the street gave me short change. I've never been back since.
"But F18 was a disaster from the first second I began with it, when I discovered they would not allow F16 to upgrade when they've always supported two versions back"
https://fedoraproject.org/wiki/Upgrading :
"This is the recommended method to upgrade your Fedora system to Fedora 18 and newer. Note that FedUp is only available in Fedora 17 and later. Thus users who are currently running Fedora 16 or earlier, will first need to upgrade to Fedora 17 using another method before being able to use FedUp to upgrade to Fedora 18 or later."
"and then I discovered it wouldn't boot from the DVD and I had to leave my computer downloading a million RPM files overnight when I had burned a DVD image"
Yes, of course, Fedora 18 doesn't boot from a DVD. That's why there were all those outraged news articles about it and the pitchfork-toting mobs in the street.
Wait, no, F18 boots fine from a DVD. We tested it. No news articles. No mobs. I can believe there might be some weird bug which prevents it working properly on some specific hardware, but generally, the F18 DVD boots just fine. I tested it myself.
"Until a few minutes ago, when I had a kernel panic and a reboot after updating 900 packages this morning. I thought I'd waited long enough for a buggy kernel to be replaced with a good one."
Fedora, being a cutting-edge distro, rebases the kernel on currently stable releases to the latest stable upstream kernel each time a new upstream release happens. Yes, this can occasionally cause problems, and sorry it did so for you. But it fits in with the nature of what Fedora is for, it does not cause problems for most users (in fact on balance it usually fixes more problems than it causes), and the kernel team does work hard to fix any bugs that are reported at the time of the rebase. See e.g. http://codemonkey.org.uk/2013/05/21/a-day-in-the-life/ "Looked at bugzilla backlog. Swore a lot. 3.9.x rebase bugs started to trickle in" and http://codemonkey.org.uk/2013/05/24/daily-log-may-24th-2013/ "Looked at a bunch of “can’t boot” bugs that came in since F18 got rebased to 3.9. Found a thread upstream that seems to be discussing the same bug."
If you want a long-term stable distribution for production use in critical cases, Fedora is probably not the distribution for you. But no, it is not "a perverse, sadistic force of pure evil". I don't wake up in the morning and go 'aha, who can we piss off today'. We are trying to drive forward the development of F/OSS, constantly, and that requires a level of churn and major change.
"If you run an installer that you've been running for years that plops the appropriate symlinks into rcN.d, will it start working?
No, you have to jump through hoops to get it to work."
It should, yes. What was 'N' in this case? What hoops are you referring to? systemd is designed to start up sysv init scripts that are in the appropriate locations, in the order specified.
"And how are runlevels not broken when I type "init 2" and network services continue to run?"
Ah, I see. Let's say something that is more accurate than what either of us said initially: systemd is partly but not entirely backwards compatible with sysv runlevels. To be specific, it implements runlevels 1, 3 and 5, which were by far the most commonly used sysv runlevels. systemd's equivalent of 'runlevel 1' is basic.target , and if you do 'init 1' you'll get that. Its equivalent of 'runlevel 3' is multi-user.target, and init 3 will get you that. Its equivalent of 'runlevel 5' is graphical.target, and init 5 will get you that. But yes, you are correct to say that there is not an equivalent to / compatibility for runlevel 2, AFAIK.
".ini files also defeat standard system tools like grep and sed. Parsing them without a dedicated parser is non-trivial, because the context changes based on the section."
I'm not sure what you're trying to say here. It gets annoying when criticisms of systemd are extremely non-specific and seem to boil down to 'I can't use it exactly the way I used sysv'. What precisely is it that you're trying to achieve that you don't think you can achieve with systemd?
"Mr. Poettering seems to make many of the same choices over and over again -- not because they're in any way the obvious choice, but because it's what he's used to."
Again, this seems kind of slippery. Can you provide some kind of detail? What choices are you talking about? And what do you mean by 'used to'? It's not like systemd existed, Lennart got used to using it, and then he forced it on everyone else. He wrote it. He wasn't 'used to' it either.
"If this flies in the face of 20-30 years of sysadmin experience he then refuses to consider why things were done a certain way"
Well, no, he certainly does. If you read any of the background to systemd's design, it is very clear that he is intimately familiar with how sysv works, and there are specific justifications for all of systemd's design choices.
The 'flies in the face of 20-30 years of sysadmin experience' thing is a trap. It is very similar to the scientific convention that a hypothesis that cannot be falsified is useless. *Any* new init system will by definition 'fly in the face of 20-30 years of sysadmin experience', so by bringing out this argument, you are effectively saying 'we must use SysV forever because we have used it for so long': you are denying the possibility that we could possibly ever design a better init system than SysV, for no reason other than 'we've been using SysV for a long time'.
"it's always his way or the highway, with less choices as the end result."
I don't see that at all. Lots of changes have been made to systemd in response to feedback, and systemd offers vastly _more_ 'choices' than sysv ever did; that's the point of the complexity that people are always moaning about, to allow it to _do more stuff_. If your request is 'stop making systemd and make sysv instead', then yes, it's 'Lennart's way or the highway'.
Sure, I'm not debating that there's a bug with your specific use case, or even that the devs said they wouldn't fix it. I'm not familiar with the details of your case. I'm just saying that you generalized out far too much from your experience. If you provide a link to the bug report or whatever where you were told this wouldn't be fixed, I'll have a look.
It's just not true to generalize from your experience and say that NM doesn't work with or care about anything other than ethernet/wifi, though, because that's just not true. Heck, I use it to connect via my phone using Bluetooth sharing.
ah, OK. try it with qxl/Spice if that's possible. It'll probably go better (though it'll depend on what your host is to a degree). I don't know if the behaviour of virt-install is planned to be changed.
systemd is extremely well documented:
http://www.freedesktop.org/software/systemd/man/
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks/
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
http://freedesktop.org/wiki/Software/systemd/Debugging
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities
what the heck could you possibly be missing?
1. All progress bars are lies.
2. The anaconda re-design was prompted precisely by the fact that the old anaconda had terrible usability. It was neither simple nor easy-to-use. As you're interested in usability, please read all posts here:
http://blog.linuxgrrl.com/category/fedora/anaconda/
If you go back a ways, you will find lots of detailed explanation on the usability problems of oldUI. Moving forward you will find lots of detailed discussion on the process of designing newUI and the reasons it was designed the way it was. The old partitioning screen had substantial problems, and many of the results you could get from it were by no means obvious at all.
3. GNOME is gradually converting its applications to put some menu actions in the 'global' menu on the top panel; this is where you will find the actions you thought were 'missing'. Indeed this will mean some apps are inconsistent with others until the conversion is completed. Fedora ships upstream GNOME with virtually no configuration changes at all. If you don't like GNOME, there are many other options to choose from in Fedora. KDE is supported on an equal basis with GNOME in Fedora.
"It uses old MSDOS ini files (who the fsck thought that was a good idea?)"
It is a very good idea, because it allows the status of a service to be tracked reliably, and it allows all sorts of configuration of the behaviour of services which is not possible, or possible only in very ugly and hacky ways, using pure shell scripts.
See 'man systemd.unit'.
I really don't understand why people assume that the systemd developers just decided to invent complexity for the hell of it, or something, in the face of the extensive evidence to the contrary. If you're going to criticize systemd, at _least_ read its documentation and understand the reasons for the way it is designed the way it is designed. Just saying 'it's designed differently and that's obviously bad!' is ludicrous.
"I agree that systemd is very bad, but even worse is journald which replaces traditional syslog with a binary logging format."
No, it does not.
[root@adam tmp]# journalctl
-- Logs begin at Fri 2013-03-08 13:04:50 PST, end at Tue 2013-05-28 13:18:06 PDT
Mar 08 13:04:50 localhost systemd-journal[116]: Allowing runtime journal files t
Mar 08 13:04:50 localhost kernel: Initializing cgroup subsys cpuset
(etc etc etc)
[root@adam tmp]# head -5 /var/log/messages
May 26 10:39:15 adam rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="559" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
(etc etc etc)
journald is *an* implementation of a system logging daemon. It is not the only implementation. It is not an exclusive implementation.
You can run as many system logging daemons as you like. Fedora is currently configured to run both rsyslogd and journald. System log messages go to both and you can inspect them however you like.
In future we may configure Fedora to only run journald by default, but this does nothing to prevent you running rsyslogd as well as journald, or instead of journald, or running any other system logging daemon that you like. The Linux system logging infrastructure is explicitly set up so that logging daemons are interchangeable and can be run concurrently. journald is written to respect that: it is one system logging daemon among many and works fine alongside others, and systemd works fine without journald if you decide you don't want it.
"Then, they changed to systemd - a dual layer abstraction abomination for services and configurations, incompatible with the runlevel and init.d scripts that admins have and rely on."
That's impressive; you've written a two line description of systemd which is incorrect in every particular.
It is not a 'dual layer abstraction', it is not incompatible with runlevels, and it is not incompatible with init.d. On the contrary, it was explicitly written with compatibility for both of those things.
"As for Network Manager, try running it with any USB networking (direct connect, like with a phone, rather than an USB-connected ethernet card): it will kill the interface every roughly 30 seconds. Its upstream refused to fix that saying they don't aim to support every possible device."
That's a massive over-simplification. NM works very hard to support connections over phones, 3G/LTE modems and the like, as Dan Williams' blog makes very clear, if you bother to read it.
"Its upstream refused to fix that saying they don't aim to support every possible device. Or, bridged setups. Or, basically anything more complex than a plain ethernet or wifi interface."
This is not correct at all. As Dan wrote on devel list just May 16th:
"It didn't used to be very compatible with server-type networking, but that's exactly what we've been working hard on for the past year or so. Bonding, bridging, VLANs, an Infiniband are all supported by the current NetworkManager 0.9.8, though it doesn't (yet) cooperate well when external tools touch things. That's going to get a lot better quite soon. The 0.9.8 GUI and nmcli both have support for all of the aforementioned interface types."
Seriously: you really think *Red Hat* would bother spending several years of engineer time writing a network management layer which didn't support 'anything more complex than a plain ethernet or wifi interface'? We're not that idiotic.
Works fine with Spice. http://spice-space.org/
What graphics configuration did you have in your KVM? We test it on qxl/SPICE, mostly, because that's by a long way the best option. the old-school cirrus/VNC doesn't get a lot of testing and can be broken at times. vga/VNC worked okay last time I tried it.
F19 has GNOME, KDE, LXDE, Xfce, MATE and Sugar live spins, and Cinnamon available from the DVD. NetworkManager is still optional, as it has been since its introduction. And systemd is awesome.
" The cool kids are moaning about the half-assed and feature-very-much-incomplete FirewallD (from essentially the same people that brought you SystemD)"
by which, presumably, you mean 'entirely different people'? Since systemd was started by Lennart Poettering and now maintained by him, Kay Sievers and a few others, while firewalld was started by Thomas Woerner and is now maintained by him and Jiri Popelka? So, you know, zero overlap.
firewalld has been in Fedora since F17 and was made the default in F18, so it's hardly the fashionable new thing to bitch about either. It is still entirely optional: if you don't like it, just remove it and you can happily use iptables (or nothing) instead. I'm not sure where you see it as being 'half-assed and feature-very-much-incomplete' as it stands in F19, firewall-cmd in particular appears to be capable of just about everything under the sun, including passing arbitrary config statements through to iptables.