Feeds

back to article Fedora 17: Mm.. this stew of beefy source tastes just right

Fedora 17 arrived on Tuesday following a three-week delay. Nicknamed Beefy Miracle, the Fedora Project promised "over and under-the-bun improvements that show off the power and flexibility of the advancing state of free software". That's a bold claim for a package with such a ridiculous name. While this is a solid update with …

COMMENTS

This topic is closed for new posts.
Silver badge
Flame

What the hell is it with this unified menu nonsense?

First Ubuntu, now the Hat which is Red.

One step forward and two steps back, it seems.

Either stick with one menu per application, nicely attached to the application window, or get rid of all of them and go for a finger-pokey fondleslab interface, where all the useful stuff is hidden away and really only available to power users (as long as it *is* available, of course).

The argument that 'Gnome has decided it will be this way' is invalid, as demonstrated by Mint, but worse than that is the mish-mash of some apps that use the unified menus and some that still draw their own; there is absolutely no reason why that should be allowed to happen.

It's taken ten or fifteen years to get rid of most of the trash that X left lying around, with different menus, mouse clicks, and even fonts for different applications, and Linux, irrespective of brand, achieved a pretty good and consistent look and feel a couple of years ago. But it seems that there's a conspiracy to prevent people using computers for anything but toys... and not just in Linux; Windows is equally to blame, and of course the Mac has had the ridiculous menus for years.

Let's either stick to something that works, or go the whole hog and get rid of menus completely (though I doubt the latter is possible; even lots of friendly toolbar icons leading to message boxes loaded with tabs are menus in all but name).

Example: when creating an ebook from scanned images, I use (in serial order but pipelined) two console applications and five GUI applications. None of the GUIs use much from the menus but what they do use, they need. None of them run full screen, either... and I *need* to be able to see an image of a page being proofread as well as the proofreader. This is not a task which lends itself to a common menu without confusion.

I'm beginning to feel that they are out to get me...

6
1
Anonymous Coward

To improve taste...

... season liberally with Cinnamon...

0
0
Anonymous Coward

Re: What the hell is it with this unified menu nonsense?

"Mac has had the ridiculous menus for years."

Maybe so but it's consistently ridiculous, all apps align with the single menu bar fixed in one place, they don't setup their own camp on top each app's window one minute and then align the next, and at least with Apples form over function ethos consistency is drummed into every Mac app designer and developer from year dot!

Quite frankly I don't give monkey's what we have but I wish GNOME would just piss or get off the pot, dithering about with one set one way then half arsed set another way just makes people take one look, drop it and run scared back to the safety of Windows and/or OSX.

4
1

Re: "Unified" Menus

It seems like the Gnome project is out to take all the worst ideas from other platforms and make them compulsory. That stupid "unified" menu bar is probably the single most retarded thing about Mac OS, and leads to lots of completely unnecessary confusion as very often it's not at all obvious which application currently has focus.

One reason I did like (OK, tolerate) gnome 2 was that it was quite well suited to multi-user systems where menus and taskbars etc could be assigned (or forced) on a system-wide basis.

It's sad to see the most promising open source desktops completely ignore "business" use like this, Linux was a natural fit for multi-user machines otherwise.

0
0

Re: What the hell is it with this unified menu nonsense?

"Either stick with one menu per application, nicely attached to the application window"

Ah, 'the application window'. A great concept until you have three of them.

The point of the application menu is to contain actions that affect _the entire application_, not a single window. Actions which affect a single window will continue to reside in the menu bar in that window.

It's a pretty simple concept, really.

1
0
Silver badge

Re: What the hell is it with this unified menu nonsense?

>>> It's a pretty simple concept, really.

Thank you. I'm a pretty simple person.

Nonetheless I'm having a hard time envisioning a multi-window application which requires both individual menus on windows and a common menu (one ring to rule them?).

If it's something like XSane then different menus apply to windows that need them; no menus are on most of the windows, though. Gimp is similar (and in my opinion, something of a mish-mash, but that's just my taste in interfaces). Tabbed applications like Kate or gedit have only one document visible at a time and so the menu is automatically relevant to that document; applications like Open Office run one window - with menus - per document.

Where does it make sense to abstract some, or even all, of the menu to a place on the screen which while it might be easy to find may be some distance from the application itself, or indeed on a different screen?

0
0

Re: What the hell is it with this unified menu nonsense?

