Slashdot Mirror
Fedora 19 Beta Released: Alive, Dead, or Neither?
darthcamaro writes "Fedora 19, aka Schrödinger's Cat, is now out in Beta. There is a long list of new features in this release, including 3D modelling tools, improved security, federated VoIP, updated GNOME and KDE desktops and new improved virtual storage to name a few. '"Normally we have a good batch of features for everyone in a new release and this time around a lot of it is under the hood kinds of stuff," Fedora Project Leader, Robyn Bergeron, told ServerWatch.'"
Netcraft can either confirm its release status or its deadness; but not both.
(yes, yes, I know that that's a totally different aspect of physics, and that Netcraft confirms the death of BSD, not of Linux; but somebody has to do these things)
Both alive and dead.
Did they upgrade away from Gnome3, network-manager and systemd? If not, why should we even look at it?
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
>> Schrödinger's Cat
A code name with an umlaut, an apostrophe and a space. That should give the web's encoders a workout.
But otherwise dead to me.
I moved to something with a sane release cycle and I fire up a VM if I want to play with toys.
You know, with all the crap with GNOME 3 and all, I left Fedora for CentOS. In many ways, CentOS serves me better, but in that, I also learned there were some things I couldn't do. Not "couldn't do without a great deal of trouble" but couldn't do. GiMP was and still is to some degree, important to me recreationally and professionally. And while I certainly have issues with GiMP 2.8.x's directions, I wanted to run it. Turned out, however, that I couldn't. It seems conflicting versions of GTK for the Desktop UI and the requirements of 2.8.x created a bit of an impossible situation. Determined to make it work, I eventually did manual compiles of GiMP and all of the GTK related dependencies. And there were a lot of them. But even after that, GiMP, with its own GTK libraries, would not integrate with my existing GNOME desktop. So I lost Japanese text entry which is, at times for me, important.
GTK is "Gimp toolkit." This makes it an application library. But for some reason, GNOME, the desktop OS shell, decided to adopt GTK for what it does. It didn't seem like a bad idea until you take into account that the GiMP and GTK developers don't give a rat's ass about backward compatibility or any of that. It is GNOME's fault for selecting GTK instead of forking it or something else. So now, among other programs, I cannot run GiMP on CentOS. I will never stop ranting about this.
But I miss the good days and have been watching the MATE desktop which will never, it seems, come to CentOS. And so I've been tempted to give the next Fedora a try. One thing I haven't heard much about is wobbly windows. I really like having my wobbly windows and 3D virtual desktop. (I speak of Compiz, of course if you didn't already know.) I see this: https://fedoraproject.org/wiki/MATE-Compiz_Spin and that's encouraging... but I wonder. I hope anyway.
But I was looking at the release schedule. Combine that with the doom of the global economy, I'm thinking I'd be better off buying up stocks of canned beans instead of a new hard drive. *sigh*
Fedora has done a couple of WTFs that alienated a large portion of the user base, and more importantly, the admin base.
As Fedora is the source/playground for what becomes the next RHEL, it is watched by the admin community more than most distros.
In Fedora 15, the big WTF was switching to a desktop environment that does not work well or consistently with remote viewing, which is a big issue for server use.
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.
In F18, they have brought back MATE as an alternative to Gnome 3, and that might revive some of the interest. But systemd is still a killer, and not in a good way. If this makes it into RHEL 7, it will be a sad wake-up-call for Red Hat when the paying user base stays at 6 or migrates to competitors.
So no, not dead, but the jury is still out on how seriously it should be taken.
both ethically and functionally... only the default package is a little buggy but still a lot faster than the resource beast called USC....
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.
My experience of systemd is that it's fine, when it works which in fairness is usually. Then again, the same could easily be said of init scripts.
But it is really opaque and not especially well documented so when it does go wrong (which is more common on servers with odd custom setups) it is really, really hard to fix.
That is not fun.
SJW n. One who posts facts.
Systemd will most likely be used in RHEL 7.
I don't understand. Why would you run Fedora on a snerver?
You forgot the "improved" Anaconda?
Since RHEL 7 was already confirmed to run Gnome 3 ,chances are systemd will indeed be the default. I don't hate it as much as I used, it indeed has its vantages. The problem is that Fedora being Fedora dropped it to the users to swallow in a not pleasing way.
As much as I love Red Hat as both as a company and as a distro, I no longer have a need or desire to use Fedora if I can have anything it has, but stabler and saner, with OpenSUSE. They need to wise up if they still want to be a player. The whole world doesn't like the cloud as much as some say they do.
You would run RHEL, which is based on Fedora.
RHEL 7 is slated to have systemd, because Fedora has it, unless enough admins voice their protest.
At least in the F17 vintage, you could turn off all the services you wanted and then start them in order in rc.local essentially throwing out systemd all together, thus reducing your system boot time greatly. systemd would eventually boot a server with many services, but there were too many loops with networking that just didn't work properly if you were still using network instead of network manager to boot quickly. Perhaps NM has now gotten to the place that you can define bonds and VLANs and the like, but the last time I tried they were a nightmare compared to good old network.
But systemd is still a killer, and not in a good way. If this makes it into RHEL 7, it will be a sad wake-up-call for Red Hat when the paying user base stays at 6 or migrates to competitors.
I agree that systemd is very bad, but even worse is journald which replaces traditional syslog with a binary logging format. (Even worse is that the binary format is *by design* not stable and you can only read a log file with the same version of the tool that created the log file!)
Unfortunately, OpenSUSE is on the systemd/journald bandwagon now too. :-(
Until I install it, it is simultaneously a great OS and a lousy OS. I'd hate to install it and determine it is a crappy release.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Personally, my distro of choice is OS4, http://www.os4online.com Fedora lost its way a while back for me, but it will be interesting to see what they do.
There are also projects like oVirt which free support is only given to Fedora.
I installed Fedora 19alpha on my laptop the other day, and I have to say that Fedora's GNOME desktop has really lost me. I don't expect things to change in Fedora 19beta. In my opinion, the last usable version of GNOME was version 3.4 in Fedora 17. And that's barely usable, but things get better if you use some of the plugins.
Fedora 19 will include GNOME 3.8 as the graphical desktop, and I've noted elsewhere that GNOME 3 has poor usability. (My graduate thesis is on the usability of open source software.) The developers at GNOME have continued their downward usability trend, so Fedora 19 isn't getting any better. GNOME 3 fails to meet two of the four themes of successful usability: "Consistency" and "Menus". Where are the menus? There is no "File" menu that allows me to do operations on files. There is no "Help" menu that I can use when I get stuck. The updated file manager (Nautilus) doesn't have a menu, but other programs in GNOME 3 do. The Gedit text editor (which is also part of GNOME) still has menus, but the file manager does not. When you maximize a Nautilus window, either to the full screen or to half of the screen, the title bar disappears. I don't understand why. The programs do not act consistently.
I will give a positive comment that the updated file manager now makes it easier to connect to a remote server. This used to be an obvious action under the "File" menu, but in GNOME 3 it is an action directly inside the navigation area. So that's a step in the right direction.
I've only discussed the file manager here, but I'm sad to say that this is just one example of poor usability throughout GNOME 3.8 in Fedora 19alpha. While some areas of the Fedora 19alpha desktop seem familiar, the environment contains many areas where I was left confused. Programs act differently; there's very little consistency. And the updated desktop environment seems to avoid familiar "desktop" conventions, tending towards a "tablet-like" interface. This further removes the obviousness of the new desktop, and it's familiarity.
The worst offender is the Fedora 19alpha installer itself. Maybe they fix this in Fedora 19beta, but I doubt it. Fedora used to have a very simple, easy-to-use installer. You answered a few simple questions using point-and-click or drop-down menus, then the installer did everything else for you. For example, let's say your computer was set up to "dual boot" both Fedora Linux and Microsoft Windows. Previous versions of the Fedora installer would give you the option to install over your previous Linux installation, or set up the install disk configuration yourself. The latter phrase may be more meaningful to someone with more technical knowledge, but the former is easily recognized by users of all skill levels to mean the same thing.
In the Fedora 19alpha installer, everything has changed. (Actually, I believe this changed in the Fedora 18 installer.) The installer now presents a yellow warning label that the disk doesn't have enough room. When I clicked into the disk setup tool, I was given the option to "reclaim" space, but I really didn't understand what that meant. There was no button or other option to "install over my previous Linux installation," despite the fact that this laptop only had Linux on it (an older Fedora 17 install). If I were a user with "typical" knowledge and "average" skill, I would likely be afraid to use this installer, lest it do the wrong thing.
The installer's progress bar is equally confusing. Usually, when a program displays a progress bar and a message to indicate the percent complete (such as, "Installing 50%") you might expect the progress bar to indicate the same "percent complete" as the text message. Not so during the Fedora 19alpha installation. The installer (Anaconda) displayed a message that it was installing system software, and it was "50%" complete, yet the progress bar displayed something like two-thirds complete. I quickly decided not to trust the progress bar. And it's a bad sign when your users decide not to trust your software.
As long as it uses systemd, FCwhatever is dead to me.
The Future of Human Evolution: Autonomy
I know it's bad form to reply to my own comment, but I figured it was better to make a separate comment about Xfce.
I consider Xfce to have much better usability than GNOME. After I installed Fedora 19alpha GNOME, I installed Fedora 19alpha Xfce, and it is much better!
From my open source software usability test last year, the four themes of successful usability were:
While I haven't done a formal usability study of Xfce, my heuristic usability evaluation of Xfce is that it meets all four of these themes. The menus are there, everything is consistent. The default Xfce uses a theme that is familiar to most users, and actions are obvious. Sure, a few areas still need some polish (like the menus) but Xfce already seems better than GNOME.
Additionally, if you are technically capable, you can dramatically modify the appearance of Xfce to make it look and act according to your preferences. At home, I've modified my Xfce desktop to something similar to the Aura window manager used in Google's Chromebook. It works really well and I find it is even easier to use than the default Xfce desktop.
And of course, Xfce uses fewer system resources, so it runs very fast.
Seems to have gone well. I like it.
If you can't rewrite an init script into a systemd start up script, you have no business administrating a box worth administrating.
IMHO the GIMP developers should have got the GEGL stuff done as a priority for 2.10 and then immediately worked on the GTK3 stuff for 3.0. All other features and improvements should be extras until the infrastructure migrations are done. Why? For reasons exactly like you describe. Being up to date with infrastructure and libraries is rather critical. GnuCash was almost dropped when it took too many years for them to jump on Gnome 2 libs. It's been what, two years since Gnome 3 and they still aren't there yet...
systemd doesn't use startup scripts.
It uses old MSDOS ini files (who the fsck thought that was a good idea?)
Sure, you can make it call a script, but even then, there are limitations - you don't know the exact state of the environment at the time your script is called, due to the massive parallelism. And it isn't a two-minute job to convert either, for any but the most trivial of scripts.
Try creating systemd ini files for advanced services that have different setups depending on the runlevel, and then come back. Until then, my opinion is that you have no clue what systemd does, how, and how it differs from established practices.
It's trying to shoehorn Windows-worst-practices into Linux, by a single developer who talks large and breaks more than he ever fixes.
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.
My experience of systemd is that it's fine, when it works which in fairness is usually. Then again, the same could easily be said of init scripts.
But it is really opaque and not especially well documented so when it does go wrong (which is more common on servers with odd custom setups) it is really, really hard to fix.
That is not fun.
There is a plethora of systemd documentation. What additional information do you need?
Perhaps NM has now gotten to the place that you can define bonds and VLANs and the like, but the last time I tried they were a nightmare compared to good old network.
NetworkManager has had bonding and VLAN support since version 0.9.4.
Fedora Project Wiki: Networking/Bonding
Fedora Project Wiki: Networking/VLAN
After Fedora 18, I honestly don't think there's anything left to break. I think their mission of creating an unusable system is accomplished, and they can quit. I'd switch to Mint or something if I wasn't using my Fedora system every day. I can't just format my hard disk and start over. I can't afford that much downtime.
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, 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. 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 has gone from a workhorse operating system to one where I walk on eggshells, wondering what they've broken and when it will crash. I don't mind experimental features at all, but not things breaking that have been stable for a long time. Fortunately, KDE shields me from Gnome 3.
When I build my next computer, I will be looking at anything else but Fedora.
I think Fedora is the Dogbert of operating systems - a perverse, sadistic force of pure evil for no other reason than enjoying the suffering of others.
The most important feature of Fedora 19 is the remote attestation in network manager. This will let you keep Fedora systems on the internet in places where only systems running approved software are permitted and will enable a future internet that has far less malware.
.. since the disaster that was Fedora Core 4. Released with a badly broken Xorg.
"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.
"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.
"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.
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?
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.
.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 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.
Not for the hell of it, more because when what you have is a hammer, everything starts looking like nails. 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.
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 -- it's always his way or the highway, with less choices as the end result.
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.
You obviously have a different view of what compatibility is than I do. 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.
And how are runlevels not broken when I type "init 2" and network services continue to run?
".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'.
"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.
It has much change for no real benefit.
People who run RHEL either use it on a server or running expensive 3rd party apps that are flaky as it is.
(Stuff like Cadence is $125,000 a seat and really badly designed but you need something like it if you want to design chips).
(Whereas when I first used SMF on Solaris it didn't annoy me at all).
When Sun or Microsoft introduce(d) something they fix the rest of the OS properly as a condition of it being added.
If you want to cause extra work for someone else you should have good reason.
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.
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.
The day I can install e.g. Oracle Grid or Backup Exec on a systemd system (without Oracle or Symantec biting the bullet and jumping through the hoops to get it to work with systemd), without order problems at either startup or shutdown, then we can talk about compatibility.
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_.
Only within systemd - it breaks the toolbox approach where you only do one thing, and can substitute at will..
If your request is 'stop making systemd and make sysv instead', then yes, it's 'Lennart's way or the highway'
No, I am all for replacing sysv - with something better, that you can configure without special tools on a running system. Anything that requires more than vi for configuration is anathemical to the Unix way. Trying to re-implement a registry has failed before - many of us remember AIX of yore, and don't want those days back.
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.
"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...
".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."
The meaning is perfectly clear. Most config files are context free. Each and every configuration item is unique. When you add in sections and make the tags only unique to the segment, it makes simple grep and sed operations (for programatic configyuration) somewhere between difficult and impossible.
Given that I am happy with the results SysV gives me, there is no way to justify any additional complexity. If you would care to create purely optional utilities that can improve things without introducing added complexity for people happy with the status quo, we'll talk.
Sometimes it's best not to do more stuff. I want my car to be a car, not a car/boat/airplane./tubnnel boring machine/can opener/ telephone sanitizer. Especially when it doubles the odds that something will break and leave me stranded.
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. The stuff is logged in binary. 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.
You do have a good point that you can run journald and syslogd in parallel. That is actually quite cool.
Whilst the younger linux only SysAdmins are whining about the change the ex-Solaris 10 admins can't wait for RHEL7 and systemd ... it is very similar to SMF which was fantastic at service management ... and a much needed addition to the linux service ecosystem...
> I think you can see where I'm going with this.
Hopefully in the direction of continuing not to ship a RHEL release with systemd included.
Fedora has done a couple of WTFs that alienated a large portion of the user base, and more importantly, the admin base.
Thanks for beginning with this statement. This is where I knew you are full of shit, so I have stopped reading. People making unsubstantiated claims about "a large portion of the user base" can always safely be ignored.
My exception safety is -fno-exceptions.
"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.
Thanks for beginning with this statement. This is where I knew you are full of shit, so I have stopped reading. People making unsubstantiated claims about "a large portion of the user base" can always safely be ignored.
Look at the download statistics for recent versions of Fedora.
As well as the fact that this submission even exists.
What other substantiation do you require? A Gallup poll?
First it was SystemD, which is horrible and unnecessarily complex and obtuse. Whatever genius came up with it I'd like to thank personally with a punch to the face. Then the geniuses decided to go for the gold and piss thousands of people off by bricking everyone on upgrade without warning: https://bugzilla.redhat.com/show_bug.cgi?id=737508
As soon as I actually began to comprehend the syntax of systemd commands, I knew it was a catastrophe. Underneath the veneer of the administration tools lies this: http://hhe.wikispaces.com/file/view/rube-goldberg.jpg/51160771/rube-goldberg.jpg
the chance that i could make a phone call without the phone company is wonderful. i start up fedora/ubuntu on my smartphone, open up voip, and call user@domain from taco bell. and what an opportunity for increasing spam calls.
.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 the biggest fan of the ini-style files partially because they're not grepable, but look at what systemd files replace -- generic shell scripts. I don't think the init scripts I deal with are grepable at all, so systemd isn't a downgrade to me in that case. It strikes me that .ini files aren't as flexible, but without looking at it I'd have to assume otherwise.