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)
>> Schrödinger's Cat
A code name with an umlaut, an apostrophe and a space. That should give the web's encoders a workout.
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."
Did they upgrade away from Gnome3, network-manager and systemd? If not, why should we even look at it?
Because Gnome 3 and Network Manager happen to work pretty well these days?
http://blog.nexusuk.org
GNOME 3 doesn't work very well on hardware that is a couple of years old. I don't mind the effects and annoying default settings that much, but I can't use a desktop environment that causes my laptop fan to run constantly.
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.
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.
Systemd will most likely be used in RHEL 7.
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!
Your PC would have to be pretty arcane to not run it in which case the solution is clear - use a less demanding distribution or window manager.
Gnome 3 works well in a VM or with remote X on headless servers?
That's news to me.
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.
Did they upgrade away from Gnome3, network-manager and systemd? If not, why should we even look at it?
Fedora is actually a very good KDE distribution.
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.
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.
LOL j/k
What is this, 1996?
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
but I can't use a desktop environment that causes my laptop fan to run constantly
If the system is not doing anything productive, then it should not be using system resources. There is no reason for his fans to spin up unless he's actually doing something.
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.
spins.fedoraproject.org/lxde/
As long as it uses systemd, FCwhatever is dead to me.
The Future of Human Evolution: Autonomy
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.
GNOME 3 will work well on pretty much any PC with a GPU from an IGP on upwards.
Will it work on my $30,000 headless server?
It also has LLVM pipe support for software rendering where the GPU / driver is not up to scratch.
That will automatically fix incorrect assumptions like displays having edges stopping the pointer device, or that the display server and client always run the same version of software?
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.
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...
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.
Gnome 3 works well in a VM or with remote X on headless servers?
That's news to me.
Why on earth would you be running Fedora of all things on a server? Yes, things don't work so well when you use software that's inappropriate for the job - why not get a LTS server distro instead of a experimental workstation distro if you want to run servers?
http://blog.nexusuk.org
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
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.
Network Manager is a victim of the 80/20 rule. 80% of the time, it works fantastic. 20% of the time it's better to disable it and edit the config files yourself.
And you know what? That's good enough for me. I use NM nearly always on my laptop because usually I just want to get connected the usual way. When I'm interested in "server level" connections I disable NM and roll my own configs manually.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Hey, hey.... it's Network Mangler, and don't you forget it!
(seriously what's with the local DNS resolver bullshit? /etc/resolv.conf and leave it the fuck alone)
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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?
This would be a good thing if Gnome didn't declare Network Manager to be a mandatory component. In Debian, making it removable needed to be forced by the Technical Committee twice.
I used to care about this when I still believed Gnome3 is not "yet" usable and it's just a matter of work/time. Nowadays, I've seen how much ill will and how little sanity Gnome3 upstream has, and I wouldn't call it a work of the devil to not insult Satanists, so I don't give a damn about Gnome3's dependencies anymore. Too bad, some people try to make Network Manager installed by default (for example, it is on Raspbian), and that's major damage.
There is only one case it may be useful: if you use wifi but no other networking, not even a virtual machine or a tunnel -- Network Manager's wifi interface is superior to those of wicd. Too bad it conflicts with anything else.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
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.
systems with poor GPUs probably have poor CPUs as well, so LLVM pipe is not going to be fun.
Not necessarily and besides, that's where the other thing I said kicks in - don't use GNOME 3 if your system isn't up to it. Use XFCE or something. I've had GNOME 3 running quite happily on a VM inside a Core Duo with some crappy portable AMD chipset. I've had it running on a 6 year old AMD X2 with some ancient Nvidia card. It's never going to win prizes on the set but neither it is especially intolerable or unusable.
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.
Works fine with Spice. http://spice-space.org/
"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 don't call RHEL an experimental workstation distro. Unless they go with Gnome 3 and/or Poettering's reinventions in RHEL 7, in which case I may have to revise my view.
Actually, more to the point: why would you be running an X desktop environment on a server at all? Running X applications remotely (tunnelled over SSH) is occasionally useful, but why on earth would you want a full desktop environment?
http://blog.nexusuk.org
"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.
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)
Why on earth not?
If you're running any form of thin clients then you most certainly need it. We have a couple of Sun Ray clients running that way. The hardware clients are nothing more than a networking stack and a display port, everything else happens on the server.
Why on earth not?
Because most servers don't have a monitor connected to them?
http://blog.nexusuk.org
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?
I was using virt-install which (according to its man page) defaults to --graphics vnc if the DISPLAY variable is set.
Ok, I just checked with 0.9.8. Plugging my phone in: udb0 pops up, gets the address configured from /etc/network/interfaces, both IPv4 and IPv6. Can ping the other side. Wait half a minute. Suddenly there's no address anymore, the interface is still up.
With no network-manager, the addresses stay.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
s/udb0/usb0/, doh. Sorry, the "preview" button is there just to make the interface look less empty, right?
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
That sort of questions is exactly why you should read the linked pages.
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.
"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.
And are useless on a non-running system. Configuring a working /etc before bringing up a system, and even cross-OS, is part of bread and butter for both large scale operations and embedded.
Actually, more to the point: why would you be running an X desktop environment on a server at all?
With Gnome (and KDE), the lines between the apps and the desktop environment are blurred. Do an ldd on some of the apps and weep.
But also consider this - a user's desktop environment might be on a remote machine, often a VM. Sometimes (yes, even in 2013) xdm and nis.
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?
Why do you want Linux to be like Windows 95 just because you don't upgrade your hardware?
Because Linux's standards should be a little higher. It's unacceptable for a desktop environment to use so many resources when 'idle.'
It shouldn't be the end user's job to throw money at hardware to work around developer hubris/laziness/ineptitude.
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.
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.
".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.
"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.
I know what you mean, dude. 36 years ago the supermarket down the street gave me short change. I've never been back since.
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.
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 powerful does the init system really ned to be? I much prefer simp[licity in things like that. I swear the GNU/Linux userspace looks a likkle more like Windows every day and it's revolting.
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.
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.
His case does imply a design flaw though. It should never just tear down an interface or remove and address if it doesn't have something better to replace it with (that is, a working network connection) for any reason other than a direct user command.
If an interface is set up and NM didn't do it, it should leave it alone unless explicitly told to manage it.
I'd guess those 2 rules would eliminate most complaints about it.
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...
I've tried Fedora a few times but always end up back with either Ubuntu or Mint.
Those things you mention are frustrating but what stopped me cold the last time was the installer. I've been installing Linux off and on for 15 years and even I was left wondering "what the heck is going on here?". I hope they fix that. I can't take the distro seriously when an advanced user can't even feel safe/certain about the install process.
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.
And how do I do that when, for example, configuring a non-running system from a different system? Like, for instance, setting up embedded systems?
The reliance on *ctl apps that have to actually run on the system is a big step back, towards Windows and how you can't really do much about the registry or event logs without a running and compatible Windows system, and for many things THE system it runs on.
This is the direction systemd/journald is taking us, and we've seen this before, with AIX. It didn't impress us then, and it doesn't now.
Those who don't know (Unix) history are doomed to repeat it.
I read the myths, but had to stop when I heard the tires screeching and crash sound in my head when it claimed it's configuration language is easy. Why is that you ask?
Why in the hell should I learn a configuration language when I already know shell scripting? All I really need is a list of what to run in what order. I don't want different services started on alternate tuesdays following the blue moon.
One of the things I have always hated about Windows was the way you have to deal with systems, please don't try to cram it into Linux. If I want it to suck, I'll just install Windows.
At least before systemd, even if NetworkManager is installed for whatever reasoin, all you have to do is "service NetworkManager stop" and "chkconfig NetworkManager off". If this, or the equivalent, has become impossible, then Houston we have a problem, but I have no reason to believe it has become impossible. I certainly never had a problem yet disabling it.
I.e., why get all OCD just because NetworkManager might be present? It's not like systemd, which THOU WILL USE due to stupid runtime dependency decisions.
That addresses Gnome3. Now how to propose to address the hell of systemd?
".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.
And how do I do that when, for example, configuring a non-running system from a different system? Like, for instance, setting up embedded systems?
You don't _need_ the *ctl tools to configure a systemd system. Just use "ed -G" (or "vi" if you need some hand holding wysiwyg GUI) to edit the text configuration files. This is no different from sysvinit.
systemd and journald support live remote logging and what not, and if they doesn't all ready support reading of offline log files, they surely will. (not something I have looked at, but perhaps "systemd-journal-remote" is what you need).
The reliance on *ctl apps that have to actually run on the system is a big step back, towards Windows and how you can't really do much about the registry or event logs without a running and compatible Windows system, and for many things THE system it runs on.
This is the direction systemd/journald is taking us, and we've seen this before, with AIX. It didn't impress us then, and it doesn't now.
Those who don't know (Unix) history are doomed to repeat it.
Having to rely on systemctl is no different than to rely on eg. Bash, vi and all the nice GNU tools, without those, not much can be done.
I see no real world problem in either using the tools on the running system by using eg. ssh, or having a systemd compatible system to analyse log files on a remote system (either offline or live remote logging). In fact, I don't think this is any different from using sysvinit/rsyslog today, except that systemd offers better tools for analysing problems and much better security etc.
That's what you're supposed to do on Red Hat, where it installs all kind of crap by force. On Debian, the expected way to remove services you don't need is to uninstall them. There's nothing akin to chkconfig, intentionally.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Having to rely on systemctl is no different than to rely on eg. Bash, vi and all the nice GNU tools, without those, not much can be done.
Oh, yes, it is very different!
If you don't have bash, use sh or ash or ksh or ... Heck, even without a Bourne family shell at all, you can still see what is done in sysv scripts and how to recreate it, because it's not abstracted two layers deep, it's caller oriented, not callee oriented.
And you don't need vi. You can use any other editor. Including stream editors like sed and awk. You have freedom. The .ini files of systemd are inherently stream editor and grep unfriendly, by the way. So you want to check the foo= statement in the [bar] section, but not in the [baz] and [furple] section? Perhaps even change it? Yeah, it can be done with sed and awk, but it's far from trivial.
With systemd/journald, you rely on the *ctl apps, and can't do much wihtout them. For journald, you even need a compatible version of the tools - the binary format has shown itself to be incompatible between both versions and arches.
What the *ctl routines do is take away the choice and ability to work without specific tools in specific versions. It's a lockdown, and a big step towards the Windows way of doing things.
Windows events have been used for how long now? And who uses them in a meaningful way? I claim it's still a mess in 2013, as it was in '98. Same with the Windows startup/shutdown process, which more than anything cause apps and people to do restarts instead of service changes, because it's too much bleeping pain in the arse to override the OS and restart a service which has dependencies without also restarting the dependencies.
There's no doubt that sysv needs improvements, or even a replacement if it cannot be improved in a meaningful way. But this barf is far from meaningful, or even novel. It's been tried before, and has failed before.
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.
I had to give up using Gnome for Fedora 19. On one implementation I installed both KDE and Gnome. There were over 7 pages of 30 icons per page of scrolling that I had to do to view what I needed to use. And that did not include my QT and C++ workbenches, as well as python and Eclipse.
So,, with KDE, its one to two clicks and the application I want is there. It certainly not as pretty, but it is way the more functional versus Gnome.
Fedora, aside from which is better, KDE or GNOME, is really great.
Leslie Satenstein Montreal Quebec Canada
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.
Better how? There is the status command, ps, and log files.
Don't you want to be able to start services or not conditionally?
SysV scripts alredy do that. Shell programs do support branching, various tests, and return coded from executables.
Don't you want to be able to say 'let me see all the logs associated with this service'?
Grep is your friend.
Don't you want to be able to have services activate on demand
It's called inetd and has existed for a very long time.
Now, can you name something that actually can't be done (and for the most part has been done for ages) with SysV ?
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...
If you think the init scripts that are included with any modern Linux distribution qualify as a "simple elegant design" you're a fucking retard.
IIRC eudev was basically a clueless rage fork by a couple of guys from Gentoo, their motivation seemingly centered around a dislike for udev/systemd developers.
One of the first things they did was to apply a different indent style throughout the repository. So you can imagine where it could go from there.
My exception safety is -fno-exceptions.
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.
"The wheel" is a lot more simple and elegant than the "twisty steaming pile" that is the modern processor; that doesnt mean its the best solution always, or that we should hold back progress for simplicity.
Some times newer, better designs are also more complex; and sometimes there isnt an optimal solution that is also "elegant". See 3d-acceleration vs monochrome graphics, journaling filesystems, virtualization, VLANs, etc etc etc. All are more complex than their predecessors and harder to learn, but thats OK because the additional capabilities are worth it.
Solaris' move from init.d scripts to SMF *years ago* was a fine thing, this is a reimplementation of the same idea. The root cause of the vitriol is Linux kids living in a conceptual and temporal vacuum.
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.
"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.
The modern processor is able to do useful things that the wheel cannot. If the CPU couldn't do anything that the wheel didn't already do well, nobody would bother with the cpu except for research purposes.
Complexity can be justifiable if it does something the simple solution couldn't, AND that something actually needs to be done. Then it's a matter of balancing the importance of that something against the costs of the added complexity.
Look again at your examples. Note how journaling filesystems don't expose any of their complexity to anyone but the developer. To everyone else, they're simpler.
Virtualization and vlans don't impose any of their complexity in situations where they weren't needed before. They also aren't all that complex compred to the alternative they replace. Without virtuialization, for example, you have the complexity of building and installing another physical server and everything that goes with that.
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
Honestly? No. Not at the level of cost. There are other methods of gathering this information (/var/log, ps, etc) that have worked fine for a long time. Breaking the way systems have worked for years is a bad thing. Just look at all the backlash against Microsoft for Windows 8. Users don't like relearning things.
Finally, I miss being able to boot to runlevel 3 with by appending init=/sbin/init 3 to the kernel line.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Actually, I have a Windows 7 install on a 1.2GHz Pentium IIIm with 1GB of RAM and Intel i845 graphics. Newer Linux version do not work on it.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Every 6 months isn't a sane release cycle? Sounds pretty regular to me (and only slips if the version is not yet stable. You're going to tell me that that's a bad thing?)
I'm starting to think GNU is the problem with "GNU/Linux" these days.
That's a long time to hold a grudge....FC1 treated me bad, by FC5 it was a good system. And FC6-7 are still the best Fedora releases ever, IMO.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
.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.
You never needed to append 'init=/sbin/init', just '3' was enough. And just '3' still works with systemd: it translates single numerals to the corresponding systemd target, so passing '3' boots multi-user.target, which is the same as 'runlevel 3' (multi-user, non-graphical).