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.'"
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.
I think its just cranky old sysadmins that don't like systemd. Its actually quite good and offers several benefits over the old sysvinit.
It's the cranky old sysadmins who keep the servers and internet running. What they say is often important. When someone tries to re-invent Windows Services, AIX smit and Windows Event log, they may grump, but they do so with the experience saying that it wasn't a good idea the last time either.
So, for how long did we have SysV init-scripts?
The problem isn't that things doesn't get to stay for too long, but rather that the "new" generation of "developers" are an ignorant, egocentric bunch of shit-heads who grew up with windows 95 and thinks that was the gold standard for an OS. Pair that with an incurable allergy to actually fixing the problems that exists, rather than papering over them -- yeah, I'm talking about PA -- and you get the current sad state of the linux desktop.
In my experience, "Familiar" doesn't have to mean "Same." Using your example, iOS shares a lot of familiarity with MacOSX. The two environments aren't the same, but they aren't worlds apart either.
I think those two points are somewhat linked. You can lose a little bit of obviousness if it looks like something that already exists (Familiarity) ... or you can lose a bit of familiarity if the system is dead simple to use (Obviousness). Gmail is one example that successfully balanced the tradeoff between Familiarity and Obviousness.
In one of my usability tests, I observed typical Windows/Mac users with average knowledge quickly figure out how to use most of GNOME 3.4 (Fedora 17) because GNOME 3.4 seemed familiar enough to Windows/Mac, programs acted consistently within GNOME 3.4, they could find actions in menus, and (most) application functions were obvious and had obvious effects.
"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.