Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Operating Systems Red Hat Software Upgrades Linux

Fedora 19 Beta Released: Alive, Dead, or Neither? 171

Posted by timothy
from the let's-not-make-a-fedoral-case-out-of-it dept.
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.'"
This discussion has been archived. No new comments can be posted.

Fedora 19 Beta Released: Alive, Dead, or Neither?

Comments Filter:
  • Sorry... (Score:5, Funny)

    by fuzzyfuzzyfungus (1223518) on Tuesday May 28, 2013 @09:54AM (#43840595) Journal

    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)

    • There are 4 possible states
      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)

    by erroneus (253617) on Tuesday May 28, 2013 @10:19AM (#43840949) Homepage

    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*

    • 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 ye
    • My advice: run debian wheezy, and if there's newer stuff you can't get, move to jessie.

    • by evilviper (135110)

      It seems conflicting versions of GTK for the Desktop UI and the requirements of 2.8.x created a bit of an impossible situation.

      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?

      It is GNOME's fault for selecting GTK instead of forking it or something else.

      Hell no! GTK is a library, and developers should NOT be scared away from using libraries of other projects. The only way you can

      • by erroneus (253617)

        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

        • by evilviper (135110)

          Turns out there may actually be a way.

          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

          • by fnj (64210)

            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

            • by evilviper (135110)

              This is not as easy as you claim, and I highly doubt you ever did exactly this.

              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

    • by EETech1 (1179269)

      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!

  • by arth1 (260657)

    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

    • 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

    • by kthreadd (1558445)

      Systemd will most likely be used in RHEL 7.

    • 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


    • 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

    • by AdamWill (604569)

      "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.

      • by arth1 (260657)

        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?

        • by AdamWill (604569)

          "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

          • by arth1 (260657)

            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

            • by AdamWill (604569)

              "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

  • 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)

    by Jim Hall (2985) on Tuesday May 28, 2013 @11:23AM (#43841707) Homepage

    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)

      by Jim Hall (2985) on Tuesday May 28, 2013 @11:38AM (#43841903) Homepage

      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:

      1. Familiarity
      2. Consistency
      3. Menus
      4. Obviousness

      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.

      • by geek (5680) on Tuesday May 28, 2013 @12:58PM (#43842845) Homepage

        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.

        • by Jim Hall (2985) on Tuesday May 28, 2013 @02:10PM (#43843435) Homepage

          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.

    • by AdamWill (604569)

      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

    • by markdavis (642305)

      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

      • by AdamWill (604569)

        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...

  • by FreeUser (11483)

    As long as it uses systemd, FCwhatever is dead to me.

When you don't know what you are doing, do it neatly.

Working...