If you'd like access to their well tested, bugfixed, signed bugfixes and updates on a high priority, high availability basis, then you can pay for such a service
True - but it's not even that. We will, of course, continue to make updates available on updates.redhat.com and announce them on redhat-announce-list@redhat.com and, if necessary, bugtraq and friends.
We're not stopping to give away stuff - we're just introducing some additional services for pay.
(No details before the official announcement;) ).
and like all previous versions of Red Hat, you'll get to have rsh, rexec and all those other worthless security problem inetd daemons enabled by default.
This isn't true at all. Red Hat Linux 7 does NOT enable any of them by default. 6.2 didn't enable them all by default.
Now that we can ship a secure replacement, we would have no reason whatsoever to enable them by default on fresh installations, and we aren't doing it.
wu-ftpd is still there if I'm not mistaken
Yes it is, and it's the right choice. Yes, it has had some security problems. Name an alternative that didn't have them. Remember the early days of ProFTPD (the only viable alternative IMO)? Remember the fact that the most recent root exploit related to an sprintf without a %s actually affected BOTH wu-ftpd and ProFTPD?
Right now, I'd call them about on par, and there's no reason to move users to a totally different configuration file layout if it doesn't get them any major benefits.
Also, last time I checked (admittedly I haven't checked the latest couple of releases), ProFTPD didn't support virtual hosts with different password files for each of them. Same for e-mail notifications to the admin for uploads by anonymous and a couple of other features.
Lastly, there's kwuftpd (included in kdeadmin as of KDE 2.0) which provides an easy way to configure wu-ftpd. I haven't seen a similar tool for ProFTPD.
Sendmail is still the default MTA
Yes. Some people rely on its features.
Some of the alternatives (especially postfix, IMO) are great, but not sufficient for everyone.
shouldn't [OpenSSH] obsolete rshd/rexecd and to a lesser extent telnetd?
No way.
Interoperability is still important, and a lot of other OSes (even other Linux distributions) still can't access ssh servers.
We aren't enabling rshd and friends by default, but it's important to keep them in - many setups still depend on them.
For www, it's ok by now - all the important browsers (including "telnet server 80";) ) support it. (https just requires a policy change in the organizations issuing certificates).
However, the command for name-based virtual hosting in FTP is not even in an RFC yet (it is included in the latest drafts for a new RFC though, along with MLST).
However, even when that RFC is passed, it will take a while until it is implemented in servers and clients (and a change IS required on both sides).
Patches for wu-ftp and the netkit ftp client exist (sample implementations...) - but I can't see a certain large company that refuses to open-source any of their products implementing something just because it's an RFC or because it would make sense... And while that company controls one of the most commonly used ftp clients...:(
While this is definitely true, just increasing the fuel price doesn't cut it.
The government in Germany recently increased fuel taxes to the point that fuel costs 2 DM per liter (slightly less than $4/gal).
The effect is that everyone is complaining about the tremendous fuel prices, while nobody can do anything about it.
Even in many of the bigger cities, there are no facilities to refill alternate fuel-cars.
Public transportation is not an alternative in many locations because it's even more expensive and not even available to a real extent in some of the more rural areas.
People who could afford getting a new car that just uses up less traditional fuel are not the ones hit hardest.
People who are still driving a 15 years-old car that obviously needs more fuel than recent technology simply because they can't afford buying a new car are in real trouble.
A more sane approach, IMO, would be to
Increase fuel prices, the way they did here
Use the extra money to fund moving to alternate technologies. Give major tax reductions to people who buy zero-emission cars or combustion cars that were designed to use little fuel.
Give minor tax incentives to companies building the facilities to recharge zero-emission cars for a very short period of time.
Since the demand will obviously grow (because of #2), they'll know they need to do it sooner or later. If they get incentives only if they start in the next 6 months or so, they'll do it sooner.
Inform the general public on WHY it's done. Many people aren't aware enough of the effects of emissions and the fossil fuel shortage that will inevitably come if nothing changes. They need to know it's not Yet Another Tax Rise (Another thing the German government did very badly - no information, and using the money exclusively to repay debts. To the average person, this MUST look like just another way to exploit the people.)
You've just mentioned a couple of reasons why OSS is the future, you just misiterpreted them...
When someone interrupts that system and says, "No. You can't have this until you give us X Y and Z", then the creative process will halt.
This is true for some situations in proprietary software. In open source, the party making this demand will get screwed. If they're patching a GPL project or using GPL or QPL libraries, they're violating the licenses - if they aren't, someone else will do their job.
tha majority of active OSS projects in the world, right now, are being housed on SourceForge. SourceForge is owned by a company that has yet to turn a profit and is currently teetering on the edge of bankruptcy.
First of all, VA's situation is not quite that bad. Second, SourceForge is NOT a single point of failure.
If VA goes bankrupt, someone else (e.g. Red Hat) will take over SourceForge, or at the very least offer a very similar service. (Promised, even if I have to start it myself.)
Since all the stuff is open source, I can legally grab all the stuff from SourceForge and put it in CVS trees elsewhere.
If some accident killed Linus and all his machines, it would of course be a very bad thing - but Linux would go on, because there are many more copies of its source code.
If, on the other hand, some accident destroyed all Microsoft offices, good-bye Windows - nobody has the source, so nobody could continue developing it [and I don't think it's possible to rewrite all its bugs from scratch;) ].
No one will work for free, if they know the guy next to them is doing the same work for pay.
Untrue. Take a look at any of the mailing lists on a bigger open source project (e.g. linux-kernel, kde-devel,...) - you'll see a lot of people who are paid for their work and a lot of people who aren't working happily together.
Open Source does not eliminate the need for software developers. As you've said yourself, Open Source usually does not have deadlines, sales figures or pressure.
That's where companies come in - they have deadlines, and need their favorite projects to be at a certain point at a certain time, so they hire someone to make sure it happens.
I think right now, we're at a point where Linux would go on even if all hobbyists stopped working on it -- as well as if all Linux companies suddenly went bankrupt.
Both of these things would slow down, but not stop, development.
Show me this type of safety in any other development model...
The only real differences for the programmers are that they can get help from outside (didn't you always want that un-tracable bug fixed by someone else? Happens a couple of times here...) and that they can legally link to GPLed and QPLed code - two things that make life a lot easier.
Aside from them, I don't think there will be many changes for developers.
Anyone stating they'll instantly get fired is spreading FUD. Companies will always need developers to make sure their programs develop in the "right" direction, and using those that have been on the project forever is plainly logical; anyone from outside would need quite some time to get familiar with the code.
Creationists can always argue that anyone who created life in one place probably had a reason to create it in other places, as well (experiment, fallback solution,..., reasons could be endless).
Similarily, the absence of life on other planets just means the beginning conditions weren't right there. (And there are so many planets that there won't ever be a point at which we can claim there's absolutely certainly no other life). I don't think anyone would claim a plain rock would eventually evolve into life.
Re:where are RPMs for Mandrake?
on
KDE Strikes Back
·
· Score: 2
As far as Red Hat is concerned:
Because we didn't finish building the packages in time.
We're currently building the packages, and they'll appear on ftp either later today or early tomorrow.
Gnome and KDE could really complement each other if they would work together a little more.
This is true and I'd like to see it happen, but there are some huge technical problems that would need solving (KParts and bonobo have little in common except for serving the same purpose) and they're all but simple.
KDE seems more bent on keeping everything dependent on qt while most of the gnome stuff is trying to be completely [...] tk independent
That's partially because of the internals - gtk+ is plain C, so it doesn't support inheritance and things. (And in the limited way it supports inheritance, gnome is as dependent on gtk+ as kde is on qt; gnome_entry_new makes use of gtk_entry_new).
Qt/KDE is C++, so you just use inheritance and automatically depend on the widgets you've used (code reuse).
since I am now posting in the 'company' of a Red Hat employee will probably end up with a lawsuit on my hands to boot
No way, unless you're inventing this to harm our reputation (which I don't think, shit happens).
Sorry for the trouble with ApplixWare - this is probably too long ago to track down and see what caused it, so I'll take it for a typical "shit happens" thing and make sure it gets fixed at least now.
For the software, all I can say is that I can't reproduce it and neither can our other customers - if you send me some details of the hardware (and the version of Red Hat Linux you were using), I'll check what's causing the problems. (We have upgraded some drivers; it may be a problem with one of them).
These problems should go into bugzilla, where actual developers can read them and take care of them. (Unless you have a support contract, the support people will help you with installation; some of them aren't qualified to fix bugs.)
Make crappy software
We're trying not to do that - and I'd really like to know if any of your problems are still occuring with the 7.0 beta version.
blame the user when it doesn't work
I guess every software company is a bit guilty about this one - if something works perfectly for you, then someone tells you it doesn't work, what would you blame first, if you don't know how much the other person knows about the piece of software?
screw the user if you can make a buck
If that was our intention, we'd be making proprietary software.
This combined with some other really bad experiences with Red Hat (both the company and the software)
Such as? We aren't perfect, but we're trying.;)
Red Hat will not be happy until it owns the Linux market. Not just in the sense of most market share, but they want all market share.
Entirely untrue.
We'd be stupid if we wanted that, even from a pure business point of view (hey, all those people being paid by Mandrake, SuSE, Caldera and all are FREE developers for us!).
Similarily, why would we GPL all our developments if we wanted to shut everyone else out?
they would have been better off to try to create some great Windows rip off. Then they could make it proprietary.
We could make our installer proprietary. Do we?
We could have made rpm proprietary. Do we?
The day Red Hat starts making proprietary software without a good reason (such as having to do NDAs to be able to get a solution at all, which is bad, but the lesser of 2 evils with the alternative being forcing users on Windoze), I'm out of here, and so are a number of other developers. It won't happen.
Two wrongs don't make a right - and this is two wrongs. We don't want KDE dead and we have no reason to take revenge on KDE.
Red Hat spent a lot of money in the early days rolling out a proprietary CDE release that was supposed to be their cash cow.
Sorry, but this isn't true. Proprietary software is not and has never been a major part in Red Hat's business plans.
At that time, there was no free and good user interface available, CDE was a kind of standard, so it got included, because a proprietary solution seemed to be better than no solution at all. We're glad that this is no longer necessary.
They had it all positioned, along with ApplixWare, etc
If we bought ApplixWare, somebody forgot to tell me.
to take over the Linux market
If that was our intention, why would we GPL our installers and permit distributions to just copy Red Hat Linux and add/remove/change some stuff?
Can't be about acceptance - SuSE don't GPL their installer and yet they're widely accepted.
If you had had a look at Red Hat Linux in the last couple of years, you would have noticed that we aren't including any proprietary software with the exception of Netscape (because it's important and there's no good free replacement, though Konqueror and Mozilla are getting there).
We don't want proprietary software.
Along came KDE and Lesstif, which drew all the energy away from the closed-source stuff that Red Hat had and all the shrinkwrapped boxes printed up for at great cost. Red Hat ended up taking a bath as result, out of reaction they hyped up Gnome as a counter-attack.
Entirely untrue. Red Hat chose to support Gnome because of Qt (1.x)'s restrictive license. The Qt 2.x license is not a problem, the old license was.
By the time Qt 2.0 was released and the license problem was fixed, Gnome was already usable and at a point where simply dumping it wouldn't have made sense. (Yes, I personally still prefer KDE, but Gnome isn't bad, and it would be a pity to see it go.).
Next time, please take the time to check the facts before posting.
Why does Red Hat insist on dumping Kde libs and bins into/usr instead of/opt/kde like everyone else?
Becuase that's what the filesystem standards say.
/opt is for local add-ons.
The latest FHS standard has loosened that restriction a bit, but still says upgrades may not overwrite anything in/opt, so putting KDE to/opt/something if it is included in a distribution while keeping updates working is plain wrong.
My personal preference would be/usr/kde (just like/usr/X11R6), but let's not add yet another location.
it seems from Miguel's recent white paper "Let's Make Unix Not Suck" that he wants Gnome to be the one and only desktop system for Linux, enforced at a deeper level, even by policy embedded in the kernel.
Miguel is not Linux and Miguel is not Gnome.
This sort of stuff can't and won't happen.
Even if the kernel or X guys should play some Microsoftish tricks in the X server to prevent other stuff from running (purely hypothetical, this won't happen), someone would just fork them and maintain a clean version.
I don't think all of Miguel's ideas are bad (though I don't think any of this stuff should go into the kernel, that's part of what causes the crashes in MS OSes) - we could probably use some sort of improved component model, but only if it is generally useful and not specific to either Gnome or KDE.
I don't think Red Hat will ever be happy until Qt and the whole KDE project is dead
Not quite true.
While we're not exactly the biggest supporters of KDE and Qt, we do contribute to them, and we're including them.
There's no point in the whole KDE/GNOME flamewars.
Both have their good and bad points and nice applications (I guess most people who are not fanatics of either one are using a couple of GNOME applications from KDE or vice versa) - so why not give users the choice?
This includes giving C++ programmers the choice to have a sane interface to gtk+ (such as Inti). It's not an attempt to kill of Qt.
(FYI: Yes, I have programmed in both, prefer Qt, and think gtk+ needs a more Qt'ish API for people who like C++.)
Oops, you caught us...:) Yes, the plans are to get a user account with karma > whatever the code currently supports, thereby causing a buffer overrun and taking over Slashdot, and thereby WORLD DOMINATION!
Oops, now I told too much.
Guess I'd better do something to make at least some people believe we're releasing because we're actually improving something...
400th post!
I'm currently pouring hot grits down my pants and looking at a Natalie Portman poster!
Your favorite Linux distribution sucks, all real people do "cat >/dev/hda"!
with each major kernel release, a relatively major reconfig was required of certain packages to get optimal performance
We're ready for 2.4 in these terms. Everything in the distribution has been compiled with 2.4 kernel includes, and all packages have been updated (we're even including iptables, the ipchains replacement for 2.4 kernels).
why not include the beta kernel with a product not expected to ship for another few months?
We don't expect to see a 100% stable 2.4.x release before going gold on 7.0. Therefore, we need beta testers to check how well our updates to the 2.2 kernels work with all sorts of hardware. That's why we're including the kernel that's closer to the default kernel for 7.0 final.
If you take a look at the kernel source RPM, you'll see we've added a number of patches, such as USB support - we don't want to include them in 7.0 without having had any public beta testing on that kernel.
Why rush 7.0
I'd rather delay 7.0 by a few more weeks to wait for some projects, but it's out of the question for the business side.
Not many would run beta in a mission critical situation
Right - but the beta is supposed to be as close as possible to the final, and the final will have 2.2.17 by default (with 2.4.0 included on the CD for those who want to play). We can't go "2.2.17 is tested well enough, we'll just throw it in if 2.4.0test9pre7 isn't stable enough at release time" because we don't want to ship untested kernel patches. That would be suicide... (Then again, maybe not, seems like Microsoft has done it all the time:>)
Slashdot Mirror
If you'd like access to their well tested, bugfixed, signed bugfixes and updates on a high priority, high availability basis, then you can pay for such a service
;) ).
True - but it's not even that. We will, of course, continue to make updates available on updates.redhat.com and announce them on redhat-announce-list@redhat.com and, if necessary, bugtraq and friends.
We're not stopping to give away stuff - we're just introducing some additional services for pay.
(No details before the official announcement
and like all previous versions of Red Hat, you'll get to have rsh, rexec and all those other worthless security problem inetd daemons enabled by default.
This isn't true at all. Red Hat Linux 7 does NOT enable any of them by default. 6.2 didn't enable them all by default.
Now that we can ship a secure replacement, we would have no reason whatsoever to enable them by default on fresh installations, and we aren't doing it.
wu-ftpd is still there if I'm not mistaken
Yes it is, and it's the right choice. Yes, it has had some security problems. Name an alternative that didn't have them. Remember the early days of ProFTPD (the only viable alternative IMO)? Remember the fact that the most recent root exploit related to an sprintf without a %s actually affected BOTH wu-ftpd and ProFTPD?
Right now, I'd call them about on par, and there's no reason to move users to a totally different configuration file layout if it doesn't get them any major benefits.
Also, last time I checked (admittedly I haven't checked the latest couple of releases), ProFTPD didn't support virtual hosts with different password files for each of them. Same for e-mail notifications to the admin for uploads by anonymous and a couple of other features.
Lastly, there's kwuftpd (included in kdeadmin as of KDE 2.0) which provides an easy way to configure wu-ftpd. I haven't seen a similar tool for ProFTPD.
Sendmail is still the default MTA
Yes. Some people rely on its features.
Some of the alternatives (especially postfix, IMO) are great, but not sufficient for everyone.
shouldn't [OpenSSH] obsolete rshd/rexecd and to a lesser extent telnetd?
No way.
Interoperability is still important, and a lot of other OSes (even other Linux distributions) still can't access ssh servers.
We aren't enabling rshd and friends by default, but it's important to keep them in - many setups still depend on them.
For www, it's ok by now - all the important browsers (including "telnet server 80" ;) ) support it. (https just requires a policy change in the organizations issuing certificates).
:(
However, the command for name-based virtual hosting in FTP is not even in an RFC yet (it is included in the latest drafts for a new RFC though, along with MLST).
However, even when that RFC is passed, it will take a while until it is implemented in servers and clients (and a change IS required on both sides).
Patches for wu-ftp and the netkit ftp client exist (sample implementations...) - but I can't see a certain large company that refuses to open-source any of their products implementing something just because it's an RFC or because it would make sense... And while that company controls one of the most commonly used ftp clients...
Does the patent office have any e-mail address where we can claim preusage?
I really really doubt they were the first.
The government in Germany recently increased fuel taxes to the point that fuel costs 2 DM per liter (slightly less than $4/gal).
The effect is that everyone is complaining about the tremendous fuel prices, while nobody can do anything about it.
Even in many of the bigger cities, there are no facilities to refill alternate fuel-cars.
Public transportation is not an alternative in many locations because it's even more expensive and not even available to a real extent in some of the more rural areas.
People who could afford getting a new car that just uses up less traditional fuel are not the ones hit hardest.
People who are still driving a 15 years-old car that obviously needs more fuel than recent technology simply because they can't afford buying a new car are in real trouble.
A more sane approach, IMO, would be to
Since the demand will obviously grow (because of #2), they'll know they need to do it sooner or later. If they get incentives only if they start in the next 6 months or so, they'll do it sooner.
You've just mentioned a couple of reasons why OSS is the future, you just misiterpreted them...
;) ].
...) - you'll see a lot of people who are paid for their work and a lot of people who aren't working happily together.
When someone interrupts that system and says, "No. You can't have this until you give us X Y and Z", then the creative process will halt.
This is true for some situations in proprietary software. In open source, the party making this demand will get screwed. If they're patching a GPL project or using GPL or QPL libraries, they're violating the licenses - if they aren't, someone else will do their job.
tha majority of active OSS projects in the world, right now, are being housed on SourceForge. SourceForge is owned by a company that has yet to turn a profit and is currently teetering on the edge of bankruptcy.
First of all, VA's situation is not quite that bad. Second, SourceForge is NOT a single point of failure.
If VA goes bankrupt, someone else (e.g. Red Hat) will take over SourceForge, or at the very least offer a very similar service. (Promised, even if I have to start it myself.)
Since all the stuff is open source, I can legally grab all the stuff from SourceForge and put it in CVS trees elsewhere.
If some accident killed Linus and all his machines, it would of course be a very bad thing - but Linux would go on, because there are many more copies of its source code.
If, on the other hand, some accident destroyed all Microsoft offices, good-bye Windows - nobody has the source, so nobody could continue developing it [and I don't think it's possible to rewrite all its bugs from scratch
No one will work for free, if they know the guy next to them is doing the same work for pay.
Untrue. Take a look at any of the mailing lists on a bigger open source project (e.g. linux-kernel, kde-devel,
Open Source does not eliminate the need for software developers. As you've said yourself, Open Source usually does not have deadlines, sales figures or pressure.
That's where companies come in - they have deadlines, and need their favorite projects to be at a certain point at a certain time, so they hire someone to make sure it happens.
I think right now, we're at a point where Linux would go on even if all hobbyists stopped working on it -- as well as if all Linux companies suddenly went bankrupt.
Both of these things would slow down, but not stop, development.
Show me this type of safety in any other development model...
The only real differences for the programmers are that they can get help from outside (didn't you always want that un-tracable bug fixed by someone else? Happens a couple of times here...) and that they can legally link to GPLed and QPLed code - two things that make life a lot easier.
Aside from them, I don't think there will be many changes for developers.
Anyone stating they'll instantly get fired is spreading FUD. Companies will always need developers to make sure their programs develop in the "right" direction, and using those that have been on the project forever is plainly logical; anyone from outside would need quite some time to get familiar with the code.
www.dvdcca.org is running Apache/1.3.3 (Unix) PHP/3.0.5
So these guys are using a pirated web server and scripting language... We should sue them over this.
Creationists can always argue that anyone who created life in one place probably had a reason to create it in other places, as well (experiment, fallback solution, ..., reasons could be endless).
Similarily, the absence of life on other planets just means the beginning conditions weren't right there. (And there are so many planets that there won't ever be a point at which we can claim there's absolutely certainly no other life). I don't think anyone would claim a plain rock would eventually evolve into life.
As far as Red Hat is concerned:
Because we didn't finish building the packages in time.
We're currently building the packages, and they'll appear on ftp either later today or early tomorrow.
A QString is unicode capable, a STL string isn't.
Besides, Qt was started before many OSes had a
useful STL implementation.
Now M$ can't blame broken hardware for the bluescreens. :>
Gnome and KDE could really complement each other if they would work together a little more.
This is true and I'd like to see it happen, but there are some huge technical problems that would need solving (KParts and bonobo have little in common except for serving the same purpose) and they're all but simple.
KDE seems more bent on keeping everything dependent on qt while most of the gnome stuff is trying to be completely [...] tk independent
That's partially because of the internals - gtk+ is plain C, so it doesn't support inheritance and things. (And in the limited way it supports inheritance, gnome is as dependent on gtk+ as kde is on qt; gnome_entry_new makes use of gtk_entry_new).
Qt/KDE is C++, so you just use inheritance and automatically depend on the widgets you've used (code reuse).
since I am now posting in the 'company' of a Red Hat employee will probably end up with a lawsuit on my hands to boot
No way, unless you're inventing this to harm our reputation (which I don't think, shit happens).
Sorry for the trouble with ApplixWare - this is probably too long ago to track down and see what caused it, so I'll take it for a typical "shit happens" thing and make sure it gets fixed at least now.
For the software, all I can say is that I can't reproduce it and neither can our other customers - if you send me some details of the hardware (and the version of Red Hat Linux you were using), I'll check what's causing the problems. (We have upgraded some drivers; it may be a problem with one of them).
These problems should go into bugzilla, where actual developers can read them and take care of them. (Unless you have a support contract, the support people will help you with installation; some of them aren't qualified to fix bugs.)
Make crappy software
We're trying not to do that - and I'd really like to know if any of your problems are still occuring with the 7.0 beta version.
blame the user when it doesn't work
I guess every software company is a bit guilty about this one - if something works perfectly for you, then someone tells you it doesn't work, what would you blame first, if you don't know how much the other person knows about the piece of software?
screw the user if you can make a buck
If that was our intention, we'd be making proprietary software.
and sling mud when you have no facts
That's Microsoft's job, not ours.
This combined with some other really bad experiences with Red Hat (both the company and the software)
;)
Such as? We aren't perfect, but we're trying.
Red Hat will not be happy until it owns the Linux market. Not just in the sense of most market share, but they want all market share.
Entirely untrue.
We'd be stupid if we wanted that, even from a pure business point of view (hey, all those people being paid by Mandrake, SuSE, Caldera and all are FREE developers for us!).
Similarily, why would we GPL all our developments if we wanted to shut everyone else out?
they would have been better off to try to create some great Windows rip off. Then they could make it proprietary.
We could make our installer proprietary. Do we?
We could have made rpm proprietary. Do we?
The day Red Hat starts making proprietary software without a good reason (such as having to do NDAs to be able to get a solution at all, which is bad, but the lesser of 2 evils with the alternative being forcing users on Windoze), I'm out of here, and so are a number of other developers. It won't happen.
Red Hat wants KDE dead for reasons of revenge.
Two wrongs don't make a right - and this is two wrongs. We don't want KDE dead and we have no reason to take revenge on KDE.
Red Hat spent a lot of money in the early days rolling out a proprietary CDE release that was supposed to be their cash cow.
Sorry, but this isn't true. Proprietary software is not and has never been a major part in Red Hat's business plans.
At that time, there was no free and good user interface available, CDE was a kind of standard, so it got included, because a proprietary solution seemed to be better than no solution at all. We're glad that this is no longer necessary.
They had it all positioned, along with ApplixWare, etc
If we bought ApplixWare, somebody forgot to tell me.
to take over the Linux market
If that was our intention, why would we GPL our installers and permit distributions to just copy Red Hat Linux and add/remove/change some stuff?
Can't be about acceptance - SuSE don't GPL their installer and yet they're widely accepted.
If you had had a look at Red Hat Linux in the last couple of years, you would have noticed that we aren't including any proprietary software with the exception of Netscape (because it's important and there's no good free replacement, though Konqueror and Mozilla are getting there).
We don't want proprietary software.
Along came KDE and Lesstif, which drew all the energy away from the closed-source stuff that Red Hat had and all the shrinkwrapped boxes printed up for at great cost. Red Hat ended up taking a bath as result, out of reaction they hyped up Gnome as a counter-attack.
Entirely untrue. Red Hat chose to support Gnome because of Qt (1.x)'s restrictive license. The Qt 2.x license is not a problem, the old license was.
By the time Qt 2.0 was released and the license problem was fixed, Gnome was already usable and at a point where simply dumping it wouldn't have made sense. (Yes, I personally still prefer KDE, but Gnome isn't bad, and it would be a pity to see it go.).
Next time, please take the time to check the facts before posting.
The installer actually installs LILO and writes the configuration file to /etc/lilo.conf unless you turn it off.
As for the LS120 drive,
http://bugzilla.redhat.com/bugzilla/ is the right place to talk about this - we can't fix problems we aren't aware of.
There were a couple of problems in the 6.1 and 6.2 installers; most of them should be fixed in the 7.0 beta.
Ask Havoc (hp at redhat dot com) - I wasn't involved in this, so I don't know.
Why does Red Hat insist on dumping Kde libs and bins into /usr instead of /opt/kde like everyone else?
/opt, so putting KDE to /opt/something if it is included in a distribution while keeping updates working is plain wrong.
/usr/kde (just like /usr/X11R6), but let's not add yet another location.
Becuase that's what the filesystem standards say.
/opt is for local add-ons.
The latest FHS standard has loosened that restriction a bit, but still says upgrades may not overwrite anything in
My personal preference would be
it seems from Miguel's recent white paper "Let's Make Unix Not Suck" that he wants Gnome to be the one and only desktop system for Linux, enforced at a deeper level, even by policy embedded in the kernel.
Miguel is not Linux and Miguel is not Gnome.
This sort of stuff can't and won't happen.
Even if the kernel or X guys should play some Microsoftish tricks in the X server to prevent other stuff from running (purely hypothetical, this won't happen), someone would just fork them and maintain a clean version.
I don't think all of Miguel's ideas are bad (though I don't think any of this stuff should go into the kernel, that's part of what causes the crashes in MS OSes) - we could probably use some sort of improved component model, but only if it is generally useful and not specific to either Gnome or KDE.
I don't think Red Hat will ever be happy until Qt and the whole KDE project is dead
Not quite true.
While we're not exactly the biggest supporters of KDE and Qt, we do contribute to them, and we're including them.
There's no point in the whole KDE/GNOME flamewars.
Both have their good and bad points and nice applications (I guess most people who are not fanatics of either one are using a couple of GNOME applications from KDE or vice versa) - so why not give users the choice?
This includes giving C++ programmers the choice to have a sane interface to gtk+ (such as Inti). It's not an attempt to kill of Qt.
(FYI: Yes, I have programmed in both, prefer Qt, and think gtk+ needs a more Qt'ish API for people who like C++.)
Officially, they claim it isn't, but they probably forgot to remove it from their ftp servers, it's still here.
AFAIK it's about avoiding single points of failure - if one thing breaks/crashes, something else takes over.
Kind of like a cluster in a box.
Oops, you caught us... :)
;)
Yes, the plans are to get a user account with karma > whatever the code currently supports, thereby causing a buffer overrun and taking over Slashdot, and thereby WORLD DOMINATION!
Oops, now I told too much.
Guess I'd better do something to make at least some people believe we're releasing because we're actually improving something...
400th post!
I'm currently pouring hot grits down my pants and looking at a Natalie Portman poster!
Your favorite Linux distribution sucks, all real people do "cat >/dev/hda"!
Hope this qualifies as Troll, -1.
Obviously, I'm not after Karma.
Both are right actually - the main dist consists of the two CDs, but for a normal installation, the first will suffice.
with each major kernel release, a relatively major reconfig was required of certain packages to get optimal performance
:>)
We're ready for 2.4 in these terms.
Everything in the distribution has been compiled with 2.4 kernel includes, and all packages have been updated (we're even including iptables, the ipchains replacement for 2.4 kernels).
why not include the beta kernel with a product not expected to ship for another few months?
We don't expect to see a 100% stable 2.4.x release before going gold on 7.0. Therefore, we need beta testers to check how well our updates to the 2.2 kernels work with all sorts of hardware. That's why we're including the kernel that's closer to the default kernel for 7.0 final.
If you take a look at the kernel source RPM, you'll see we've added a number of patches, such as USB support - we don't want to include them in 7.0 without having had any public beta testing on that kernel.
Why rush 7.0
I'd rather delay 7.0 by a few more weeks to wait for some projects, but it's out of the question for the business side.
Not many would run beta in a mission critical situation
Right - but the beta is supposed to be as close as possible to the final, and the final will have 2.2.17 by default (with 2.4.0 included on the CD for those who want to play).
We can't go "2.2.17 is tested well enough, we'll just throw it in if 2.4.0test9pre7 isn't stable enough at release time" because we don't want to ship untested kernel patches. That would be suicide... (Then again, maybe not, seems like Microsoft has done it all the time