Since nobody can fix problems without being aware of them, please make sure you report those problems rather than just complaining on your favorite message board/mailing list/IRC channel/...
Qt depends on Mesa if you want the OpenGL functionality, and many people need that (at least according to the number of "bug" reports we got when we shipped Qt without OpenGL support).
Upgrading depends on what you've used before.
If you've used a previous 2.0 beta, you want to update because of tons of bugfixes.
If you've used 1.x, check the KDE-2 launchpad.
As for switching from Gnome to KDE 2.x or vice versa, my recommendation has always been to try out both and check which you like better.
Since you can run KDE applications inside gnome and vice versa, you may like Konqueror and a couple of other new tools even if you decide not to switch.
Yes, they're going straight to/usr - that's because I don't see a need to keep KDE 1.x around now that 2.0 is stable.
It's an update, and should be handled as such. (I'll be putting together a kde1-compat package to keep old KDE 1.x apps running in a while, though updating to KDE 2.x versions is of course preferred).
Second, if we decided to drop sparc support commercially, we'd also try to get a community effort on keeping the port alive going.
Third, this has nothing whatsoever to do with releasing a closed source version. Doing that would do harm to the entire community.
Dropping a rarely used port would hurt a part of the community, but actually benefit others (all the engineering time we're currently putting into fixing up sparc would go to other projects).
The article's subject should be "Red Hat Linux 7.0 possibly won't be released for sparc".
The sparc machines are still part of our build system, and we won't just drop it off.
If we ever decide to discontinue sparc support commercially, the sparc port will be turned into a community effort.
Re:Nobody needs basic any more
on
KBasic
·
· Score: 2
The only people using basic are
a) Those who write or maintain Windows gui/components/ASP
They're all potential users of real OSes who just haven't used them yet.;)
Actually I know some people who match this description and who would move to a real OS if they didn't have to rewrite all their stuff in a totally different language.
Rewriting 20000 lines of BASIC code in C, C++ or Java is not exactly a fast or interesting job.
b) Those without the balls to learn Java
While there's no really working free JDK (kaffe still isn't there, probably some time in the future...), there are other reasons not to do Java.
If they wanted to do something useful, they would write a Java IDE
Plus a free JVM and JDK... Without these, a Java IDE is pretty much useless.
It seems all KDE wants to do is make linux into a Windows clone
No way. KDE doesn't have a bluescreen module, a "send-everything-to-microsoft"-feature (aka windowsupdate.microsoft.com), useless drive letters,...
KDE is just trying to make the transition from a broken OS to a real OS as easy as possible, which is a good thing.
Basic is definitely not the greatest programming languages, but basic variants are still quite easy to get for people who haven't done programming before (and who don't want to be serious programmers).
Agreed (good old Atari ST...;) ) as far as the older versions are concerned. The stuff they've been pushing out recently is crap [I don't know why I'm still getting all their betas, but I won't complain about that].
Their (yuck!) Win32 port closely resembles a (yuck!!!) VB clone, but at least it works in wine.
the point is that pretty much any procedural language can take on whatever aspects of others it wishes
without remaining compatible, though, unfortunately. More fragmentation in programming languages ("this program requires xyz's implementation of the abc compiler, version 1.23.45") is just what we need (not).
Still, KBasic is probably a good idea - it will make it much easier for VB programmers to port their stuff to real OSes.
Right, but it definitely adds to security and makes it easier to build a secure system.
If someone sniffs on your connection and you're using telnet, enjoy.
If someone sniffs on your connection and you're using ssh (basically == telnet+cryptography), not too much of a problem.
Unless I missed something while looking through the sources, they've just added more tools/libraries (openssl, openssh, etc.), not modified the filesystem code in the kernel.
"rpm -e autorun" is the fix for that.
We've experimented with KDE 2.0 betas because we hoped we could get rid of Qt 1.x - it worked in my testing, but only because I don't use autorun.
In the 7.0final, KDE 1.1.x (2+patches) works perfectly, the 2.0 preview on the 2nd CD works ok.
For our primary use (being a wm with gnome), 0.16.4 was too bloated (re-implementing all the gnome functionality).
Now that we're using a different wm for gnome, updating is ok.
The fact that most of us like GNOME doesn't mean we don't like KDE.
We don't like the Qt 1.x license. That's all.
By now, GNOME has progressed far beyond a point where we would want to drop it as soon as there's a stable release of KDE running on Qt 2.x, so that's not going to happen.
We're shipping the latest PCMCIA drivers as part of the kernel.
We've also put in many changes to the apmd scripts to support suspend/resume much better.
Also, there's now a special "laptop" setup in the custom install.
XFree86 4.0 won't help you much with RAM/CPU, actually you might be better off using 3.3.6 on very low-end machines. Red Hat Linux 7 includes both 3.3.6 and 4.0.1.
Actually, it's because we want to be listed in the guinness book of world records for the least bugs, the biggest number of good features, the biggest user base...
Oops, now I've accidentally revealed our plans for world domination...
Err... What now...
Ah, yes, of course, we're picking the name just to win the favor of Linux, OF COURSE.
xinetd is more secure (it has tcp wrappers functionality implemented), and it supports having a different config file for each service, making it much more easily maintainable by config tools.
Because of this change, we could finally get all the inet services into ntsysv - along with the ones running as daemons.
This sort of stuff is MUCH harder to achieve with the traditional inetd.
The European version contains some additional CDs.
Since net access is still very expensive in many countries in Europe, we decided we should include more packages (that can be simply downloaded in the rest of the world) in Europe.
The additions (including, of course, Parsec) will be available on ftp.redhat.de (unless licenses don't permit it) - parts of them, such as our new, credit card sized Rescue CD, are available already.
We knew we'd be doing this since a day after 6.2 went gold, so we had enough time to stabilize them (yes, our patches have been given back and integrated in the trees). We also employ most of the maintainers for both, so we could make a qualified decision on which beta to take there.
Slashdot Mirror
We usually fix any problems reported to
bugzilla.
Since nobody can fix problems without being aware of them, please make sure you report those problems rather than just complaining on your favorite message board/mailing list/IRC channel/...
KDE2 fixes the issue you're complaining about - The file manager (konqueror) and the desktop icons (kdesktop) are separate.
They aren't installed by default because zip is not exactly a standard format on Linux.
The kdeutils package wants them because it includes a frontend.
Qt depends on Mesa if you want the OpenGL functionality, and many people need that (at least according to the number of "bug" reports we got when we shipped Qt without OpenGL support).
Upgrading depends on what you've used before.
If you've used a previous 2.0 beta, you want to update because of tons of bugfixes.
If you've used 1.x, check the KDE-2 launchpad.
As for switching from Gnome to KDE 2.x or vice versa, my recommendation has always been to try out both and check which you like better.
Since you can run KDE applications inside gnome and vice versa, you may like Konqueror and a couple of other new tools even if you decide not to switch.
Yes, they're going straight to /usr - that's because I don't see a need to keep KDE 1.x around now that 2.0 is stable.
It's an update, and should be handled as such. (I'll be putting together a kde1-compat package to keep old KDE 1.x apps running in a while, though updating to KDE 2.x versions is of course preferred).
First of all, the article is plain wrong.
Second, if we decided to drop sparc support commercially, we'd also try to get a community effort on keeping the port alive going.
Third, this has nothing whatsoever to do with releasing a closed source version. Doing that would do harm to the entire community.
Dropping a rarely used port would hurt a part of the community, but actually benefit others (all the engineering time we're currently putting into fixing up sparc would go to other projects).
They're all about the money
Untrue.
If it were true, we wouldn't have GPLed our code and allowed others to simply copy Red Hat Linux and put their label on it.
The article's subject should be "Red Hat Linux 7.0 possibly won't be released for sparc".
The sparc machines are still part of our build system, and we won't just drop it off.
If we ever decide to discontinue sparc support commercially, the sparc port will be turned into a community effort.
The only people using basic are
;)
...
a) Those who write or maintain Windows gui/components/ASP
They're all potential users of real OSes who just haven't used them yet.
Actually I know some people who match this description and who would move to a real OS if they didn't have to rewrite all their stuff in a totally different language.
Rewriting 20000 lines of BASIC code in C, C++ or Java is not exactly a fast or interesting job.
b) Those without the balls to learn Java
While there's no really working free JDK (kaffe still isn't there, probably some time in the future...), there are other reasons not to do Java.
If they wanted to do something useful, they would write a Java IDE
Plus a free JVM and JDK... Without these, a Java IDE is pretty much useless.
It seems all KDE wants to do is make linux into a Windows clone
No way. KDE doesn't have a bluescreen module, a "send-everything-to-microsoft"-feature (aka windowsupdate.microsoft.com), useless drive letters,
KDE is just trying to make the transition from a broken OS to a real OS as easy as possible, which is a good thing.
Basic is definitely not the greatest programming languages, but basic variants are still quite easy to get for people who haven't done programming before (and who don't want to be serious programmers).
best BASIC still has to be GFA BASIC
;) ) as far as the older versions are concerned. The stuff they've been pushing out recently is crap [I don't know why I'm still getting all their betas, but I won't complain about that].
Agreed (good old Atari ST...
Their (yuck!) Win32 port closely resembles a (yuck!!!) VB clone, but at least it works in wine.
the point is that pretty much any procedural language can take on whatever aspects of others it wishes
without remaining compatible, though, unfortunately. More fragmentation in programming languages ("this program requires xyz's implementation of the abc compiler, version 1.23.45") is just what we need (not).
Still, KBasic is probably a good idea - it will make it much easier for VB programmers to port their stuff to real OSes.
Right, but it definitely adds to security and makes it easier to build a secure system.
If someone sniffs on your connection and you're using telnet, enjoy.
If someone sniffs on your connection and you're using ssh (basically == telnet+cryptography), not too much of a problem.
Unless I missed something while looking through the sources, they've just added more tools/libraries (openssl, openssh, etc.), not modified the filesystem code in the kernel.
We've done it in 7.0 - since the timeframe was a bit short, we haven't SSLified everything, but there's still plenty of time for the next version...
Actually the stuff has been merged back into the tree for quite a while.
Red Hat is not Microsoft.
"rpm -e autorun" is the fix for that.
We've experimented with KDE 2.0 betas because we hoped we could get rid of Qt 1.x - it worked in my testing, but only because I don't use autorun.
In the 7.0final, KDE 1.1.x (2+patches) works perfectly, the 2.0 preview on the 2nd CD works ok.
You don't even need kernel 2.4 - we're also including the kernel for the Enterprise Edition (kernel-enterprise-*rpm) which has the LFS patch.
For our primary use (being a wm with gnome), 0.16.4 was too bloated (re-implementing all the gnome functionality).
Now that we're using a different wm for gnome, updating is ok.
The fact that most of us like GNOME doesn't mean we don't like KDE.
We don't like the Qt 1.x license. That's all.
By now, GNOME has progressed far beyond a point where we would want to drop it as soon as there's a stable release of KDE running on Qt 2.x, so that's not going to happen.
Red Hat will continue to support both desktops.
We're shipping the latest PCMCIA drivers as part of the kernel.
We've also put in many changes to the apmd scripts to support suspend/resume much better.
Also, there's now a special "laptop" setup in the custom install.
XFree86 4.0 won't help you much with RAM/CPU, actually you might be better off using 3.3.6 on very low-end machines. Red Hat Linux 7 includes both 3.3.6 and 4.0.1.
Actually, it's because we want to be listed in the guinness book of world records for the least bugs, the biggest number of good features, the biggest user base...
Oops, now I've accidentally revealed our plans for world domination...
Err... What now...
Ah, yes, of course, we're picking the name just to win the favor of Linux, OF COURSE.
xinetd is more secure (it has tcp wrappers functionality implemented), and it supports having a different config file for each service, making it much more easily maintainable by config tools.
Because of this change, we could finally get all the inet services into ntsysv - along with the ones running as daemons.
This sort of stuff is MUCH harder to achieve with the traditional inetd.
The European version contains some additional CDs.
Since net access is still very expensive in many countries in Europe, we decided we should include more packages (that can be simply downloaded in the rest of the world) in Europe.
The additions (including, of course, Parsec) will be available on ftp.redhat.de (unless licenses don't permit it) - parts of them, such as our new, credit card sized Rescue CD, are available already.
No, it's plain Red Hat Linux 7. .0 release. ;)
It's not another buggy
We knew we'd be doing this since a day after 6.2 went gold, so we had enough time to stabilize them (yes, our patches have been given back and integrated in the trees). We also employ most of the maintainers for both, so we could make a qualified decision on which beta to take there.