Configs in/etc, services in/etc/init.d, documentation in/usr/share/doc, user bins in/usr/bin unless your apps is necessary to rescue to the system, sbin for yoru admin bins,/usr/lib for your libraries,/usr/share for everything else, RPM for your packages, stable releases of glibc and gcc for C library and compiler, etc.
At the end of the document, you'll find an extra section offering a list of the ports used by commonly probed and attacked services. By blocking traffic to these ports at the firewall or other network perimeter protection devices, you add an extra layer of defense that helps protect you from configuration mistake
This seems like a really bad idea. Giving people a list of port they should block traffic to implies that they needn't properly lock down their rulesets properly, andd have accept as the default policy.
I've reviewed a small amount (say, thirty) Linux / Unix / and (a couple of) Windows books for an Australian computer magazine (APC).
As a rule, if a book has more than two authors and is more than four hundred pages long, its quality is generally poor. This is because such titles - eg, most of the Unleashed series - take content from several diffferent authors, but don't maintain consistent style of build a solid learning path. One fellow explains the/etc/passwd file, then another fellow explaining NIS does a longer version of the same explanantion using a different analogy, rather than building on what the audience already knew. The change is style and analogies is often confusing for those new to the platform.
I'm not saying all huge books are like this, but because of their nature they're more than likely to need a good editor to make all the disparate content a little more seamless, and because most are churned out like nobodies' business they rarely get this attention.
Other examples of why big books are often poorer includes the 1400 page Upgrading and Repairing PCs compared to the 700 page O'Reilly's PC Hardware in a Nutshell. Upgrading and Repairing loves including charts of the details about every PC product made by every manufacturer since the edition was published. This information is generally out of date, but th books publishers tell you you can fidn newer information onlien at the oublishers web site. Well, er, actually, I can find it at any web site. PC Hardware in a Nutshell is a lot mroe concise but contains most of the useful information. What it lacks in out-of-date charts it makes up in providing users with real-world experience and facts-supported opinion by the two authors - eg, they'll tell you that HP don't often release or support newer firmware for the CD drives they rebrand, so it might be best to avoid HP gear.
Another famously bad exampel of a large book is John Chirillo's Hack Attacks Encylopaedia. Its ~1500 pages (IIRC) of mainly unedited text files from outdated h4x0r tools, with a chapter by John at the start. It disgusts me that a) he has the nerve to call himself the authro of the title when he's clearly the edit, and a lazy one at that b) that this is a so called premium security title and is charged accordingly.
They're complimentary tools. Basically, yo ucan make your own apt-get server, or use various servers on the net to install third party packages that don't come with Red Hat, like lame, xine, mplayer, etc.
Other reasons why Freshroms rocks
on
Red Hat 8.0 Released
·
· Score: 3, Informative
..for Red Hat users:
Since Fraunhofer `clarified' their licensing for MP3 encoders, Red Hat 8 doesn't include any mp3 encoding or playing tools. Freshrpms have the packages you need for playing mp3s, and even encoding them if you're some kind of sick twisted person that doesnt encode oggs yet
Xine and Totem (GTK2 Xine) packages for playing DVDs and films. Freshrpsm is based in France where CSS itself is illegal (the libdvdcss decoder is therefore fine).
Alsa, so you can let many apps use your soundcard at once, as well as many other davnatges, plus a great 5 minute howto on installing it.
Apt get to install all these funky new Linux packages (RPMs), plus the new GTK version of the Synaptic front end.
Lots of other good stuff I haven't mentioned and to come. Matthias even sometimes does requests.
A users perspective of Red Hat 8 and KDE
on
Red Hat 8.0 Released
·
· Score: 5, Informative
Most people have heard a lot on this topic, but mostly from people who haven't actually used 8.0 or Null. In fact, a good deal of the information that has been touted about the web is provably false. Some of the changes have had negative side effects that are in bugzilla, but, in my opinion as a KDE user, overall they've increased the usability of Linux desktops.
I can't see a purpose for that patch - I've read Red Hat's point of view and I still don't see how a naming conflict would realistically occur Yes see a problem here, I've repeatedly said I see a problem. However I've also corrected you when you said the side effect was intentional. It clearly isn't, or they wouldn't be fixing it.
Only RHKDE had this problem. Note that RH never fixed this bug.
That seems odd when according to your link "The problem is khtml doesn't correctly interpret the tag and thus, flash animations which are not inside a pair work ok. Like the one above." Doesn't look as if it was Red Hat's bug to fix...
So, we have a massive Redhat patch to KDE written by GNOME developers that serves no purpose except to break things in KDE, but in your mind this is somehow a "side effect".
No, the patch is not a side effect. I never said it was. The services breakage is a side effect. if it was the intended purpose of the patch, they wouldn't be trying to fix it.
Thanks for the info re: QT. I haven't been able to get as much in depth information on the content of the patch as I'd like, and I've had to reply on heresay (much as I'm doing now unfortunely - do you have a link with mroe info?). I've heard this from a couple of people and I'll update the document accordingly,
People can and have have hinted that Red Hat broke Konqueror plugins (and caused every other bug that has or will appear in their KDE) on purpose to discredit KDE. Yes, these people are idiots, but others still believe them.
Konqueror plugins and Bluecurve are both fixed. I think they have have been for a fair while.
If an application other than rm or a file manager is calling unlink() then it probably has a good reason for doing it, and you don't want the files in a Trashcan anyway
Well, I might delete the old SXW of my document after I save the MS Word version to submit to an editor in OpenOffice.
The exceptions, like Mozilla, can easily be taken care of too.
If I want to read the Redhat party line responding to what they've done, I'll go find Owen's paper. Your bias for Redhat is pretty clear: covering for them by calling their intentional breakages a bug. LOL.
You don't seem to understand the difference between Red Hat's changes and the resulting side effects. Red Hat didn't rename the.desktop files for the purposes of breaking that system call. If they didn, they couldn't be reversing their behavior by filing a high priority bug report - that makes no sense.
Stop trying to include me in the Myterious Anti KDE Sinister Organization. I always acknowledged the file renaming has no benefit I can see for end users, and I've criticised other Red Hat desktop decisions in the article too, such as the poor menu setup. Just because I agree with Red Hat on a few points doesn't mean I don't think independently: clearly I do, or I wouldn't be disagreeing with them on other points.
Oh well, your loss. The article's getting a few hits and I think you look bad by not providing evidence to support your claims of other breakages that you say aren't mentioned.
Huh? It's not a bug to Redhat - they did this unnecessary crap _intentionally_. With a HUGE patch. The RH GNOMErs (Havoc & Owen) defended what they did on kde lists.
I agree that it seems unnecessary (I can't udnerstand why they'd do it either) but I think you're missing the difference between the problem and a side effect. The side effect was unintentional - otherwise Red hat wouldn't have a highly priority bug concerning it, and wouldn't be working on a patch to fix it.
I'm correcting the document now to reflect the vfolder and system tray specs status as draft specifications.
Cheers for the correction, but you could be a bit more civil about it. As the document states, I'm approaching this from a users point of view, oddly enough, where Red Hat are aiming.
PS: The second URL you posted doesn't seem to work.
Further, you claim that every contributor is listed in "About App" boxes. I invite you to look over commit logs of any KDE application, and you'll see that there are dozens of contributors who aren't listed in the about box - bugfixers, proofreaders, people who fix up UI improvements. Heck, a casual look at kde-cvs archives will show that.
If this is the case (I doubt anybody would assume it was off the bat) then have you reported it to bugzilla?
And, BTW, I consider opinions based on inaccurate information meaningless. That's nice dear. Meanwhile, in the real world, peole can and do make mistakes. My article certainly debunks more myths than it propogates, and unlike many of the critics, my page will be corrected when I find better information.
We're not talking about applications, we're talking about users deleting files.
...which they do with applications, whether bash, OpenOfffice, Konqueror, or whatever else. The advantage over desktop environment specific trashcans is that libtrash works transparently to most applications and this can be easily supported by them all. You just have to make a tashcan icon and point it at the right directory.
And where do you see that these drafts have been approved ?
That's a true point, one I'm about to add to the page, but not what we were talking about. You said Red Hat was freedesktop.org, I provided soem evidence that it wasn't.
About point 2, considering how bad were the RH's KDE packages in the past, i'm almost sure it wasn't tested enough.
As someone who used those packages, I disagree.
About point 3 and 4, i just advise you to use as correct and accurate language as possible in your article, if you want credibility.
Fair enough, I can see your point and will add it to the page.
About OpenOffice you seem to ignore that it includes some GNOME interaction (not a lot for now though, granted)
Interesting. Could you be more specific?
However KOffice is very light and coherent when used within KDE, and i'm sure that for a lot of people such qualities are very important. This raising the question: on what basis did RedHat determine what is "best" Linux software ? KWord imports very well Word document as far as i know and have used it.
Does it export it? For most users, the ability to save to the file format that `everyone else' uses outweighs some sense of desktop interoperability. Likewise, being able to view web pages. Not everyone has the power to change other people's desktop habits or HTML coding skills.
That said, i know i'll be able to reconfigure everything, but most users will simply not do it.
I did. I don't know about other people, but I think if desktop users are unsatisfied most be aware they can chaneg and might do so. The best idea though is to keep them satisfied from the start.
There's plenty of stuff for (real) KDE users to be upset about.
Is there anything specific that's not covered in my article? I'd be happy to add it if you wish. As you can tell I don't think everything Red Hat changed has been beneficial, so if you have real criticisms and evidence to prove their case, post here or send me an email.
Your app doesn't intercept the unlink system call. it intercepts GNU `rm'. Most applications don't use GNU rm to delete files.
Re:I know you're kidding, but....
on
Undelete In Linux
·
· Score: 3, Informative
"[X] Standard software install system - LSB, Red Hat, Mandrake, Suse"
By listing four things here, you've gone right ahead and said that the software install system is _not_ standard.
I think what the poster meant was that Red Hat, Mandrake and Suse all conform to the Linux Standards Base. Which defines the standard packaging (software install and maintenance) system for Linux. Of course, you can pick your own front end.
"[X] Easy to use Windows filesharing - KDE, Samba"
Easy to use Windows filesharing is clicking on a button that says share files and seeing that folder show up in Network Neighborhood. It's not SWAT
Damn stright, I agree. But KDE does have this ability - look for ksambakonquiplugin (shit name I know) on apps.kde.com. Its too bad the distros don't ship with it turned on by default.
Too bad it's factually inaccurate in 100s of places
I've only had my own experiences and information from other people I've researched the topic with. If there's errors there (and there undoubtedly are) then I suppose you'll send me some email explaining exactly what's wrong, and providing supporting evidence. You do believe these opinions are correct, right?
Re:A users take on Red Hat 8 and KDE
on
Red Hat 8.0 Reviewed
·
· Score: 4, Informative
1- you should consider that freedesktop.org IS mostly RedHat. So what standards are you talking about ?
That's simply false. Red Hat host the site, but non Red Hat developers from KDE, Gnome and many other projects have contributed to many of its standards - eg, the Window Management specification that's supported by both environments and a increasingly large array of leightweight window managers.
2- about Qt+Xft, it's simple: they have shipped Beta Software. This is not good, and, unsurprisingly, they have done it for KDE, not GNOME. The same about VFolders. About this, RH's attitude looks very close to a (bad) fork.
Both the QT addons and the standard VFolder support stuff are a patch by Red Hat. Just like your distro doesn't ship a standard Linux kernel (most major distros don't). Yes, they'll be in future versions, but that doesn't mean that Red Hat 8 hasn't goen through extensive beta testing.
3- Mozilla uses GTK, you're apparently not aware of it.
GTK is not Gnome. Especially when its a backend for XUL.
4- About Mozilla & Konq again, you're making a small mistake. You say that Konqueror doesn't render properly web pages. This is false, for the simple reason that Konqueror can use KHTML or Mozilla, precisely, to render web pages.
Its not false, I'm assuming the default renderign engine of the software - which is a reasonable asummption to make as kmozilla isn't anywhere near as maintained as khtml is.
5- about changing default apps, you failed to notice that this will prevent interaction between apps when using KDE. Namely all those nice interactions between KMail and Konqueror and KOrganizer and Kaboodle, through KPart or DCOP, that most users point as the "added value", the "big plus" of KDE, are simply nonexistent if you use most RH default apps (simply because these default apps are not KDE apps).
Then choose a different app. Or better yet, standardize the interface. The bug isn't that peopel dare use applciation from other toolkits, the bug is that doing so often gives them a worse user experience because these application use nonstandardized mechanisms to interact with each other.
Also, don't fail to consider that _most_ users _will_use_default_apps_ that they are proposed
Good - Red Hat have taken some time selection good defaults and its nice that they showcase the best of what OSS has to offer.
because this is the attitude that years of microsoftian lobotomization has lead to.
No offence (I think your post is quite intelligent), but many people won't take you seriously if you use words like `Microsoftian'.
For all Linux newbies using RH, the mandatory conclusion if they try KDE instead of GNOME will be "KDE is crap".
By that same logic Gnome is crap, because they're missing out in Abiword, Gnumeric, and Galeon, in favor of non Gnome alternatives. Wait a sec. Abiword can't open, edit, and save MS Office documents reliably. Neither can KOffice. If a new user is given these defaults, anmd reasonably assumes they're the best the platform has to offer, the user may very well incorrectly l assume Linux is crap.
Thanks for your post. But I think what Red Hat's doing provides for a better desktop experience for end users. I love and use KDE, but no matter how hard the developers try, my platform is Linux - not KDE. I can and will choose the best apps avaliable to me regardless of toolkit. If that means those apps will miss out on some functionality because of that, the solution is to allow those non-KDE apps to integrate with KDE to the best of their ability - not to tell Red Hat that they should include a beta-quality office suite as a default because it uses the Right Toolkit.
Null coped pretty well with upgrading a 7.3 system with lots of Freshrpms updates to Null, the 8.0 beta. However, if you've got Gnome 2 already set up on your 7.3 box (most likely from the apt respository which stores 7.3 rpms), I'd remove it before you update, simply because your custom updates might seem newer than the 7.3 ones. You should probably do this before your install, but you can do it later if you wish.
The installer will however tell you about any conflicts as a result of your custom packages, and if worst comes to worst, you still won't loose any data - the Linux packaging system will use your existing configs (and create [config].rpmnew for any config files from new packages) or back yoru existing configs up as [config].rpmsave if the config file format has changed.
A users take on Red Hat 8 and KDE
on
Red Hat 8.0 Reviewed
·
· Score: 5, Informative
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.
Slashdot Mirror
Configs in /etc, services in /etc/init.d, documentation in /usr/share/doc, user bins in /usr/bin unless your apps is necessary to rescue to the system, sbin for yoru admin bins, /usr/lib for your libraries, /usr/share for everything else, RPM for your packages, stable releases of glibc and gcc for C library and compiler, etc.
Do you want to know more?
At the end of the document, you'll find an extra section offering a list of the ports used by commonly probed and attacked services. By blocking traffic to these ports at the firewall or other network perimeter protection devices, you add an extra layer of defense that helps protect you from configuration mistake
This seems like a really bad idea. Giving people a list of port they should block traffic to implies that they needn't properly lock down their rulesets properly, andd have accept as the default policy.
Chaos is freedom
GNU/Freedom!
I've reviewed a small amount (say, thirty) Linux / Unix / and (a couple of) Windows books for an Australian computer magazine (APC).
/etc/passwd file, then another fellow explaining NIS does a longer version of the same explanantion using a different analogy, rather than building on what the audience already knew. The change is style and analogies is often confusing for those new to the platform.
As a rule, if a book has more than two authors and is more than four hundred pages long, its quality is generally poor. This is because such titles - eg, most of the Unleashed series - take content from several diffferent authors, but don't maintain consistent style of build a solid learning path. One fellow explains the
I'm not saying all huge books are like this, but because of their nature they're more than likely to need a good editor to make all the disparate content a little more seamless, and because most are churned out like nobodies' business they rarely get this attention.
Other examples of why big books are often poorer includes the 1400 page Upgrading and Repairing PCs compared to the 700 page O'Reilly's PC Hardware in a Nutshell. Upgrading and Repairing loves including charts of the details about every PC product made by every manufacturer since the edition was published. This information is generally out of date, but th books publishers tell you you can fidn newer information onlien at the oublishers web site. Well, er, actually, I can find it at any web site. PC Hardware in a Nutshell is a lot mroe concise but contains most of the useful information. What it lacks in out-of-date charts it makes up in providing users with real-world experience and facts-supported opinion by the two authors - eg, they'll tell you that HP don't often release or support newer firmware for the CD drives they rebrand, so it might be best to avoid HP gear.
Another famously bad exampel of a large book is John Chirillo's Hack Attacks Encylopaedia. Its ~1500 pages (IIRC) of mainly unedited text files from outdated h4x0r tools, with a chapter by John at the start. It disgusts me that a) he has the nerve to call himself the authro of the title when he's clearly the edit, and a lazy one at that b) that this is a so called premium security title and is charged accordingly.
They're complimentary tools. Basically, yo ucan make your own apt-get server, or use various servers on the net to install third party packages that don't come with Red Hat, like lame, xine, mplayer, etc.
If you use Red Hat, you need FreshRPMS.
Most people have heard a lot on this topic, but mostly from people who haven't actually used 8.0 or Null. In fact, a good deal of the information that has been touted about the web is provably false. Some of the changes have had negative side effects that are in bugzilla, but, in my opinion as a KDE user, overall they've increased the usability of Linux desktops.
I've written a fairly comprehensive summary of what exactly Red Hat have modified about their KDE setup, and what I believe to be the rationale behind those changes. If you've read it before, it might eb worth a visit as I've made a few correctiosn and additiosn since then.
Cheers,
Mike
I can't see a purpose for that patch - I've read Red Hat's point of view and I still don't see how a naming conflict would realistically occur Yes
see a problem here, I've repeatedly said I see a problem. However I've also corrected you when you said the side effect was intentional. It clearly isn't, or they wouldn't be fixing it.
Only RHKDE had this problem. Note that RH never fixed this bug.
That seems odd when according to your link "The problem is khtml doesn't correctly interpret the tag and thus, flash animations which are not inside a pair work ok. Like
the one above." Doesn't look as if it was Red Hat's bug to fix...
So, we have a massive Redhat patch
to KDE written by GNOME developers
that serves no purpose except to
break things in KDE, but in your
mind this is somehow a "side effect".
No, the patch is not a side effect. I never said it was. The services breakage is a side effect. if it was the intended purpose of the patch, they wouldn't be trying to fix it.
But I think you know this and you're trolling me.
Thanks for the info re: QT. I haven't been able to get as much in depth information on the content of the patch as I'd like, and I've had to reply on heresay (much as I'm doing now unfortunely - do you have a link with mroe info?). I've heard this from a couple of people and I'll update the document accordingly,
People can and have have hinted that Red Hat broke Konqueror plugins (and caused every other bug that has or will appear in their KDE) on purpose to discredit KDE. Yes, these people are idiots, but others still believe them.
Konqueror plugins and Bluecurve are both fixed. I think they have have been for a fair while.
If an application other than rm or a file manager is calling unlink() then it probably has a good reason for doing it, and you don't want the files in a Trashcan anyway
Well, I might delete the old SXW of my document after I save the MS Word version to submit to an editor in OpenOffice.
The exceptions, like Mozilla, can easily be taken care of too.
If I want to read the Redhat party line responding to what they've done, I'll go find Owen's paper. Your bias for Redhat is pretty clear: covering for them by calling their intentional breakages a bug. LOL.
.desktop files for the purposes of breaking that system call. If they didn, they couldn't be reversing their behavior by filing a high priority bug report - that makes no sense.
You don't seem to understand the difference between Red Hat's changes and the resulting side effects. Red Hat didn't rename the
Stop trying to include me in the Myterious Anti KDE Sinister Organization. I always acknowledged the file renaming has no benefit I can see for end users, and I've criticised other Red Hat desktop decisions in the article too, such as the poor menu setup. Just because I agree with Red Hat on a few points doesn't mean I don't think independently: clearly I do, or I wouldn't be disagreeing with them on other points.
Oh well, your loss. The article's getting a few hits and I think you look bad by not providing evidence to support your claims of other breakages that you say aren't mentioned.
Huh? It's not a bug to Redhat - they did this unnecessary crap _intentionally_. With a HUGE patch. The RH GNOMErs (Havoc & Owen) defended what they did on kde lists.
I agree that it seems unnecessary (I can't udnerstand why they'd do it either) but I think you're missing the difference between the problem and a side effect. The side effect was unintentional - otherwise Red hat wouldn't have a highly priority bug concerning it, and wouldn't be working on a patch to fix it.
I'm correcting the document now to reflect the vfolder and system tray specs status as draft specifications.
Cheers for the correction, but you could be a bit more civil about it. As the document states, I'm approaching this from a users point of view, oddly enough, where Red Hat are aiming.
PS: The second URL you posted doesn't seem to work.
Further, you claim that every contributor is listed in "About App" boxes. I invite you to look over commit logs of any KDE application, and you'll see that there are dozens of contributors who aren't listed in the about box - bugfixers, proofreaders, people who fix up UI improvements. Heck, a casual look at kde-cvs archives will show that.
If this is the case (I doubt anybody would assume it was off the bat) then have you reported it to bugzilla?
And, BTW, I consider opinions based on inaccurate information meaningless.
That's nice dear. Meanwhile, in the real world, peole can and do make mistakes. My article certainly debunks more myths than it propogates, and unlike many of the critics, my page will be corrected when I find better information.
Mike
We're not talking about applications, we're talking about users deleting files.
...which they do with applications, whether bash, OpenOfffice, Konqueror, or whatever else. The advantage over desktop environment specific trashcans is that libtrash works transparently to most applications and this can be easily supported by them all. You just have to make a tashcan icon and point it at the right directory.
Too bad you chose to be rude than to inform me of this politely. Regardless, someone with more tact already has and I'm adding it to the page.
And where do you see that these drafts have been approved ?
That's a true point, one I'm about to add to the page, but not what we were talking about. You said Red Hat was freedesktop.org, I provided soem evidence that it wasn't.
About point 2, considering how bad were the RH's KDE packages in the past, i'm almost sure it wasn't tested enough.
As someone who used those packages, I disagree.
About point 3 and 4, i just advise you to use as correct and accurate language as possible in your article, if you want credibility.
Fair enough, I can see your point and will add it to the page.
About OpenOffice you seem to ignore that it includes some GNOME interaction (not a lot for now though, granted)
Interesting. Could you be more specific?
However KOffice is very light and coherent when used within KDE, and i'm sure that for a lot of people such qualities are very important. This raising the question: on what basis did RedHat determine what is "best" Linux software ? KWord imports very well Word document as far as i know and have used it.
Does it export it? For most users, the ability to save to the file format that `everyone else' uses outweighs some sense of desktop interoperability. Likewise, being able to view web pages. Not everyone has the power to change other people's desktop habits or HTML coding skills.
That said, i know i'll be able to reconfigure everything, but most users will simply not do it.
I did. I don't know about other people, but I think if desktop users are unsatisfied most be aware they can chaneg and might do so. The best idea though is to keep them satisfied from the start.
PS. I'm checking out Havoc's posts now.
There's plenty of stuff for (real) KDE users to be upset about.
Is there anything specific that's not covered in my article? I'd be happy to add it if you wish. As you can tell I don't think everything Red Hat changed has been beneficial, so if you have real criticisms and evidence to prove their case, post here or send me an email.
Your app doesn't intercept the unlink system call. it intercepts GNU `rm'. Most applications don't use GNU rm to delete files.
"[X] Standard software install system - LSB, Red Hat, Mandrake, Suse"
By listing four things here, you've gone right ahead and said that the software install system is _not_ standard.
I think what the poster meant was that Red Hat, Mandrake and Suse all conform to the Linux Standards Base. Which defines the standard packaging (software install and maintenance) system for Linux. Of course, you can pick your own front end.
"[X] Easy to use Windows filesharing - KDE, Samba"
Easy to use Windows filesharing is clicking on a button that says share files and seeing that folder show up in Network Neighborhood. It's not SWAT
Damn stright, I agree. But KDE does have this ability - look for ksambakonquiplugin (shit name I know) on apps.kde.com. Its too bad the distros don't ship with it turned on by default.
Too bad it's factually inaccurate in 100s of places
I've only had my own experiences and information from other people I've researched the topic with. If there's errors there (and there undoubtedly are) then I suppose you'll send me some email explaining exactly what's wrong, and providing supporting evidence. You do believe these opinions are correct, right?
1- you should consider that freedesktop.org IS mostly RedHat. So what standards are you talking about ?
That's simply false. Red Hat host the site, but non Red Hat developers from KDE, Gnome and many other projects have contributed to many of its standards - eg, the Window Management specification that's supported by both environments and a increasingly large array of leightweight window managers.
2- about Qt+Xft, it's simple: they have shipped Beta Software. This is not good, and, unsurprisingly, they have done it for KDE, not GNOME. The same about VFolders. About this, RH's attitude looks very close to a (bad) fork.
Both the QT addons and the standard VFolder support stuff are a patch by Red Hat. Just like your distro doesn't ship a standard Linux kernel (most major distros don't). Yes, they'll be in future versions, but that doesn't mean that Red Hat 8 hasn't goen through extensive beta testing.
3- Mozilla uses GTK, you're apparently not aware of it.
GTK is not Gnome. Especially when its a backend for XUL.
4- About Mozilla & Konq again, you're making a small mistake. You say that Konqueror doesn't render properly web pages. This is false, for the simple reason that Konqueror can use KHTML or Mozilla, precisely, to render web pages.
Its not false, I'm assuming the default renderign engine of the software - which is a reasonable asummption to make as kmozilla isn't anywhere near as maintained as khtml is.
5- about changing default apps, you failed to notice that this will prevent interaction between apps when using KDE. Namely all those nice interactions between KMail and Konqueror and KOrganizer and Kaboodle, through KPart or DCOP, that most users point as the "added value", the "big plus" of KDE, are simply nonexistent if you use most RH default apps (simply because these default apps are not KDE apps).
Then choose a different app. Or better yet, standardize the interface. The bug isn't that peopel dare use applciation from other toolkits, the bug is that doing so often gives them a worse user experience because these application use nonstandardized mechanisms to interact with each other.
Also, don't fail to consider that _most_ users _will_use_default_apps_ that they are proposed
Good - Red Hat have taken some time selection good defaults and its nice that they showcase the best of what OSS has to offer.
because this is the attitude that years of microsoftian lobotomization has lead to.
No offence (I think your post is quite intelligent), but many people won't take you seriously if you use words like `Microsoftian'.
For all Linux newbies using RH, the mandatory conclusion if they try KDE instead of GNOME will be "KDE is crap".
By that same logic Gnome is crap, because they're missing out in Abiword, Gnumeric, and Galeon, in favor of non Gnome alternatives. Wait a sec. Abiword can't open, edit, and save MS Office documents reliably. Neither can KOffice. If a new user is given these defaults, anmd reasonably assumes they're the best the platform has to offer, the user may very well incorrectly l assume Linux is crap.
Thanks for your post. But I think what Red Hat's doing provides for a better desktop experience for end users. I love and use KDE, but no matter how hard the developers try, my platform is Linux - not KDE. I can and will choose the best apps avaliable to me regardless of toolkit. If that means those apps will miss out on some functionality because of that, the solution is to allow those non-KDE apps to integrate with KDE to the best of their ability - not to tell Red Hat that they should include a beta-quality office suite as a default because it uses the Right Toolkit.
The same goes for Gnome too.
Null coped pretty well with upgrading a 7.3 system with lots of Freshrpms updates to Null, the 8.0 beta. However, if you've got Gnome 2 already set up on your 7.3 box (most likely from the apt respository which stores 7.3 rpms), I'd remove it before you update, simply because your custom updates might seem newer than the 7.3 ones. You should probably do this before your install, but you can do it later if you wish.
The installer will however tell you about any conflicts as a result of your custom packages, and if worst comes to worst, you still won't loose any data - the Linux packaging system will use your existing configs (and create [config].rpmnew for any config files from new packages) or back yoru existing configs up as [config].rpmsave if the config file format has changed.
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.