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)
It may exist in both states until the .tar file is opened. In theory it also may be possible to peek inside the file and determine its state (or if it has one).
Because it's new! New == Better
Hasn't Microsoft taught you anything?
LOL j/k
systemd is pretty much here to stay, I'm betting that in about two years every major distro will use it. No, I don't think that is a good thing.
"I use a Mac because I'm just better than you are."
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*
if you liked Gnome2 you will like MATE (because its basically the same, plus a name change so it can coexist with Gnome3, plus bug fixes, library updates and a few small new features)
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.
Even for a supposedly bleeding edge distro SystemD was included in Fedora in far too immature a state with too many broken/missing features, IMHO, and that gave it a bad rep. The latest SystemD release in Fedora 19 actually isn't that bad if you give it a chance and take the time to properly grok how it works, it's more complex that the old init script approach, but it's also much more powerful. You pays your money...
Anyway, complaining about SystemD is *sooo* last distro now. The cool kids are moaning about the half-assed and feature-very-much-incomplete FirewallD (from essentially the same people that brought you SystemD) now which seems to be the suffering from the same "included a few 0.x revisions too soon" problems.
UNIX? They're not even circumcised! Savages!
Gnome 3 works well in a VM or with remote X on headless servers?
That's news to me.
Gnome3's interface... let's not speak of it, I prefer to not use words it deserves among civilised people.
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.
Or, bridged setups. Or, basically anything more complex than a plain ethernet or wifi interface.
It wouldn't be bad if Network Manager accepted that it's not infallible and allowed such devices it does not support. But not, it insists it has the complete view of the system's network, everything else is wrong, and even if you blacklist a device it knows (not possible for ones it doesn't), it still says you're in "offline mode" when you use programs that made the mistake of querying NM.
If a single line, "apt-get purge network-manager", instantly fixes all problems of this kind, I'm kind of disinclined to believe that "it works pretty well".
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
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.
systems with poor GPUs probably have poor CPUs as well, so LLVM pipe is not going to be fun.
You don't have to go back to far to find GPUs with max textures size of 2048x2048 or lower. for a composited desktop across multiple desktops the total desktop size cant exceed the max texture size. So on a few year old netbook you may not be able plug into to an external monitor or projector with GNOME3 where you could with GNOME2.
i booted fedora18 in a kvm virtual machine today. The GNOME3 desktop displayed, but with horrible corruption.
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.
I'll take their advice seriously, when they seriously contribute an actual technical criticism of systemd that doesn't simply end up as a platitude or rule of thumb.
I Mean, Einstein himself was a critic/non believer of Quantum Mechanics, I wouldn't call him an idiot, but you can't let people who've been doing the same thing well forever just squash a new idea without valid criticism.
Gnome3's interface... let's not speak of it, I prefer to not use words it deserves among civilised people.
I migrated to Gnome 3 from E17 because it's actually about the best DE I've found. Yes, it has problems; there are parts of it that make me wonder WTF the developers were thinking (mostly the bits they've ripped off from Apple, which frequently seem ill thought out even on OS X), but it generally works better for me than any other DE I've tried. If you don't like Gnome 3 then that's fine - there's plenty of choice, but don't shoot down the whole distro because it happens to default to a DE that you personally don't like, but which many other people find to be excellent.
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.
Or, bridged setups. Or, basically anything more complex than a plain ethernet or wifi interface.
The USB thing is a shame - I can't really comment on that as I've not tried using USB NICs with it.
As for "you can't do anything complex with it", IMHO it isn't intended for that use - network manager is intended as a "plug and play networking for dummies" system; if you want something complex then set NM_CONTROLLED=no in the network config and configure it yourself. Adding lots of support for very complex setups to NetworkManager itself, when that's already supported via other mechanisms, would seem to defeat its purpose of offering a *simple* network configurator.
But not, it insists it has the complete view of the system's network, everything else is wrong, and even if you blacklist a device it knows (not possible for ones it doesn't), it still says you're in "offline mode" when you use programs that made the mistake of querying NM.
That certainly doesn't seem to agree with my experiences. I frequently set systems up with NM_CONTROLLED=no in the NIC configuration and NetworkManager handles that just fine (in fact, on servers I make a point of doing this; which is fine - IMHO NetworkManager is neither intended nor suited to server environments so turning it off and using more traditional configurations (which are still supported) is a good idea).
If a single line, "apt-get purge network-manager", instantly fixes all problems of this kind, I'm kind of disinclined to believe that "it works pretty well".
If you're using apt-get then you're not using Fedora, so your comments seem a bit irrelevant to a discussion about the latest Fedora release. I can't comment on how well NetworkManager works in other distros, but under both Fedora and Scientific Linux it seems to work well and is trivial to bypass if you need lots of complexities in your network configuration.
http://blog.nexusuk.org
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.
The problem is that many aren't "cranky old SA's" but just uninformed old gits that refuses to even read up on new technology and flat out denies that there any problems whatsoever with Linux logfiles, and the way Linux handles services (init etc).
Whenever I see systemd or Journal hate here on Slashdot, it is always just snarky remarks that almost always are totally wrong, and clearly demonstrate that they don't know what they are talking about.
Even if you never, ever use the Journal tools or access the Journal log files, systemd and Journal will enhance the Syslog files considerably, by enabling log info early in the boot process, and tagging and aggregate the logfiles.
IMHO, systemd and Journal is the best new tools for the Linux SA made in the past decade.
I really recommend reading this list of systemd myths:
http://0pointer.de/blog/projects/the-biggest-myths.html
And Lennart's "systemd for Administrators". Here is a link to the first part of twenty instalments:
http://0pointer.de/blog/projects/systemd-for-admins-1.html
Very good stuff. A must read for any Linux SA, whether they think they dislike systemd or not.
Even if you never, ever use the Journal tools or access the Journal log files, systemd and Journal will enhance the Syslog files considerably, by enabling log info early in the boot process, and tagging and aggregate the logfiles.
And what do you do when something goes wrong? Or you need access from a different arbitrary system?
I really recommend reading this list of systemd myths:
http://0pointer.de/blog/projects/the-biggest-myths.html
And Lennart's "systemd for Administrators". Here is a link to the first part of twenty instalments:
http://0pointer.de/blog/projects/systemd-for-admins-1.html
Very good stuff. A must read for any Linux SA, whether they think they dislike systemd or not.
Do you have any links that has been written by others than Poettering himself? Like, for instance, system administrators?
And what do you do when something goes wrong? Or you need access from a different arbitrary system?
That sort of questions is exactly why you should read the linked pages. So calm your fuming hate against Poettering and start reading.
I guess your very vague question is something about accessing Journal log files, something you probably think can be problematic since they are binary, right? No worries mate. Syslog is a first class Journal client, you can read all the usual text file stuff in /var/log/* if for some reason journalctl doesn't work, but everything else does. Journal send all messages to syslog, including early boot stuff that syslog couldn't log before.
It is just that when journalctl (and all the other cool *ctl tools) works, it is faster, easier and more secure than the usual chaotic syslog logging. So what is wrong with displaying not only an error message, but also the exact link where the error message is explained and documented? "journalctl -f" instead of "cat /var/log/messages | tail" ?
Cryptographic secure logging? That you have an actual guarantee that a message is written by the daemon it claims?
"journalctl", "systemctl" and all the other *ctl tools like localectl, hostnamectl and loginctl, are just wonderful and powerful tools, that promises some kind of consistency when it comes to Linux logging and system information gathering etc.
I spent the last 10 minutes googling to try to find out what all the hate is for SystemD (and what it is). Here is what I've found, according to "the web":
* SystemD gives flexibility about when and how services are started in a way that old init scripts could not
* Its currently a bit rough around the edges
* It can significantly lower boot time in the real world
Chief complaints seem to be
* "its not unix-y"
* Its new, and a bit complex
* If its screwed up, the system may not boot (then again, ditto with init scripts / fstab / grub.cfg / initrd / any of a zillion other things)
* People dont like the developer
Is that an accurate summary? Are there any technical issues that Im not getting? It just seems to be a lot of vitriol amounting to "I dont like learning new systems" (which, honestly, is a valid criticism-- but its not a technical deficiency).
" 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.
"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.
"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.
That sounds about right.
There are also some complaints about it absorbing other components e.g. udev. to the developers this makes sense because udev is about responding to hardware events and systemd can trigger this based on these events (e.g. starting network servers when you plug in a network card, or a backup script when you plug in an external drive). also they shared a lot of code. To people who don't want to use systemd, this makes them worry about where they will get udev from, and if udev will continue to work on non systemd systems. (there is now a fork of udev called eudev)
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?
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.
I know what you mean, dude. 36 years ago the supermarket down the street gave me short change. I've never been back since.
They didn't help me when systemd crashed and took with it the entire system. It's built as a card house, with assumptions that things don't go pear shaped, or if they do, you have time to wade through hundreds of configurations in search of the proverbial needle in a haystack.
I don't LIKE systems where you put all your eggs in one basket, and for good reason.
This is no different from a failed init that causes a kernel panic. The difference is that systemd now is thoroughly tested on *thousand of machines and keeps improving, so using it to control services will minimize all the dangers that comes from hand editing complicated, often undocumented init scripts.
systemd has superior debugging facilities and is well documented. You can actually systematically analyse what a certain run-level (called target) requires, or tell systemd to spawn a shell if it crashes. It is so much better when it comes to tracking down service/daemon troubles than static scripts.
Sure, there is something to learn about systemd before mastering it, and many people seems to loathe reading about new technology, or just doesn't have much time on their hands to learn new stuff. But neither is a systemd problem, and learning new technology and new ways of doing things, comes with the territory as SA.
Check out all the wonderful stuff one can do with systemd, journald, and all the *ctl tools; completely consistent control and behaviour across every Linux system that uses systemd. No need to learn and relearn dozens of small system peculiarities across distributions for controlling services, working with log-files, getting system info, etc. etc.
systemd is the future because it is such a good idea that most major distributions are switching to it. I will recommend all Linux SA's to put their real or imagined reservations against systemd aside, and start boning up on the subject
There is a lot to learn, not because systemd is complicated, but because it can do so many things, like resource limiting, mounting etc.
Here is a link that compares sysvinit, Upstart and systemd
http://0pointer.de/blog/projects/why.html
Come on, "On-demand socket activation for per-connection service instances" for virtual servers, how cool is that!
How about it takes a simple and fundamental thing and turns it into a twisty little steaming pile?
It's just one more bit of needless complexity mucking up a simple eligant design.
It's not even all that well documented, so learning it presents a bit of difficulty.
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.
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...
Chief complaints seem to be * "its not unix-y"
"It's not unix-y" carries with it other issues, including "its not portable." My understanding is that systemd makes use of some new features in the linux kernel, that among other things won't work on other kernels. Will it work on legacy hardware? And so on. It may be that for most users and most distros with their respective philosophies, systemd's "not unix-y-ness" presents no great issue. And I think that's fine -- distros that strive to be new and flashy like mint and fedora should use systemd and take advantage of its features. For debian, where supporting lots of different architectures and maintaining the GNU/kFreeBSD and GNU/Hurd ports are part of their philosophy, it probably makes sense to pass on systemd, at least for the meantime.
* Its new, and a bit complex
Put another way -- it's not yet all the way ready for primetime. This does not seem to bother distros like ubuntu and fedora from releasing new and buggy features as defaults (e.g. PulseAudio in ubuntu 8.04). And that's great for those distros, that wan't to give users an experience on the bleeding edge in lieu of extra stability. But that's not for everyone either.
* If its screwed up, the system may not boot (then again, ditto with init scripts / fstab / grub.cfg / initrd / any of a zillion other things)
Sure, but again -- for many distros, it is worth taking the time to clean up the rough edges. SysV init scripts could screw up your system dreadfully if you get them wrong, but most of the software that you use probably knows how to deal with them and won't get it wrong.
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