Classic example is 'Close'. What are we closing exactly? Why do you have to close each window one by one just to quit the app?

1
0
Silver badge

Re: What the hell is it with this unified menu nonsense?

But that is surely a paradigm shift to 'using an application' from 'working on this data set', no?

Why would you want - or expect - every instance of an application to close at once?

One of the true benefits of the various linux desktops is that they offer multiple work surfaces; I tend to use four. And I might have half a dozen applications open on each, each dealing with some different work function. Given that I might have, say, a word processing application open on three work surfaces at once, two of which are invisible to me, why would I want to close the *application*?

Maybe it's just not the way I work. Maybe I'm a stone age throwback Luddite who shouldn't be trusted with anything more technologically advanced than a clay tablet. But I remain a firm believer in the rule of 'don't surprise the user' and I still consider the data to be the important part of what I'm working on, not the application itself.

0
0
Bronze badge

Improved scrolling?

What on earth is improved scrolling?

You grab the scroll bar, and drag it up or down - and it works. That's what I've just done.

It's worked for twenty years or more. What on earth is there to improve?

And the "improved" scrolling has "harder to grab" scrollbars, which may be harder to use for some users. That's improved how, exactly? (At least they haven't gone for the disappearing/magically reappearing sometimes scrollbars that Ubuntu invented...)

9
0
Anonymous Coward

And window borders about 1px wide

which is really getting my goat on Xubuntu right now.

0
0

Re: Improved scrolling?

Improved scrolling probably refers to the fact that it's now smoother.

0
0
Silver badge
Mushroom

Re: Improved scrolling?

Right, so the eye candy has been improved while the actual scrolling function has degraded.

It seems we have had a generation change in OSS. Yesterdays ADD children have become the next generation of developers, doing shit because its kewl and throwing all usability out the window for the sake of rendering tricks and mad transitions.

1
0
Silver badge

No joy on VirtualBox

I have a FC16 image on VirtualBox and I went through the motions of installing the "preupgrade" app, running it, letting it go all the way through. Now I have a system which boots but shows "Fedora 16" in the console progress bar and then stops when it hits 100%. As if some .rpmnew is sitting around for me to discover that it didn't replace the boot sequence from FC16. Not a good first impression.

A laptop at home which I installed from the live CD worked a lot better.

0
0
Bronze badge
Linux

Re: No joy on VirtualBox

This is down to kernel versioning, recent Fedoras keep up with stable kernel versions and if that means that F16 has 3.3.7 but the installer for F17 has 3.3.4 then things can get confused.

I would suggest that you look at the F17 Common Bugs page, it's easy to find using Google and provides ways to fix a small number of problems that often catch people out.

0
0
Silver badge

Re: No joy on VirtualBox

I don't think it even installed the fc17 kernel at all. All grub shows are the fc16 ones. Probably explains why it won't finish its init.d properly.

0
0
Silver badge

Re: No joy on VirtualBox

Hmm, now I discover it did install the kernel but didn't put it in the grub bootloader. But after updating the bootloader I get a bunch of errors about configuration issues. It's depressing when crap like this happens. I think I'll give up and reinstall.

0
0

Re: No joy on VirtualBox

that's due to:

https://fedoraproject.org/wiki/Common_F17_bugs#upgrade-old-kernel

Well, at least the 'Fedora 16' in the progress bar part is. It's a surprisingly difficult thing to 'solve', from our end, as long as F16 kernels are going to be kept up to date with F17 ones.

That shouldn't normally prevent the system booting, though. That sounds like it may be a different problem. Can you boot it to a console at least?

0
0

UI consitency

" Of course, if user interface consistency is your highest priority then you probably aren't using Linux anyway."

I assume if that is your priority you're using a Mac, because Linux is far better at this than Windows.

Almost every piece of software on my Windows box styles it's window, menus, UI controls etc differently. Admittedly I don't use it for much, but the differences between Firefox, Chrome, Thunderbird, Traktor, iTunes, Live and various device-specific pieces of software (Sony Reader app, SEUS, the stupid bloatware graphics driver, the ridiculous trackpad controller, etc) are astonishing. There's a wider variety of weird chrome on show than a saturday afternoon at a scooter convention.

Most GTK apps look very similar, because they are all drawn using GTK toolkit so they can't help it. Menu layouts might be a bit variable, but it's getting better. KDE is even better than Gnome on the UI consistency front - almost MacOS good, I'd say, which is a pretty good achievement - because the situation used to be awful for both Desktops, back in the day.

