Beefy Fedora could use a dash of miracle whip If you’re called Beefy Miracle, you better pack a punch. And when the Fedora crew christened their next Linux desktop, that was certainly the plan. On the menu was “over and under the bun improvements that show off the power and flexibility of the advancing state of free software.” While Fedora 17 is certainly beefy, what's …
"Another far more disappointing thing missing in Fedora 17 is the Btrfs file system, which was originally slated as default with this release but which didn’t make the cut. You can still opt to use Btrfs during the installation process, but it won't be the default until Fedora 18."
Actually, it's worth noting that you can't easily use btrfs during installation with Fedora 17, due to an Unfortunate Concatenation Of Circumstances (I hear that's what the cool kids are calling 'bugs' these days).
We have an extensive rewrite of the anaconda (installer) UI planned. This was originally going to land in Fedora 17, but it turned out there was no way it would get done in time for that, so now it's targeted for Fedora 18. However, during the time when it was still slated for Fedora 17, the *backend* code for handling btrfs partitioning got rewritten to be much more complex and capable (it actually takes advantage of btrfs' neat capabilities, rather than just treating it as a dumb filesystem like ext4). Since the idea was that the new UI would land, the old UI partitioning code wasn't updated for the new btrfs backend code...so when we changed course and decided to stick with the old UI for F17 after all, btrfs wound up between a rock and a hard place. No-one had the time to spend considerably rewriting the old UI's partitioning code to deal with the new, complex btrfs backend handling, so we just disabled btrfs as an available filesystem during interactive install of F17.
You can still use btrfs for partitions when installing F17, but only if you do a kickstart (scripted) install. You can't do it during an interactive install. It'll be back, along with the UI rewrite, in F18.
This is all mentioned in the release notes, but of course El Reg readers and journalists are far too cool to read documentation. ;)
Er, bit confused: the headline is "Beefy Fedora could use a dash of miracle whip" and the third paragraph reads "While Fedora 17 is certainly beefy, what's been delivered with this first and only beta is not particularly miraculous.", but the rest of the article doesn't seem to say anything particularly negative at all about the Beta. I'm not quite sure how to read that - did you find problems that got cut from the article, or is it just the case that you didn't feel there were any gigantic changes? Just seems a bit unclear. Thanks!
The GNOME conception is somewhat more nuanced than the article makes it out to be. The idea is basically that controls which are *universal to the app in question* - i.e. affect the whole app, not any particular window of that app - should go in the top bar. Controls which are *specific to a particular app window* should go in that window.
This is really an attempt to address several age old conundrums, like 'does Close mean "close the app" or "close the window"?' and the like. There was a rather illuminating thread on either the test@ or devel@ list somewhat recently where the concept was explained pretty well, but I can't find it for the life of me. The design whiteboard for the 'app menu' is at https://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu .
The old saying about trying to polish a t*rd springs to mind.
The big issue I have with most major desktop interfaces these days is that they're too obtrusive and take up too much desktop space.
My desktop space is at a premium and is where I do my work so the less of it that the interface takes up the better. The trouble is that the current trend is to use more and more of this valuable screen real-estate for something that's only used for starting apps; after you've done that the desktop space used by the interface is just wasted.
Furthermore, scattering parts of this interface all around the screen, at both sides and top & bottom, just runs up mouse mileage and slows me down - on a large/hi-res screen this means excessive hand movement and is a real problem for anyone who doesn't have lots of clear space to physically move the mouse around.
Personally, I don't have any desktop icons at all - why TF should I have to dock half a dozen app windows, or more, just to start something else? My quick launcher panel applet currently holds my 16 most often used apps and when I need to use the 'start' menu I know where the stuff I need is located (and doesn't require excessive mouse movement).
Isn't the fact that most of these wasteful desktop interfaces now have to include a 'Show Desktop' button somewhere on the screen an indication that their design is badly flawed? Not only does that button use yet more screen real-estate but it also means additional actions that have to be performed before you can actually do what you want to do.
These desktop interfaces are only good for people who like playing with desktop interfaces.
Have you actually used GNOME 3? One of its major selling points is that unless you're actively using it to launch an app or manage windows/workspaces, it pretty much gets out of your way and stays there. There is only a top panel, unlike the default top *and* bottom panels in GNOME 2; the systray and notifications are only visible when something happens or when pulled up manually; by default the file manager does not run in the root window, so there are no icons on the desktop at all.
Your complaints about "most major desktop interfaces" sound, to me, like exactly the sort of issues the GNOME Shell team are trying to address with their design. Give it a try, you might like it.
Used Gnome 2 (was easy enough to kill one of the default panels and customise the remaining one) until it got too dumbed down, then switched to KDE 3 until it was replaced by KDE 4. Currently using Trinity (a fork/continuation project of KDE 3.5) and whilst it does have some of its own problems I can customise it to perfectly suite me (include what ever applets I want, change position, size, colour etc). I can use as many panels as I like (with or without autohide), or even none at all if I keep a tiny bit of the desktop clear.
There's just no attraction to switch to something that's so contrived as Gnome 3 (or for that matter, KDE 4 as well) and, judging from the majority of comments I see, disliked by most who have tried them.
...and then there are the issues trying to use some of these desktops that rely upon h/w features to work properly over vnc...
That doesn't change the fact that your earlier complaints about desktop environments taking up too much screen space, scattering interface elements around the screen, requiring a "show desktop" button and encouraging excessive mouse movement can't really be levelled at GNOME Shell, IMHO. (The "Activities" button in GNOME Shell is *not* a "show desktop" button; it opens the activities overview, which un-hides the dock & workspace switcher, shows open windows Expose-style, and can be used to find and launch applications not on the dock. It can be activated from the keyboard.)
I don't think GNOME Shell is perfect, and am dreading the introduction of application menus integrated into the top panel; but of all the complaints I've had, I've never once thought "this is too cluttered" or "this takes up too much screen space".
started the live cd in an old emachine with a decent graphics card connected to 1080 hdtv and it ran smooth. Tried to boot on my '04 poweredge with a self-adjusting monitor capable of resolutions better than 1080 and the monitor shows "input not supported" WTF!? That has NEVER come up before with anything on said monitor. (yet another reason to leave 14 on that server? or perhaps gnome3 just doesn't belong anywhere near my desk)
"new unified file system layout: that is, everything now lives under /usr. The plan is to get rid of the separation of /bin and /usr/bin, as well as /sbin and /usr/sbin and so on. All files from the top level directories will now be found under their /usr equivalent."
Does this not sound like a bad idea?
I thought part of the idea of having separate /s?bin and /usr/s?bin was that you could boot a system with just the root FS, not needing to mount /usr, and have the essential tools available. So, if tools are moved into /usr and the root-level directories contain only symlinks, this functionality is borked, and your system is screwed if it can't mount /usr.
This may not be a problem for most desktop systems, which generally seem to be installed in a single root partition (eurgh!), but for those of us who do things the "right way" would be just as vulnerable to /usr corruption as the rest.
Hope this "improvement" doesn't happen to Debian any time soon.
Thanks, Mangobrain-- that page that you linked to provided some interesting reading. Even more interesting was something that that page linked to, which was a comment written by Rob Landley discussing the original historical justification for the /bin vs. /usr/bin split, which can be found here:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
Apparently, all of this trouble with /bin vs. /usr/bin started when Ken Thompson and Dennis Ritchie ported the original UNIX operating system (which they had developed on a DEC PDP-7 two years earlier) to a DEC PDP-11 in 1971. The PDP-11 had a pair of 1.5MB RK05 disk packs for storage. Originally, they had the operating system's file system completely stored on just one of these RK05 disk packs, until it grew too large to fit. So they split the file system across a second disk pack, which was as you might of guessed was mounted as "/usr". They called it "/usr" because they initially moved all of the user directories there, however they soon replicated all of the OS directories, such as /bin, /sbin, /lib, /tmp, etc. over there as well because the first disk pack was out of space. Soon they were running out of space on the second disk pack, so they acquired a third RK05. Once again they initially moved the user directories to the new disk pack, and mounted the new third disk pack as "/home". This allowed the operating system to then fill the first two disk packs ("/" and "/usr"), with all of the operating system directories duplicated on both of them.
So if this comment by Rob Landley is correct, the only historical reason for having the file system split between "/bin" and "/usr/bin" and other such duplications was due to the original small disk capacities of the PDP-11 that UNIX was developed on 40-years ago. The file-system split was never actually meant to become used for all of the different reasons that some Linux distros use it for today. All of those rules about what should be included in "/" versus what should be included in "/usr" were apparently manufactured both by third-parties and standards bodies over the years, diverged between these various groups over time, and thus are now very incompatible and distro-dependent.
Originally coming from the Microsoft Windows world, when I first started messing around with a version of Sun Solaris twelve-years ago I couldn't make any sense out of the layout of the UNIX file system, and why some programs wanted to be installed in /opt, other programs wanted to be installed in /usr/bin, still other things wanted to be in usr/sbin, why there was both a /bin and a /usr/bin, etc. Now it seems that the reason why none of it made much sense was because there really *was* little sense behind it by that time-- it all came about from a file-system layout that was split due to 1970's hardware constraints that made sense during that time yet no longer generally applied in the modern day, and yet developers still kept the convention in place, inventing new and sometimes arbitrary reasons to justify why they installed their files in whichever one of those directories that their personal philosophy considered to be the "Right One."
Also interesting is the fact that Fedora isn't the first UNIX-like operating system to attempt the "/"-"/usr" file system unification-- apparently Oracle did it first with Solaris 11. My Sun SPARC boxes are all still running Solaris 10, so I was unaware of that development in the new version. Hey, you learn something new every day! :)
Thanks for the historical info, you learn something new every day :)
However, there is still a case for keeping the "Linux" way of splitting / and /usr. I have used it for those reasons for years and would be very uncomfortable moving a server to a "unified" layout.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
