Slashdot Mirror
Red Hat 8.0 Reviewed
Jon writes "Eugenia from OSNews is giving Red Hat 8.0 a run for its money. She posted a very detailed and balanced review for the new version of Red Hat, which aims to be a "business desktop". Very interesting article and discussion over at OSNews." Several people also sent in the stories from InternetNews as well as LinuxPlanet.
You can read a users take on Red Hat 8 and KDE here/ I'll update it soon with screenshots and soem more info on the services bug.
You can tell redhat sucks cuase it's easy to install.
That's why i use gentoo.
It's so eleet it doens't even have an installer!
you just copy the stuff over by hand!
that just proves you have to be eleet to use it!
my mom got mad when i installed it on our dell in the family room but it's just cuase she's not leet!
you posers in the data centers running redhat on the huge server farms are pussies compared to my leet mp3 server!
uh my mom needs to get a recipe off marthastweart.com, gotta go!
keep it leet!
w3rd em up!
I just tried Mandrake's latest release on a dual Celeron 533 and a Tecra Laptop, both dual boot systems. I had the latest Redhat beta ((null)) and installed it right after installing Mandrake. No comparison. The Redhat interface looks much better, and the intergration of the menus is a much needed improvment. All of the program defaults make logical sense to me, as I use OpenOffice, Moz, and Evolution by choice.
I am waiting for the mirrors to update RH 8.0 like a Lion waiting for fresh meat.
I may be bad with names, but I'll never forget your IP address
Buzz -> Rex -> Bo -> Hamm -> Slink -> Potato -> Woody -> Sarge -> Eugenia
Wouldn't it be nice if developers in the free software community read things like this and took the criticisms to heart as seriously as if someone had knocked them for not using a free license? That is, the community has some peer pressure for acceptable software: using a free software license (GPL, LGPL, BSD), sharing code but with appropriate attribution, using open standards and tools (autoconf, etc), and so on. The openness of the community and this system of taboos have arguable produced better software and certainly gotten us closer to a free software world. Could the same pressure potentially lead free software application developers to enforce good GUI design habits as well as good programming habits? When users give feedback like the above that says "hey, your program may be cool, but you aren't following good UI design principles" and this criticism carrys weight similar to telling someone that they should use a free software license, then perhaps free software can really evolve past its geek-oriented roots to something that the masses can embrace.
Curmudgeon Gamer: Not happy
Ahemm. Watch out, Apache 2.0 will bite you in the ass if you're not careful.
Null used Apache 2.0 as apposed to 1.3.26 in RH 7.3. So yer default config files are now somewhere else, and all of your carefully massaged virtual things are now nowhere to be found. It can be fixed pretty easy, just RTFM.
There are probably a few more "gotchas" but that one stuck out like a sore thumb.
I may be bad with names, but I'll never forget your IP address
Many things, like Flash Player and Acrobat Reader are available on the Applications CD.
We don't put closed source, or binary only software into the distribution itself, that's what keeps our distro fully GPL'd.
As for the decision behind not shipping mp3 players, that has more to do with the nature of mp3 patent licensing and royalty scemes. There used to be very clear terms allowing us to ship such things, but that seems to be changing, at least enough to put it in the gray area.
That said, nothing is stopping an end user from getting any of the software they are used to having on Red Hat Linux, we chose to err on the side of caution and not become someone's test case for litigation down the road.
On the other hand, try using Ogg Vorbis instead of mp3. It's not so encumbered with gray area, it's open and patent/royalty free.
And anyone having run a few benchmarks knows
1) Compiling for Pentium sucks on anything who is not a true Pentium. On a PII/PIII and on the K6 (I don't have access to an Athlon or PIV) they are markedly slower than code optimized for the 386 and much slower than code compiled with -mcpu=i686
2) Using the -march=i686 allows gcc to use PII/PIII specific instructions but benefits are small (about 2%) respective to -mcpu=i686 so you throw away universality for little benefit. Mandrake uses -mcpu=i686 -march=i586 but gcc is not smart enough to use 586 instructions when optimizing for 686 so it silently reverts to plain -mcpu=i686.
3) For those packages where 386-only instructions don't make sense since they have perfoarmnce-critical parts written in assembler (kernel, glibc, sasl) RedHat ships packages specific to the PII/PIII family who are compiled with -march=i686 (full optimizations) and another set specific to the Athlon compiled with -march=athlon.
Umm I thought KDE was open Source (I could be wrong) so how does hacking it suck..
I thought that too, at first. I thought that some of the mistakes she made sounded like English wasn't her native language. So instead of choosing to be a smart ass and make some "clever" comment about it, I chose to educate myself. I looked up the info on the author (by simply clicking on her name at the top of the article). She is Greek, so English isn't her first language. While it isn't perfect English by far, it got the point across. In the author's own words:
I am Greek and english is not my native language. We do OSNews for fun (however, OSNews takes most of my time every day), so if you have a problem with my spelling and grammar either a) do not come back (spare us and save your time too) b) send me a proofread version of the article in question. Whining about something I can't radically improve overnight, is not an option.
My beliefs do not require that you agree with them.
Insightful.
/dev/yourharddrivenamehere. Significantly reduces "jerkiness" in X when doing disk access, including paging. For a long time, a lot of distros left this off by default.
.9 + Sound Blaster Live! with the emu10k1). It's not worth it. 99.99% of Linux users will never, ever need network transparency or any other features that you get with a sound server. They *do* want sound that doesn't break up, and having hardware mixing does that for them. Ye gods, it'd be nice to see Linux have some architecture that does "opportunistic" mixing (hardware mixing if any channels are left, software if not).
I'd also like to point out that I've done a bit of benchmarking gcc, and optimizing for a particular processor makes almost no difference on the vast majority of software.
The biggest win comes from flipping on -O3. Then if you can get away with it, -fomit-frame-pointer, which helps the register-starved x86, but keeps you from looking at stack traces and debugging crashed programs (or sending in useful bug reports). -fexpensive-optimizations have also helped a bit too, and for certain packages, -ffast-math can be big. -march=pentium2 makes next to no difference on anything I've tried benchmarking. -DNDEBUG is potentially good...seems like most production software is compiled with assertions enabled, when they're really intended for debugging.
The Pentium 1 sucked at running code compiled for the 386/486. This is why you got compilers like pgcc, a Pentium-optimized Mandrake distro, and lots of talk about architecture optimizations. With the Pentium 2, Intel realized that all software was not going to be recompiled for each processor (at least in Windows land), and did a really solid job of running 386 code.
So, as far as architectures go, the Pentium 1 is the odd man out. If you have a Pentium 1, it sucks to run any code other than stuff compiled for your chip. If you have anything else, you'll generally get very minimal gains from compiling specifically for your processor instead of for the 386.
Finally, most people don't actually care about the maybe 10% speedup they can get by recompiling software using optimization flags other than just -O2. They care about interactive latency. Look at Mac OS X. OS X is *hideously* slow, but it *feels* pretty fast because it has good UI latency -- it jacks UI priority and puts a lot of emphasis on slapping something on the screen that's updated as soon as the user does anything.
On Linux, here are the big culprits.
Jack the nice value of X from 0 to -10, if your distro doesn't already do so (take a look in top and see what it's running at). The nice value doesn't make it much "faster", but it does significantly improve latency, so you can get crisp edge-flipping and updating.
Turn *on* DMA and umasked interrupts (insert usual warnings about potential problems with *really* old computers having these on). hdparm -u1 -d1
If you're doing something that doesn't need low latency in the background, *nice* it. I run all compiles niced to 20. I can be compiling six or seven packages with no user-perceptable slowdown at all. Software that's always sucking down a little CPU in the background but still should be interactive (like lopster or gtk-gnutella) should be niced to 5 or so.
Make all your cron jobs run at nice 20 (crontab -e, edit command line to contain nice -n20). They have no reason to demand interactive latency, and you *do* need said latency for your UI.
If you run any servers on your workstation, they should run around nice 10. They need to get back to the user, but they shouldn't make your UI get unpleasant when they get hit.
Renice esd/artsd to -15. If these don't get CPU *right away* when they need it, your sound will break up. Frankly, I dumped esd/artsd, and got a sound card with hardware mixing (ALSA
Use a decent window manager. Sawfish is incredible if you're an edge-flipping maniac like me and like zero edge resistance. Why? Sawfish is actually not that *fast*, but they've compensated for that fact, which makes them beat any other window manager I've seen at edge flipping latency. Sawfish doesn't block other app redraws when edge flipping until it's redrawn its titlebars, as other WMs do, so you get much faster redisplay of app windows. Beautifl design.
Finally, I've had good experiences with redefining HZ in the kernel. Unfortunately, one of the side effects of using the X11 architecture is that anything going to the screen has to wait for a context switch -- first, the app tells X to display something, then we wait until X is active and actually display it. This isn't a huge deal unless you have a bunch of processes that all want CPU time, and you have an app or X that's blocking on I/O (say you've paged out an app). Then your ten compiles, and the lowly default 100 HZ in the x86 kernel mean that it takes a full tenth of a second just to move from the user app to X. If the app is displaying a big pixmap that has to be paged it, it has to draw a little bit, start paging the thing back in, draw a little more...it's I/O bound and yet it isn't gettting a chance to keep the ATA bus saturated. Jack HZ to 1000 or 1024 and recompile your kernel, and you should notice slightly better UI latencies (NOTE: at one point, this caused oddities in some libc call lke usleep or something, and made a couple games run too fast...I don't think this is an issue any more).
Other wins: Use mozilla 1.1 (much faster redraw than 1.0), use an up-to-date version of gtk2 (wow, the version RH is packaging is much faster at rendering aa text than the old snapshot I had from Ximian), use the blisteringly fast rxvt instead of the slow gnome-terminal or konsole. Use gnuserv mode in emacs/emacs -- that way, you open a *single* copy of emacs and then just open new windows in it. Opening files is about 50 times faster.
After following all these tips, you can play with Linux the way it was meant to be seen.
May we never see th
Here's a comment I made on another list:
I doubt if the changing of the themes and such was the problem. I would not lose any sleep over single vs double-click or a few icons and bitmaps. This would not justify Bero quitting and claiming that KDE was "crippled". Part of the real problem, ironically, is that the changes Red Hat made ARE merely skin-deep. This is exactly what the KDE project is not.
A perceptive Slashdotter earlier saw that the problem was not in the superficial reskinning, but in the integration. KDE is not about being yet another window manager, but was meant as a holistic answer to the desktop problem. A KDE desktop is meant to be a collection of integrated applications with predictable, uniform behavior. You will see the same file dialog (with URLs and bookmarks), print dialog, toolbar editor, font chooser, color picker, help infrastructure, address book, and predictable cut and paste. Sharing of components means familiar behavior throughout, such as the file manager embedded in the file open dialog or the image viewer embedded in the file manager. When you open a file, the dialog remembers the bookmarks and frequently used directories you used in other KDE apps. In other words, the KDE experience provides a uniformity, familiarity and predictability that goes well beyond mere theming or toolkits. This is good for beginners.
Red Hat has in effect substituted other apps for every major KDE app. The KDE apps are not gone, but they are less visible. This means that a typical Red Hat user will install "KDE" and never run a single significant KDE application. What you get is the usual jumble of X apps doing their own thing in their own way. Apps do not remember your favorite colors, your print settings, your favorite directories. It's the familiar X desktop: a Frankenstein collection of apps stitched together by superficial skinning, but not quite fitting together. "KDE" is reduced to being an oversized, slow window manager: nothing more. It is not really KDE. Why would anyone want to use that?
For pros, the best-of-breed approach is the status quo. IMHO, a beginner need not start this way. The default KDE apps may simply be good enough, with the common UI and infrastructure compensating for the individual weakness. Sure, a deliberate decision can be made to pick a better app, now or later. But this should be done with the concious knowledge that this goes "off the KDE ranch", that the various integration, uniformity and usability improvements of KDE will not apply. Starting off a beginner with a best-of-breed approach leaves him with the usual Frankenstein collection of disintegrated apps, all unalike. I.e., this is the status quo that KDE was supposed to fix. Trouble is, Red Hat will not let KDE be KDE.
First off let me say 1) don't usually like Eugina or her opinions and 2) I'm a big RedHat backer.
That said the review seemed pretty fair to me. She's write in saying multiple menus or counterproductive. I mean either include an app under the main area or don't include it. There should NOT be duplicate subcategories on the menu. Can you imagine if Windows XP shipped with the Acessories menu listed twice?
Second, regarding multimedia. If its multimedia abilities are as castrated as she's says, that's a big negative against RedHat 8.0. I still can't believe and MP3 player isn't included. As if that lets them off the hook for years of including an MP3 in every RedHat release?! Now Out of the Box multimedia is broken, which won't stop me, but will stop the average user who has never used linux before. There should dam well be a single button you click that restores MP3 ability. Making a user try to figure out how to get MP3 back into XMMS is NOT user friendly.
Lastly while obvisouly most people are not running at the resolutions mentioned in the article, having something as basic as being able to change your refresh rate ala Corel linux should be standard by now. It actually quite pathetic that its not.
Anyway, I'm downloading it now so we'll see how it goes. The one thing I am looking forward to is decent fonts for once. If they get that right I can probably forgive the other things.
If you wanna get rich, you know that payback is a bitch
Matthew Thomas (who does a lot of UI stuff for Mozilla) has written two really good articles that largely answer your question)
Why free software usability tends to suck
Why free software usability tends to suck even more
To address a few things mentioned in your post:
Wouldn't it be nice if developers in the free software community read things like this and took the criticisms to heart as seriously as if someone had knocked them for not using a free license? That is, the community has some peer pressure for acceptable software: using a free software license
Because Free Software is currently Freedom As A Programmer Envisions It. As the Free Software concept was nutured by Richard M. Stallman, a programmer, this is not surprising. Freedom As An End User Envisions In (also known as The Freedom To Get Stuff Done) has never really been considered by the Free Software community to be a Valid Freedom.
Funny you should mention, I'm currently drawing up a public license that enforces usability and goes after the people who've kept linux so very unusable.
The openness of the community and this system of taboos have arguable produced better software and certainly gotten us closer to a free software world.
I commonly hear this phrase "We've gotten so far on the server, it's only a matter of time before get to the desktop." Unfortunately, this statement makes the assumption that the same abilities, values, and methodologies that lead to success on the server do the same for the desktop. Linux has been doing so well on the server because people in the linux community were really good at doing server stuff. Unfortunately these people were the most absolute worst people you could have ever sent to do desktop stuff. 30 years of anti-newbie RTFM baggage, command-line junkihood, and having a userbase that entirely consists of programmers and sysadmins does not behoove the creation of high quality user interfaces. In contrast, the mac developer community has for 17 years put very strong values on consistancy and non-geeks being able to use the software. That's why they've been able to succeed on the unix desktop in 3 years where linux has failed for the last 7-8.
Could the same pressure potentially lead free software application developers to enforce good GUI design habits as well as good programming habits?
It's already been tried, and has been tried by people with very strong usability/HCI backgrounds. The response they generally get from programmers is "stop whining. If you want to fix something, you should learn how to code". Or sometimes you'll hear "Don't complain about what you get for free". Or "That's what you want, that's not what I want. That's just your opinion."
Or if a usability person criticizes a UI in front of a kernel hacker, the kernel hacker might say "I can't believe that people actually get paid to criticize the work of others" (true story).
When users give feedback like the above that says "hey, your program may be cool, but you aren't following good UI design principles" and this criticism carrys weight similar to telling someone that they should use a free software license
First of all, you have to be pro-active about creating good user interfaces. Users generally do not actively complain about specific application interfaces unless the interfaces are truly, truly, horrible. They will usually passively complain, trying to find execuses to use the program less, or unconsciously creating some workaround, or saying "I hate computers" around the watercooler. You won't get active feedback very often from users, so you need to actively watch them using your UI. So often what makes a UI unbearable is a bunch of little, annoying things that add up to one cumulative bad user experience. To catch those little things, you really have to watch the person using the interfaces. You should also do research ahead of time to learn (before you design the UI) to learn what the most common annoyances are. Unfortunately, most Free Software UI's are cranked out and *then* people try to do active damage control. Much like the world of commercial software, actually.
Another problem with your suggestion is that most of the current userbase for Free Software/OSS are the geeks who've been so clueless about good UI (and some of whom who think that HCI is a load of bull). These people adapt very, very well to badly designed UI's, often priding themselves on doing just that. They often don't take notice of the little, annoying things and are often not confused by ambiguous widget layouts or jargon-laden wording. When you consider these facts, it's not surpising why StarOffice gets such glowing reviews from the geek community. Assuming you manage to find a geek who gives you feedback about the UI, chances are he's not going to a suggestion that jives with all of what we've learned about HCI in the last 20 years. Just because you get feedback doesn't necessarily mean its usable feedback.
Hope I've answered a few of your questions.
Ergonomica Auctorita Illico!