Bind 9.0 is safer because it was written from scratch with security in mind, unlike the prior versions.
qmail and djbdns are not open source, so we aren't going to ship them unless the license changes.
Netscape will disappear in future releases, so it won't be hypocritical anymore.
Since I'm located in.de, I need to use quite different tools. FTR I used "WISO Steuersparbuch 2000" with the wine package from 7.0 powertools back then. It's still working with the one from 7.1 powertools.
No windows DLLs, just the standard setup from the package.
I'm not going to get into any "my distribution is better than yours" flamewars. It should be fairly obvious what I'm using;), and I'm constantly trying everything else ("stealing" features is part of the job;) ).
My general recommendation is "try everything, stay with what you like best".
Apache 1.3.19 is included in 7.1 (You can always verify what version of apache and PHP is in the current release by checking what netcraft says about www.bero.org;) ).
You can download the 7.1 package from ftp (and it should work without changes on 7.0), but there probably won't be an errata release for older versions (since the old one didn't have any major problems, at least none I'm aware of, but I don't maintain the apache package).
Updates will always be available over ftp in addition to RHN, at least for the foreseeable future.
2.96-81 (from 7.1) fixes every genuine bug people reported to us.
Code that doesn't compile correctly with it will almost certainly not compile with gcc 3.0 when it's released.
As for the (double) and (float) things you're mentioning, we aren't aware of any problems.
What exactly is the problem? Do you have some sample code?
I've had much better results with the current release (using the wine package from 7.1 Powertools).
I don't have Windows or any of its DLLs, but all the stuff I've tried works almost perfectly (meaning I get occasional glitches in the display, but I can get the work done). It's mostly small tools though, such as a tool for filling out tax froms, an electronic phone book and an electronic map.
Obviously, you should wait until the Linux kernel is completely finished before shipping one.
Yes, quite right... We should probably buy out the CIA and have them shoot Linux, Alan and those other ****ing *****s who keep throwing new code at the Kernel rather than just letting our marketing guys say "It's finished".
Please don't tell management, since I'm a developer, if they decide to take that approach, it might cost me my job or more.;)
omniscience will be a hiring requirement for all support staff
Again, don't tell management. I don't want to be moved off to support.;))
seriously, working on Linux all day must be a lot of fun
It sure is. That's why many of us keep rejecting better paid jobs and it's why I'm here, reading/. in a Konqueror session and hacking on 7.2 stuff in a konsole right next to it, at 9 pm on a public holiday while I'm on vacation.;)
So, where did you report your issues? If you reported them to support, it was simply the wrong place. They should have told you, but they're probably too overloaded at times.
Since we can recompile all SRPMs with our compiler (how do we think we're putting together the distribution? Check the headers in the binaries and you'll see that we do eat our own dogfood), you'll probably get a "RESOLVED: NOTABUG" and a "We can't reproduce this, must be a local configuration issue, make sure you installed the correct version of glibc-devel", but we'd rather get 30 bug reports about things that are actually a local configuration issue than missing one genuine bug report.
You're forgetting that the binary incompatibility things affect any version of gcc.
If you have 2.95 and start updating to 3.0, you'll run into the exact same binary compatibility problems you'll have when you start updating from 2.96 to 3.0.
Same for egcs.
Yes, this sucks. The fix is to use gcc 3.0, which won't be out for a while - we (and probably all the other distributions) will fix it when it's ready.;)
wu-ftpd: Two of the wu-ftpd core developers (in the new wu-ftpd development group formed after the 2.6.0 release) are Red Hat employees. We've gone through the code a couple of times and we think it's safe now. There's no need to reinvent the wheel if you can fix up the existing one.
Yes, there are other alternatives, like proftpd or the openbsd ftpd, but they are not necessarily better just because they're different. proftpd has had just as many root exploits, none of the other ftpds has all the features our users have come to expect. Similarily, we don't switch to a tool that has a totally different configuration file unless there are plenty of good reasons to do that (such as inetd->xinetd). AFAIK no alternative ftpd provides an equivalent of kwuftpd, allowing even beginners to configure most of the features.
bind: The maintainers have noticed this problem themselves - bind 9.0.0 was a complete rewrite without using any old code.
We're shipping bind 9.1.0 with a lot of fixes from the 9.1.1 branch.
sendmail: While I personally would like to replace it with postfix, sendmail has matured, and some of the arguments for wu-ftpd apply here too - don't change to something radically different unless there are plenty of good reasons.
We are shipping both postfix and exim in powertools for people who know what they're doing, though.
ResierFS: It's not possible to do a ReiserFS only installation at this time because our kernel people have found it to be too unstable. It still caused file system corruption under some circumstances, and we couldn't fix those problems in time. If it stabilizes a bit more, it will be possible in the next version (along with ext3).
I can't reproduce the compiler problems you're talking about. We didn't use any non-2.96 compilers for building 7.0 and all errata packages. Chances are you didn't install a required -devel package or you're using nonstandard kernel headers.
As for not getting a response from support, this isn't nice (and I can't verify what's up, I'm in development, not support), but it's understandable.
Unless you've purchased a support contract, you'll only get installation support (even Red Hat has to live of something), and since you think you've found a bug, you should have reported it to our bug tracking system at http://bugzilla.redhat.com/bugzilla/ instead. You usually get replies to bugzilla entries in a reasonable time.
Actually we're pretty much shipping both of them, Netscape 6.01 isn't that different from mozilla 0.7 (just more buggy;) ).
Replacing one piece of proprietary **** with another is not an option IMO - the right replacements ATM are Konqueror and Mozilla, unless Opera decides to go open source. (Can Opera do anything Konqueror can't do ATM, anyway?)
wine: Some of us have sent in a couple of patches, but we're not the big guys behind wine, for the reasons mentioned before. wine is broken by definition (any emulation of an inherently broken API will have to be broken), and we'd rather push native applications than pushing an emulation layer and thereby the broken API it emulates, even though wine is nice to have ATM.
gcc 2.96 can compile code you can use on any other linux distro. The compatibility problem is related to C++ name mangling changes. Those haven't been consistant between any 2 major gcc releases, and that won't change until gcc 3.0 is out.
If you aren't using C++, you won't run into any problems. If you're using C++, either inlcude our libstdc++ in your binary distribution or link statically.
If you are aware of anything that causes infinite loops or gcc chokes with 2.96-81, please report it, so we can fix it. We're not aware of any big problems in 2.96-81, and we can't fix problems we aren't aware of.
C++ binary compatibility is a joke until gcc 3.0 is released. Handling C++ source isn't. gcc 2.96 does that well, 2.95.3 and earlier don't.
And yes, all of 7.0 was compiled with 7.0 itself.
If you can't get the SRPMs to recompile, it's a local installation issue (missing -devel packages? Modified glibc? Other kernel headers?).
If you find any 7.0 SRPM that can't be compiled on a 7.0 Everything install, let me know and I'll personally fix it, but this shouldn't be the case.
2.95.3 is just 2.95.2 with a couple of fixes for the most critical bugs.
It doesn't address any of the features in 2.96 we need, such as real C++ support or ia64 support.
The kernel release was "late" for our deadlines. They're not marketing deadlines, but ones that make sense. If we waited for 2.4.4 and released 7.1 after testing it, 2.4.5 would be current by the time it got out of the door. If we waited for 2.4.5, 2.4.6 would be current.
You need to make a cut at some point. For us, that's "when it's ready". 2.4.2 with our patches *is* ready for prime time, so there was no need to delay the deadline any more.
Not officially supporting anything that hasn't passed QA isn't corporate idiocy either. It's simply practical. If someone calls support and complains "apache doesn't work", how are they supposed to help the user efficiently if he's using a kernel and glibc we didn't approve or test?
Not really.
I use Konqueror 99% of the time, but if I need to use Java (e.g. for my bank's online banking system), I can't get around Netscape 4.x for now.
The problem is that Konqueror and Mozilla can't handle Java without an installed JVM - and there's no working free JVM out there. (Kaffe is a start, but not really usable yet).
Unlike the various JDKs out there, Netscape 4.x is at least freely redistributable. That's why we're keeping it in for now.
"Install Red Hat Linux, then go download a JDK at xyz.com" is not an option for many people out there - for example in most parts of Europe, people still pay for net connections by the minute. Even if there's no per minute charge, people are still bandwidth imparied even if they need highspeed access. I'm posting this over a 64 kBit/s line by the way - it's the fastest link available around here. My order for a DSL link has been waiting for that evil monopolist for 15 months by now.
While sabotaging the kernel like that wouldn't be a violation of the GPL (the GPL allows to make any changes, even adding a bluescreen module), it would definitely be a horrible thing to do, and something we'd never do.
This is talking about support as in "you may call our support center and ask the people how to set up software RAID without paying extra".
Of course the normal version supports software RAID, but you're on your own (or need to buy a support contract) if you can't figure out how to set it up.
Slashdot Mirror
Bind 9.0 is safer because it was written from scratch with security in mind, unlike the prior versions.
qmail and djbdns are not open source, so we aren't going to ship them unless the license changes.
Netscape will disappear in future releases, so it won't be hypocritical anymore.
Since I'm located in .de, I need to use quite different tools. FTR I used "WISO Steuersparbuch 2000" with the wine package from 7.0 powertools back then. It's still working with the one from 7.1 powertools.
No windows DLLs, just the standard setup from the package.
I'm not going to get into any "my distribution is better than yours" flamewars. It should be fairly obvious what I'm using ;), and I'm constantly trying everything else ("stealing" features is part of the job ;) ).
My general recommendation is "try everything, stay with what you like best".
Apache 1.3.19 is included in 7.1 (You can always verify what version of apache and PHP is in the current release by checking what netcraft says about www.bero.org ;) ).
You can download the 7.1 package from ftp (and it should work without changes on 7.0), but there probably won't be an errata release for older versions (since the old one didn't have any major problems, at least none I'm aware of, but I don't maintain the apache package).
Updates will always be available over ftp in addition to RHN, at least for the foreseeable future.
Get kmail from the current KDE CVS tree.
2.96-81 (from 7.1) fixes every genuine bug people reported to us.
Code that doesn't compile correctly with it will almost certainly not compile with gcc 3.0 when it's released.
As for the (double) and (float) things you're mentioning, we aren't aware of any problems.
What exactly is the problem? Do you have some sample code?
If so, report it at our bug tracking system and/or drop me a message.
I've had much better results with the current release (using the wine package from 7.1 Powertools).
I don't have Windows or any of its DLLs, but all the stuff I've tried works almost perfectly (meaning I get occasional glitches in the display, but I can get the work done). It's mostly small tools though, such as a tool for filling out tax froms, an electronic phone book and an electronic map.
Obviously, you should wait until the Linux kernel is completely finished before shipping one.
;)
;))
/. in a Konqueror session and hacking on 7.2 stuff in a konsole right next to it, at 9 pm on a public holiday while I'm on vacation. ;)
Yes, quite right... We should probably buy out the CIA and have them shoot Linux, Alan and those other ****ing *****s who keep throwing new code at the Kernel rather than just letting our marketing guys say "It's finished".
Please don't tell management, since I'm a developer, if they decide to take that approach, it might cost me my job or more.
omniscience will be a hiring requirement for all support staff
Again, don't tell management. I don't want to be moved off to support.
seriously, working on Linux all day must be a lot of fun
It sure is. That's why many of us keep rejecting better paid jobs and it's why I'm here, reading
So, where did you report your issues? If you reported them to support, it was simply the wrong place. They should have told you, but they're probably too overloaded at times.
The right place to report bugs is http://bugzilla.redhat.com/bugzilla.
Since we can recompile all SRPMs with our compiler (how do we think we're putting together the distribution? Check the headers in the binaries and you'll see that we do eat our own dogfood), you'll probably get a "RESOLVED: NOTABUG" and a "We can't reproduce this, must be a local configuration issue, make sure you installed the correct version of glibc-devel", but we'd rather get 30 bug reports about things that are actually a local configuration issue than missing one genuine bug report.
You're forgetting that the binary incompatibility things affect any version of gcc.
;)
If you have 2.95 and start updating to 3.0, you'll run into the exact same binary compatibility problems you'll have when you start updating from 2.96 to 3.0.
Same for egcs.
Yes, this sucks. The fix is to use gcc 3.0, which won't be out for a while - we (and probably all the other distributions) will fix it when it's ready.
Yes, there are other alternatives, like proftpd or the openbsd ftpd, but they are not necessarily better just because they're different. proftpd has had just as many root exploits, none of the other ftpds has all the features our users have come to expect. Similarily, we don't switch to a tool that has a totally different configuration file unless there are plenty of good reasons to do that (such as inetd->xinetd). AFAIK no alternative ftpd provides an equivalent of kwuftpd, allowing even beginners to configure most of the features.
We're shipping bind 9.1.0 with a lot of fixes from the 9.1.1 branch.
We are shipping both postfix and exim in powertools for people who know what they're doing, though.
And in violation of the FHS...
</mode>
The FHS mentions the distribution updates shouldn't touch anything in
/opt (just like
I can't reproduce the compiler problems you're talking about. We didn't use any non-2.96 compilers for building 7.0 and all errata packages. Chances are you didn't install a required -devel package or you're using nonstandard kernel headers.
As for not getting a response from support, this isn't nice (and I can't verify what's up, I'm in development, not support), but it's understandable.
Unless you've purchased a support contract, you'll only get installation support (even Red Hat has to live of something), and since you think you've found a bug, you should have reported it to our bug tracking system at http://bugzilla.redhat.com/bugzilla/ instead. You usually get replies to bugzilla entries in a reasonable time.
AFAIK with x >= 5, so it's not a problem.
Recent releases of rpm 3.0.x can handle v4 packages.
We're including both. The old one is called aic7xxx, the new one is aic7xxx_new/aic7xxx_mod.
AFAIK the old (proven stable) one is used by default.
No. We're including Qt 2.3.0, Freetype 2.0.1, XFree86 4.0.3 and KDE 2.1.1 + extra fixes.
Anti-Aliasing is turned off by default, but turning it on is as simple as clicking a checkbox in KControl.
No, it'll just slow things down. A lot.
Also, s/glib/glibc/, they're two quite different beasts.
Actually we're pretty much shipping both of them, Netscape 6.01 isn't that different from mozilla 0.7 (just more buggy ;) ).
Replacing one piece of proprietary **** with another is not an option IMO - the right replacements ATM are Konqueror and Mozilla, unless Opera decides to go open source. (Can Opera do anything Konqueror can't do ATM, anyway?)
wine: Some of us have sent in a couple of patches, but we're not the big guys behind wine, for the reasons mentioned before. wine is broken by definition (any emulation of an inherently broken API will have to be broken), and we'd rather push native applications than pushing an emulation layer and thereby the broken API it emulates, even though wine is nice to have ATM.
gcc 2.96 can compile code you can use on any other linux distro. The compatibility problem is related to C++ name mangling changes. Those haven't been consistant between any 2 major gcc releases, and that won't change until gcc 3.0 is out.
If you aren't using C++, you won't run into any problems. If you're using C++, either inlcude our libstdc++ in your binary distribution or link statically.
If you are aware of anything that causes infinite loops or gcc chokes with 2.96-81, please report it, so we can fix it. We're not aware of any big problems in 2.96-81, and we can't fix problems we aren't aware of.
C++ binary compatibility is a joke until gcc 3.0 is released. Handling C++ source isn't. gcc 2.96 does that well, 2.95.3 and earlier don't.
And yes, all of 7.0 was compiled with 7.0 itself.
If you can't get the SRPMs to recompile, it's a local installation issue (missing -devel packages? Modified glibc? Other kernel headers?).
If you find any 7.0 SRPM that can't be compiled on a 7.0 Everything install, let me know and I'll personally fix it, but this shouldn't be the case.
That's because the sources are broken (not ISO C99/ISO C++98 compliant), not because the compiler is broken.
Check http://www.bero.org/gcc296.html for a couple of examples of broken code that used to work with older compilers, and how to fix it.
2.95.3 is just 2.95.2 with a couple of fixes for the most critical bugs.
It doesn't address any of the features in 2.96 we need, such as real C++ support or ia64 support.
The kernel release was "late" for our deadlines. They're not marketing deadlines, but ones that make sense. If we waited for 2.4.4 and released 7.1 after testing it, 2.4.5 would be current by the time it got out of the door. If we waited for 2.4.5, 2.4.6 would be current.
You need to make a cut at some point. For us, that's "when it's ready". 2.4.2 with our patches *is* ready for prime time, so there was no need to delay the deadline any more.
Not officially supporting anything that hasn't passed QA isn't corporate idiocy either. It's simply practical. If someone calls support and complains "apache doesn't work", how are they supposed to help the user efficiently if he's using a kernel and glibc we didn't approve or test?
Not really.
I use Konqueror 99% of the time, but if I need to use Java (e.g. for my bank's online banking system), I can't get around Netscape 4.x for now.
The problem is that Konqueror and Mozilla can't handle Java without an installed JVM - and there's no working free JVM out there. (Kaffe is a start, but not really usable yet).
Unlike the various JDKs out there, Netscape 4.x is at least freely redistributable. That's why we're keeping it in for now.
"Install Red Hat Linux, then go download a JDK at xyz.com" is not an option for many people out there - for example in most parts of Europe, people still pay for net connections by the minute. Even if there's no per minute charge, people are still bandwidth imparied even if they need highspeed access. I'm posting this over a 64 kBit/s line by the way - it's the fastest link available around here. My order for a DSL link has been waiting for that evil monopolist for 15 months by now.
#include
While sabotaging the kernel like that wouldn't be a violation of the GPL (the GPL allows to make any changes, even adding a bluescreen module), it would definitely be a horrible thing to do, and something we'd never do.
This is talking about support as in "you may call our support center and ask the people how to set up software RAID without paying extra".
Of course the normal version supports software RAID, but you're on your own (or need to buy a support contract) if you can't figure out how to set it up.