3
1
Silver badge
WTF?

…Unix disk space issues that were solved decades ago

This has nothing to do with disk space, and all to do with booting, availability and recovery.

Essential programs for using the system live in /bin and /lib

Essential sysadmin programs for fixing the system live in /sbin and /lib

OS installed programs live in /usr/bin and /usr/lib

OS installed sysadmin utilities live in /usr/sbin and /usr/lib

User installed programs live in /usr/local/bin and /usr/local/lib

When you boot up single user, you would typically only mount what is necessary to boot - /. This typically includes /lib, /bin and /sbin, so the programs found in there are what enable you to go multiuser.

I suppose it does make sense that linux would drop all these conventions. Every linux distro I've used has no concept of an "OS", just a collection of packages that get installed that make up the OS. Something that I would consider part of the OS - like OpenSSL - is instead bundled up as a package and installed alongside something utterly irrelevant, like xchat.

Given that they already drop that useful distinction, just sticking everything in one place probably felt natural.

2
1

Re: …Unix disk space issues that were solved decades ago

Pretty much any *NIX I've used is just a bunch of packages not just Linux. Solaris has been going down this filesystem consolidation route for some time as well. In Sol 9 and 10 /bin is just a symlink to /usr/bin and from what I understand 11 has taken this further. Indeed one of the arguments I've seen in favour of this change is to increase compatibility across *NIXs with everything being found in the same place.

Note that I'm not sure I agree 100% with this, having /usr on a read only or remote filesystem has its place on many systems.

1
0
Linux

Re: …Unix disk space issues that were solved decades ago

"I suppose it does make sense that linux would drop all these conventions."

I suggest you read the "Linux Standard Base" and the "Filesystem Hierarchy Standard" documents.

1
0
Silver badge

Re: …Unix disk space issues that were solved decades ago

The best thing about standards is that there are so many to choose from. LSB and FHS are documents about how Linux people want to organize Linux.

Furthermore, they illustrate my point about these directories not relating to disk space issues. From FHS:

/bin

Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp.

/sbin

Essential system binaries, e.g., init, ip, mount.

/usr/bin

Non-essential command binaries (not needed in single user mode); for all users.

And so on. The need for a standard was to rein in all the various distributions that would install packages in particularly obscure locations like /opt. It is not necessary for proper UNIX OS like FreeBSD or OpenBSD, who have hier(7) that date from V7 UNIX, and already arranged their filesystem in a sane manner. Compare and contrast FHS with hier(7), you will see that FHS is simply a cut down and simplified version of hier(7), with added Linux-isms.

2
0
(Written by Reg staff) Silver badge

Re: …Unix disk space issues that were solved decades ago

All interesting stuff, and be as that may, the reference to the "disk space issue" is explained here: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Hope this helps.

C.

2
0

And there I thought...

... /sbin was for statically-linked binaries, in case someone screws up your shared libraries (or they happen to be unavailable during startup, for example, because they are on a volume that needs to be mounted.)

0
0
Stop

Re: …Unix disk space issues that were solved decades ago

"This has nothing to do with disk space, and all to do with booting, availability and recovery."

No, it doesn't. Your theory has several advantages:

* It's commonly cited

* It's cogently argued

* It all looks like it makes sense

And only one disadvantage, which unfortunately is quite a large one:

* It's wrong

Background!

https://fedoraproject.org/wiki/Features/UsrMove#You_are_doing_it_wrong.21_.2Fbin_and_.2Fsbin_are_there_to_rescue_a_broken_.2Fusr.21

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html (yes, the /usr split really does trace back to Thompson and Ritchie and a very small hard disk, in 1971).

Believe it or not, there are lots of greybeardy types involved with Fedora and other projects who've looked at the /usr split and concluded it makes no damn sense and has absolutely no advantage. Having a historical perspective is in fact an _advantage_ in doing so. We did really think about it. Honest.

1
0
Bronze badge

"It does not, however, show results for applications that are in the repos but not yet installed, a nice new feature you'll find in the latest version of Ubuntu's Unity search tool."

Sarcasm?

0
0
Bronze badge
Paris Hilton

GNOME 3.4 continues to polish GNOME 3

Yes, nothing like getting your GNOME polished.

1
0
Pint

Beefy Miracle....

....why do I suddenly crave a large hamburger or steak?

0
0
Trollface

Btrfs?

