Fedora 19 Beta Released: Alive, Dead, or Neither? 171
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.'"
Sorry... (Score:5, Funny)
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)
Re: (Score:2)
1) Alive
2) Dead
3) Neither Alive nor Dead (Unborn is a possibility)
4) Both Alive and Dead (Zombie?)
The summary asks if Fedora is in one of the 3 states. You say that Netcraft cannot confirm state 4.
So the question in the Summary can actually be answered by Netcraft because the question assumes axiomatically or confirms that State 3 is false or impossible.
Related question -What if Ballmer asks "Will Fedora be alive next year under the condition that I will kill it if
Should I care? (Score:5, Interesting)
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 [fedoraproject.org] 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*
Re: GIMP (Score:2)
Re: (Score:2)
My advice: run debian wheezy, and if there's newer stuff you can't get, move to jessie.
Re: (Score:3)
I'm confused... What's the problem here? When you upgraded GTK to 2.8.x, did GNOME break? If so, when you installed gtk2-2.8.x along-side the old gtk, what failed to work?
Hell no! GTK is a library, and developers should NOT be scared away from using libraries of other projects. The only way you can
Re: (Score:2)
Turns out there may actually be a way. As I said, I had to compile all of the dependent libraries and put them in their own separate location for the local GiMP 2.8.x to use. (I was not referring to GTK2 2.8.x, I was referring to GiMP 2.8.x) The problem is that the new libraries, when they did their thing, did not know how to integrate with the active GNOME desktop. There may be a file I can change or have it point somewhere... I don't know. Everywhere I asked offered no answers or suggestions.
I agree
Re: (Score:2)
No, there "may actually be/" 20 ways... The one you tried is not the best one, and not the first one you should try.
Why didn't you just forcibly upgrade glib & gtk2? I'm sure the package manager will complain, but keep going anyway, and find out if GNOME will work with the newer lib without problems... It just might.
Second to that, there's no reason you can't install multiple version of the same lib, in exactly the same location. This is not Windows... Linux h
Re: (Score:2)
Forcing upgrades of isolated components by defeating dependency locks is about the worst of all possible ideas, and most particularly so in what is after all an enterprise quality desktop. I would certainly slap anybody who tried that crap on my system, and I wouldn't support anybody who was determined to do it on their own system. My comment would be "bad idea; you will be sorry, end of discussion".
As for tossing additional versions of glib2 and gtk2 into the system, you can't do that using yum, which is t
Re: (Score:3)
In fact I do this ALL THE TIME. One of my top bookmarks is a link to a Fedora Rawhide (SRPM) mirror site. I'm always doing rpmbuilds and upgrading RHEL libs and applications to something newer.
It was quite a bitch on RHEL5... Had to get a Fedora 14 rpm SRPM just to handle the XZ compression, newer checksums, etc., and RHEL5's base packages were so old, newer versions of anything could require rebuilding much of the base system
Re: (Score:2)
I'm really curious if Nix would help in this situation. I'm tempted to install it on my machine, but have not had the time.
en.wikipedia.org/wiki/Nix_package_manager
Anyone else have any experience with Nix, or think it would or wouldn't work here?
I see the GNU folks have also forked it and made GNU Guix so it may have something to offer.
Cheers!
Not dead, Jim. But... (Score:2, Insightful)
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, in
Re: (Score:3)
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
Re:Not dead, Jim. But... (Score:5, Informative)
systemd is extremely well documented:
http://www.freedesktop.org/software/systemd/man/ [freedesktop.org]
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks/ [freedesktop.org]
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions [freedesktop.org]
http://freedesktop.org/wiki/Software/systemd/Debugging [freedesktop.org]
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities [freedesktop.org]
what the heck could you possibly be missing?
Re: (Score:2)
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.
Re: (Score:2)
Systemd will most likely be used in RHEL 7.
Re: (Score:2)
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, bu
Re: Not dead, Jim. But... (Score:2)
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.
Really? I'm not in the habit of having any sort of GUI on Linux servers. When I encounter a GUI on a server I inherit, I judge the previous maintainer to be sloppy.
Perhaps it's a generational thing, perhaps I'm missing something. More than superfluous, I view GUIs as a waste of resource.
Perhaps it's
Re: (Score:2)
"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.
Re: (Score:2)
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?
Re: (Score:2)
"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 acc
Re: (Score:2)
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 ge
Re: (Score:2)
"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
Re: (Score:2)
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
Re: (Score:3, Insightful)
"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 ex
Re: (Score:2)
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
Re: (Score:2)
".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 choice
Re: (Score:2)
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.
Re: (Score:2)
".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
Re: (Score:3)
Re: (Score:2)
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, progr
Re: (Score:3, Insightful)
"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" sw
Re: (Score:2)
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.
should I install it? (Score:2)
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.
Fedora 19 and GNOME (Score:5, Informative)
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.
Fedora 19 and Xfce (Score:4, Informative)
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.
Re:Fedora 19 and Xfce (Score:5, Interesting)
Familiarity
Consistency
Menus
Obviousness
.
Honest question here, not trolling. Doesn't your last point negate your first? If it's obvious then who cares about "familiar"? To me "familiar" is what's killing the industry from making any major progress. It's already proven that people will accept new (via iOS and Android) if it's easy enough to use.
Re:Fedora 19 and Xfce (Score:4, Insightful)
In my experience, "Familiar" doesn't have to mean "Same." Using your example, iOS shares a lot of familiarity with MacOSX. The two environments aren't the same, but they aren't worlds apart either.
I think those two points are somewhat linked. You can lose a little bit of obviousness if it looks like something that already exists (Familiarity) ... or you can lose a bit of familiarity if the system is dead simple to use (Obviousness). Gmail is one example that successfully balanced the tradeoff between Familiarity and Obviousness.
In one of my usability tests, I observed typical Windows/Mac users with average knowledge quickly figure out how to use most of GNOME 3.4 (Fedora 17) because GNOME 3.4 seemed familiar enough to Windows/Mac, programs acted consistently within GNOME 3.4, they could find actions in menus, and (most) application functions were obvious and had obvious effects.
Re: (Score:2)
1. All progress bars are lies.
2. The anaconda re-design was prompted precisely by the fact that the old anaconda had terrible usability. It was neither simple nor easy-to-use. As you're interested in usability, please read all posts here:
http://blog.linuxgrrl.com/category/fedora/anaconda/ [linuxgrrl.com]
If you go back a ways, you will find lots of detailed explanation on the usability problems of oldUI. Moving forward you will find lots of detailed discussion on the process of designing newUI and the reasons it was designe
Re: (Score:2)
I don't disagree with you about the installer. 17 was the best yet. 18 left me very bitter and figured they will have a lot of work to do on the "new" installer and hope 19 is improved.
But you should not condemn Fedora based on Gnome... that has nothing to do with Fedora. JUST DON'T USE GNOME. Install the KDE spin or the XFCE spin or the LXDE spin and be happy and don't look back. Maybe they should offer a MATE spin, but I have never been all that impressed with Gnome (old or especially new) in the fir
Re: (Score:2)
F19 anaconda is massively improved from F18's. I do wish people would quit moaning about F18's in a thread about F19 and just try the damn F19 installer already...
feh (Score:2)
As long as it uses systemd, FCwhatever is dead to me.
Re:You forgot both. (Score:5, Funny)
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).
Re: (Score:2)
Because it's new! New == Better
Hasn't Microsoft taught you anything?
LOL j/k
Re:Gnome3 (Score:5, Interesting)
Re:Gnome3 (Score:5, Interesting)
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.
Re: (Score:3)
" 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
Re: (Score:2)
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.
Re:Gnome3 (Score:4, Informative)
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.
Re:Gnome3 (Score:5, Interesting)
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).
Re:Gnome3 (Score:4, Informative)
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)
Re: (Score:3)
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.
Re: (Score:2)
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?
Re: (Score:3)
Gnome 3 works well in a VM or with remote X on headless servers?
That's news to me.
Re: (Score:2)
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?
Re: (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
Why on earth not?
Because most servers don't have a monitor connected to them?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Works fine with Spice. http://spice-space.org/ [spice-space.org]
Re:Gnome3 (Score:5, Informative)
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".
Re:Gnome3 (Score:4, Informative)
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.
Re: (Score:2)
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.
Re: (Score:2)
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,
Re: (Score:2)
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 decisio
Re: (Score:2)
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.
Re: (Score:3)
"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 sayin
Re: (Score:2)
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.
Re: (Score:2)
s/udb0/usb0/, doh. Sorry, the "preview" button is there just to make the interface look less empty, right?
Re: (Score:3)
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 th
Re: (Score:2)
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.
Re: (Score:3)
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)
Re: (Score:2)
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.
Re:Gnome3 (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
I was using virt-install which (according to its man page) defaults to --graphics vnc if the DISPLAY variable is set.
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
That addresses Gnome3. Now how to propose to address the hell of systemd?
Re: (Score:2)
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)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Gnome3 (Score:4, Insightful)
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.
Re: (Score:2, Interesting)
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.
Re:Gnome3 (Score:5, Informative)
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 [0pointer.de]
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 [0pointer.de]
Very good stuff. A must read for any Linux SA, whether they think they dislike systemd or not.
Re: (Score:3)
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 [0pointer.de]
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 [0pointer.de]
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?
Re:Gnome3 (Score:4, Informative)
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.
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:2)
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 impr
Re: (Score:2)
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 somet
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
"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 [fedoraproject.org] :
"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
Re: (Score:3)
I know what you mean, dude. 36 years ago the supermarket down the street gave me short change. I've never been back since.