Whilst having support for file systems is nice I do wonder how much "Demand" there is for Btrfs?

Curious how many people who run Fedora would actually plump for anything other than ext4?

Now ZFS and something like Dtrace would be interesting.

As to the problems people may have with it just now, you know why it's called the bleeding edge don't you?

Sent from

[root@localhost ~]# uname -r

3.3.7-1.fc16.x86_64

0
0

Re: Btrfs?

"Curious how many people who run Fedora would actually plump for anything other than ext4?"

Quite a lot. I mean, Fedora's meant to be an experimental, bleeding-edge sort of a distro. If you're the kind of person who wants to play with btrfs, the chances you're running Fedora are quite high.

The review gives something of a misleading impression of Fedora's btrfs support, although it's not _wrong_ exactly. The key thing it misses is that btrfs support actually regressed in 17, which is unfortunate but somewhat unavoidable.

From, oh, 11 or something like that through to 16, we've had support for btrfs in the installer. (For several of those releases you had to pass a sekrit parameter on boot to prove you were smart enough to read the documentation and so with any luck smart enough to know that btrfs was likely to eat your data and your babies for dessert, but the support was always _there_). However, btrfs was treated more or less as a dumb filesystem like ext*; there was no account taken of its advanced features like volume management or mirroring.

There's a new anaconda UI in the works, and it was initially planned to land in F17. So someone went ahead and rewrote the btrfs support _backend_ in anaconda to be much smarter and support all btrfs' advanced features. The frontend in the old UI code was not updated for these changes, because the idea was the new UI would be arriving anyway.

unfortunately the new UI, er, didn't arrive, it was clearly not going to be done in time for F17 so it got postponed to F18. This meant we were stuck with some smart new backend code but no matching frontend code (the mix is explosive, you just get a crash). It seemed something of a waste to devote considerable resources to extensively updating the old storage UI for a single release, and rolling back to the old backend code wasn't really very easy to do either, so in the end we plumped for just temporarily disabling btrfs support in the interactive installer for F17 as the easiest option. It will return with the new anaconda UI in 18.

0
0
Thumb Up

Re: Btrfs?

Cheers makes sense!

Just wondering how it compares to say ZFS what with Oracle now "being involved" with two designs which seem to have quite a lot in common.

If you wanted to play with Btrfs would you be better looking at "Oracle Unbreakable Linux"?

0
0

Re: Btrfs?

Well, er, for a start, you shouldn't ask anyone from Red Hat that question. We listen right up to 'Would I be better looking at Oracle' and then start saying 'no'. =)

I honestly don't really know how btrfs compares to ZFS technologically speaking. What I can probably say without risk of controversy is that btrfs is far, far better integrated with the Linux kernel. ZFS remains mainly a Solaris technology for technical and licensing reasons (I believe). btrfs is core Linux kernel stuff.

See http://zfsonlinux.org/faq.html for some more info.

I am not aware of any reason Unbreakable Linux would be any better than RHEL for using btrfs on, but then, it's not my job to know much about either. AFAIK, Unbreakable Linux is essentially a RHEL clone with a different kernel build available. I don't think they do anything particularly special to btrfs in the kernel build, but IMBW.

It's probably not yet a great idea to mess about with btrfs with anything that even _smells_ like a critical workload, yet, whether you're running Fedora, RHEL, Oracle or anything else.

0
0

Beefy Miracle?

Sorry, Fedorans, but there should never be a codename with the initials B.M. <shudder></shudder>

0
0

Re: Beefy Miracle?

I take it you never read 8-Bit Theater, then. Or play Final Fantasy games. Bit of a loss for you!

0
0
Anonymous Coward

FAIL again

And again, GNOME proves that they've got their heads so far up their own arse, they refuse to believe that their pre-conceived ideas about what they think users *should* want may not be what users do want. But ooo, this looks FUNKY and DIFFERENT so it must be GOOD because we can spout pseud-style justification for why they are always right, usually based on over-trivialised models of users' behaviour. (Hint: just because a lot of people use a computer for monotasking use of facebook, twitter and web browsing, doesn't mean that as long as it works in those cases, it must be good).

Barkeep, make mine an XFCE.

And this flame isn't just my own pointless words, my company has supported GNOME to date in its flagship product, but is dropping it and moving to QT (KDE). We see no long-term future in GNOME justifying the effort of continuing to update for this absurdly behaving moving target.

0
0
This topic is closed for new posts.