Unfortunately the Adaptec AIC7xxx SCSI driver was REALLY broken and 6.2 won't even install
It is my understanding that some cards using the AIC7xxx chipset are really broken and 6.2 doesn't have the right workarounds (it definitely works on my home machine with an original Adaptec 2940).
Did you try the patch from http://people.redhat.com/dledford/ai c7xxx.html? A couple of people have reported that fixes the problem (use the driver at the BOTTOM of the list), so I guess it's actually resolved.
I don't have the actual hardware to verify this myself.
Not for now, because it's too unstable (journal format changing every couple of releases), and once you've managed to mess up a filesystem beyond what a journal replay can fix, chances are you're in trouble with reiserfs. Once it has stabilized, we'll include it unless something better comes along before that.
For 7.0, I'll put up a kernel RPM with the ReiserFS patch on http://people.redhat.com/bero/experimen tal/ when I have the time (probably shortly after the 7.0 release) for those who want to play, but don't say I didn't warn you.
AFAIK you may not use them in a place where the RSA patent applies, so don't get them unless you're outside of the US and any other contry that has the RSA patent.
Fortunately, the patent will expire later this year.
Missing from the beta, present in our current tree (and definitely the final).
kernel 2.4test5ac
Actually it's there, on the 2nd CD and not installed by default because it's known to have some critical bugs.
tux 1.0
Needs kernel 2.4
apache 2.0pre4
Chances are 2.0 won't be released in time for 7.0. It'll probably be in 7.1 (and I'll make RPMs for 7.0 available as soon as I have the time).
bind 9.0
Same as for apache - I'm actually using the 9.0.0 release candidate to host bero.org, but it has a couple of problems, like some missing utilities, and requires all master zones to be changed because the TTL stuff is now mandatory (and most people haven't used it with bind 8), so there's no really clean update path. Not something we could do in the couple of days between the 9.0.0rc1 release and the beta.
staroffice
It's still binary-only, they've just announced they'll GPL it by October 13th. We'll include it once that happened, until then, it will be on the Linux Applications CD in the boxed sets.
LVM
It's present in the 2.4 kernel we're shipping.
reiserfs
Too unstable at the moment. They keep changing the journal format, and the recovery tools aren't quite where they should be. Yes, reiserfs is nice while it works (I'm actually using it on one of my machines), but if something doesn't work and a journal replay doesn't fix it, you're usually in trouble.
I'll make a kernel RPM with the patch available over at people.redhat.com/bero/experimental when I have the time (probably shortly after the 7.0 release) for those who want to play - but for now, we don't feel we can support it.
I've actually had a look at that before - but since I couldn't find any license in there, we can't ship any of them. Who can guarantee that the fonts we pick aren't taken from some company that will sue us for stealing?
I like to download slightly buggy debian packages and write to an author and say, "hey, this is a little bit messed up"
Sure, we listen to those, as well. If you don't want to use bugzilla for whatever reason, just pick the latest name in the changelog. Chances are you'll get a reply, even if it takes a while (we get a lot of them, I'm admittedly about 500 mails behind at the moment).
I also like a minimalist base install
We've fixed that up for 7.0. (Pick custom install and select individual packages, then don't select anything). We're down to 30 or so packages in a minimal install.
Why do distros feel the need to come with a shitload of software?
In some countries, net connections are terribly expensive, and the average computer store (unfortunately) still doesn't carry a lot of Linux software or mirrors of Linux ftp servers, so we're better off including a lot of things.
Including it on the CDs doesn't mean you have to install it... That's what custom installs are there for.
You can turn that of at installation time if you choose a custom install.
The reasoning is, basically, that someone who can't run a custom install probably won't find his way around on the text console. Someone who can (and wants to) handle the text console as primary UI is much more likely to know how to vi/etc/inittab than someone who is just looking for a way to start an easy interface at bootup.
I didn't mean to be insulting of course
I thought so - I just prefer "an advanced user might miss the XYZ feature FreeBSD has" over "it seems to be targeted more at newbies", because once we know WHAT is missing, we can fix it...
Does the XFree 4.0.1 in RH 7.0b come with it's own free TT fonts? (Freetype IIRC)
Freetype is a LIBRARY that supports handling truetype fonts. We've been including it and patching XFree86 to handle it since 6.0 or so.
However, there are no TT fonts included ATM (neither with the 7.0beta nor with Freetype) - if you can point me to a place that has good and free TT fonts that we could include, do. It's hard to find any high-quality free TT fonts.
I have been keeping up with RawHide and I haven't seen anything going which would warrant a 7.0 designation
All the major number increase means is that an application compiled on a 7.0 system won't run on a 6.x system without being recompiled (because of the glibc and compiler upgrades).
Binary compatibility throughout a major number release is very important to us (do you think we LIKED keeping egcs 1.1.2 as the primary compiler in 6.2?).
Why does there need to the start of beta? Should not all distributions be continuously in beta?
Yes. And we are. Check out Raw Hide, which is actually a snapshot of our current development work, updated every couple of days.
Our official betas are when we decide something has all the features we need in the final version, and generate ISO images to make it available to a broader group of people.
Red Hat Beta 6.0, 6.1 and Alpha 6.2 which include the newest and most unstable of all releases.
You must be using a different 6.2 than the rest of the world then... If you have any issues with 6.2, report them - we can't fix problems we aren't aware of. Considering my web server (running 6.2) has had an uptime of 103 days before I rebooted it for a kernel upgrade, I'd hardly call it alpha-quality code.
Each time the version number of glibc is increased by 0.0.1, Red Hat grabs the new version and uses it to bounce up its version number by 1.0
Entirely untrue. We increase the major version number when there are changes that will prevent stuff compiled on the new version to run on the old version without being recompiled. For 7.0, that's caused by the change of compilers (C++ binary incompatibility) and glibc (2.2, not 2.1.8).
I truly do not understand the purpose of releasing commercial beta code unless... Unless they want to use all their users to do their work for 'm
No matter how large a company is, it can't possibly have all combinations of hardware, so how are we supposed to find bugs that occur only in systems that have the MyNet 2000 network card in combination with a Weirdo UW-SCSI card? That's (part of) why public betas are absolutely needed.
As for supplying beta testers with the final version, I'm all for it (no, I don't have any say on this), but it's probably hard to do - how do you determine who did "enough" testing? 10 Entries in Bugzilla? Then what about someone who found only one bug, but submitted a perfect fix? You'll probably always end up being unfair to someone.
Interesting that they wouldn't include a beta of the kernel but of KDE
We are actually including a 2.4 kernel package (I think it's on the 2nd CD), it's just not installed by default.
The reasons are simple - you don't want a mission critical server to crash because of a broken kernel. While a UI segfaulting is not very nice, it's hardly as critical.
We're normally in a 6 months release cycle - which I think is about right: Making even more releases would sometimes be nice for the technical side, but would definitely be scary for retailers.
Making less releases would put us behind all the others (just imagine the slashdot announcement "SomeDistro 10.3 released, has Kernel 2.4.1 and KDE 2.0, while Red Hat is still at Kernel 2.0.38 and KDE 1.0" - nobody (except for some Red Hat haters, maybe) would like that!) - at the pace of development in Linux, 6 months can be a major change...
We're not talking about 3-years-later-than-95-is-still-almost-the-same-OS. ..
Changing that would be giving up some of the biggest advantages of Linux and (fast) open source development.
Red Hat. Inc. presents a beta release of Red Hat Linux for your hacking pleasure. First, the regular drill:
This is a beta release of Red Hat Linux. It is not intended for mission critical applications. It's not even intended for non-mission critical applications. Important data should not be entrusted to Pinstripe, as it may eat it and make loud belching noises.
Significant changes have been made since the last version of Red Hat Linux. We need your help to find and report bugs. Search for existing bug reports for problems you find by using bugzilla at:
This beta includes so much cutting edge software, the binary packages come on two iso images. The installation program now handles reading packages from multiple CDs.
* Where can I get this release?
Pinstripe can be downloaded from our public FTP site at:
ftp://ftp.redhat.com/pub/redhat/beta/pinstripe
With the support of volunteers ftp site administrators, Pinstripe is available from several mirrors. The following have complete copies of Pinstripe, please use a mirror close to you:
North Carolina, USA: ftp://metalab.unc.edu/pub/Linux/distributions/redh at/beta/pinstripe/ http://metalab.unc.edu/pub/Linux/distributions/red hat/beta/pinstripe/
General system improvements: o FHS compliant packaging of files /usr/man is now/usr/share/man /usr/doc is now/usr/share/doc /usr/info is now/usr/share/info See http://www.pathname.com/fhs/ for more information
o Document roots for Apache and anonymous FTP are removed from /home so it may be automounted.
o Packages with services are automatically restarted on live upgrades
o Expanded LDAP integration
o Expanded Kerberos integration
Core system components: o glibc 2.1.91 o XFree86 4.0.1, XFree86 4.0.1 runtime environment o XFree86 3.3.6 X servers included for maximum hardware compatibility o GNOME 1.2 o kernel 2.2.16 o GCC 2.96
Expanded hardware support: o Basic USB support (mouse and keyboards) o Expanded hardware accelerated 3-D support
System service changes: o inetd replaced by xinetd o BSD lpr replaced by LPRng
A sampling of package upgrades: o GIMP 1.1.24 o Perl 5.6.0 o Tcl/Tk 8.3.1
A sampling of Package additions: o SDL, smpeg o SANE o gphoto o MySQL o AbiWord o dia o ispell has been replaced by aspell o XEmacs
Next generation development library previews included: o pango: Unicode font rendering See http://www.pango.org/ o Inti: C++ foundation libraries including GTK+ GUI toolkit classes See http://sources.redhat.com/inti/
No matter how you try and put it, a piece of code does not share any similarities to a poem [...] Coding is just a process, not a work of art
Depends on your definitions... There is actually creativity involved (if you can't accept that coming up with a different solution to a problem is creativity, think of creating the user interface).
Of course there's a difference between writing and coding, but there are also a couple of similarities (also, comparing this to technical writing is much more appropriate than comparing it to writing a poem; technical writing is a form of expression and thereby protected, as well!) - and these similarities are all that matters for deciding whether or not it is a type of expression and creativity:
You usually write it (text/code) to achieve a specific purpose.
There is a nearly unlimited number of ways to achieve the same goal (choice of language/programming language, wording/coding style)
Give any two people the same task in writing or coding, and chances are both will come up with versions that fit the task, but are very different.
You might have to partition the DB into multiple files to get around the 2GB file size limit on Linux
Or patch the kernel so it doesn't have the limit. Patches for this are available; if you don't want to build your own kernel, get the Red Hat Linux Enterprise Edition, which has this patch by default.
Slashdot Mirror
Unfortunately the Adaptec AIC7xxx SCSI driver was REALLY broken and 6.2 won't even install
It is my understanding that some cards using the AIC7xxx chipset are really broken and 6.2 doesn't have the right workarounds (it definitely works on my home machine with an original Adaptec 2940).
Did you try the patch from http://people.redhat.com/dledford/ai c7xxx.html? A couple of people have reported that fixes the problem (use the driver at the BOTTOM of the list), so I guess it's actually resolved.
I don't have the actual hardware to verify this myself.
Not for now, because it's too unstable (journal format changing every couple of releases), and once you've managed to mess up a filesystem beyond what a journal replay can fix, chances are you're in trouble with reiserfs.
Once it has stabilized, we'll include it unless something better comes along before that.
For 7.0, I'll put up a kernel RPM with the ReiserFS patch on http://people.redhat.com/bero/experimen tal/ when I have the time (probably shortly after the 7.0 release) for those who want to play, but don't say I didn't warn you.
It's not about crypto regulations this time, it's about the #include RSA patent.
[Open]SSH uses RSA for host key authentication.
We've made RPMs available at ftp://ftp.redhat.de/pub/rh-addons/secur ity/, where the RSA patent doesn't apply, though.
AFAIK you may not use them in a place where the RSA patent applies, so don't get them unless you're outside of the US and any other contry that has the RSA patent.
Fortunately, the patent will expire later this year.
What's missing:
sendmail 8.11
Missing from the beta, present in our current tree (and definitely the final).
kernel 2.4test5ac
Actually it's there, on the 2nd CD and not installed by default because it's known to have some critical bugs.
tux 1.0
Needs kernel 2.4
apache 2.0pre4
Chances are 2.0 won't be released in time for 7.0. It'll probably be in 7.1 (and I'll make RPMs for 7.0 available as soon as I have the time).
bind 9.0
Same as for apache - I'm actually using the 9.0.0 release candidate to host bero.org, but it has a couple of problems, like some missing utilities, and requires all master zones to be changed because the TTL stuff is now mandatory (and most people haven't used it with bind 8), so there's no really clean update path. Not something we could do in the couple of days between the 9.0.0rc1 release and the beta.
staroffice
It's still binary-only, they've just announced they'll GPL it by October 13th. We'll include it once that happened, until then, it will be on the Linux Applications CD in the boxed sets.
LVM
It's present in the 2.4 kernel we're shipping.
reiserfs
Too unstable at the moment. They keep changing the journal format, and the recovery tools aren't quite where they should be.
Yes, reiserfs is nice while it works (I'm actually using it on one of my machines), but if something doesn't work and a journal replay doesn't fix it, you're usually in trouble.
I'll make a kernel RPM with the patch available over at people.redhat.com/bero/experimental when I have the time (probably shortly after the 7.0 release) for those who want to play - but for now, we don't feel we can support it.
I presume that's a carefully selected snapshot
For the beta, yes.
Everything in there except for the kernel and some compat packages has been compiled with the snapshot.
For the final, we hope to include the final release.
Has the ia32 c++ ABI been finalised (and implemented)?
Implemented: yes.
Finalised: Hopefully, but there might be some more changes (which will of course make it into the 7.0 final).
I've actually had a look at that before - but since I couldn't find any license in there, we can't ship any of them.
Who can guarantee that the fonts we pick aren't taken from some company that will sue us for stealing?
I like to download slightly buggy debian packages and write to an author and say, "hey, this is a little bit messed up"
Sure, we listen to those, as well. If you don't want to use bugzilla for whatever reason, just pick the latest name in the changelog.
Chances are you'll get a reply, even if it takes a while (we get a lot of them, I'm admittedly about 500 mails behind at the moment).
I also like a minimalist base install
We've fixed that up for 7.0. (Pick custom install and select individual packages, then don't select anything).
We're down to 30 or so packages in a minimal install.
Why do distros feel the need to come with a shitload of software?
In some countries, net connections are terribly expensive, and the average computer store (unfortunately) still doesn't carry a lot of Linux software or mirrors of Linux ftp servers, so we're better off including a lot of things.
Including it on the CDs doesn't mean you have to install it... That's what custom installs are there for.
I don't really like that it boots to X as default
/etc/inittab than someone who is just looking for a way to start an easy interface at bootup.
You can turn that of at installation time if you choose a custom install.
The reasoning is, basically, that someone who can't run a custom install probably won't find his way around on the text console. Someone who can (and wants to) handle the text console as primary UI is much more likely to know how to vi
I didn't mean to be insulting of course
I thought so - I just prefer "an advanced user might miss the XYZ feature FreeBSD has" over "it seems to be targeted more at newbies", because once we know WHAT is missing, we can fix it...
Does the XFree 4.0.1 in RH 7.0b come with it's own free TT fonts? (Freetype IIRC)
Freetype is a LIBRARY that supports handling truetype fonts.
We've been including it and patching XFree86 to handle it since 6.0 or so.
However, there are no TT fonts included ATM (neither with the 7.0beta nor with Freetype) - if you can point me to a place that has good and free TT fonts that we could include, do.
It's hard to find any high-quality free TT fonts.
I have been keeping up with RawHide and I haven't seen anything going which would warrant a 7.0 designation
All the major number increase means is that an application compiled on a 7.0 system won't run on a 6.x system without being recompiled (because of the glibc and compiler upgrades).
Binary compatibility throughout a major number release is very important to us (do you think we LIKED keeping egcs 1.1.2 as the primary compiler in 6.2?).
Why does there need to the start of beta? Should not all distributions be continuously in beta?
Yes. And we are. Check out Raw Hide, which is actually a snapshot of our current development work, updated every couple of days.
Our official betas are when we decide something has all the features we need in the final version, and generate ISO images to make it available to a broader group of people.
Red Hat Beta 6.0, 6.1 and Alpha 6.2 which include the newest and most unstable of all releases.
You must be using a different 6.2 than the rest of the world then...
If you have any issues with 6.2, report them - we can't fix problems we aren't aware of. Considering my web server (running 6.2) has had an uptime of 103 days before I rebooted it for a kernel upgrade, I'd hardly call it alpha-quality code.
Each time the version number of glibc is increased by 0.0.1, Red Hat grabs the new version and uses it to bounce up its version number by 1.0
Entirely untrue.
We increase the major version number when there are changes that will prevent stuff compiled on the new version to run on the old version without being recompiled.
For 7.0, that's caused by the change of compilers (C++ binary incompatibility) and glibc (2.2, not 2.1.8).
We're compiling some selected packages with optimizations - that way, we can still run on a 386, but get most of the speed out of optimizations.
Also, since we're using gcc 2.96, the generated 386 code is probably somewhat faster than the "optimized" code earlier versions produced.
I truly do not understand the purpose of releasing commercial beta code unless... Unless they want to use all their users to do their work for 'm
No matter how large a company is, it can't possibly have all combinations of hardware, so how are we supposed to find bugs that occur only in systems that have the MyNet 2000 network card in combination with a Weirdo UW-SCSI card?
That's (part of) why public betas are absolutely needed.
As for supplying beta testers with the final version, I'm all for it (no, I don't have any say on this), but it's probably hard to do - how do you determine who did "enough" testing? 10 Entries in Bugzilla? Then what about someone who found only one bug, but submitted a perfect fix?
You'll probably always end up being unfair to someone.
Do any distros have palns to ship nVidia's official drivers with their distros?
;)
We'll start doing that as soon as they release the source. If anyone at nVidia is reading this, please cause the right consequences.
Interesting that they wouldn't include a beta of the kernel but of KDE
We are actually including a 2.4 kernel package (I think it's on the 2nd CD), it's just not installed by default.
The reasons are simple - you don't want a mission critical server to crash because of a broken kernel.
While a UI segfaulting is not very nice, it's hardly as critical.
s/needing/supporting/g
For a normal install, you won't need the second CD. It's just there for some extra packages that most people probably won't need.
We're normally in a 6 months release cycle - which I think is about right: Making even more releases would sometimes be nice for the technical side, but would definitely be scary for retailers.
. ..
Making less releases would put us behind all the others (just imagine the slashdot announcement "SomeDistro 10.3 released, has Kernel 2.4.1 and KDE 2.0, while Red Hat is still at Kernel 2.0.38 and KDE 1.0" - nobody (except for some Red Hat haters, maybe) would like that!) - at the pace of development in Linux, 6 months can be a major change...
We're not talking about 3-years-later-than-95-is-still-almost-the-same-OS
Changing that would be giving up some of the biggest advantages of Linux and (fast) open source development.
less and less to those who seek to immerse themselves in the goodness of a unix environment
How so? (If we don't know what's wrong, we can't fix it!)
I'm running it without X about 90% of the time, I'm not missing anything...
Announcing...
h at/beta/pinstripe/ d hat/beta/pinstripe/
a t/beta/pinstripe/ h at/beta/pinstripe/
t a/pinstripe/ e ta/pinstripe/
/ pinstripe/ a /pinstripe/
r edhat.com/redhat/beta/pinstripe/
n stripe
/ redhat/redhat/beta/pinstripe/
/ beta/pinstripe/
a /pinstripe/ t /beta/pinstripe/
i pe/ r ipe/
i nstripe/
i nstripe/ p instripe/
/ redhat/redhat/beta/pinstripe/
i nstripe/
h at/beta/pinstripe/
/usr/man is now /usr/share/man
/usr/doc is now /usr/share/doc
/usr/info is now /usr/share/info
/home so it may be automounted.
Red Hat Linux "Pinstripe"
a Beta release
Red Hat. Inc. presents a beta release of Red Hat Linux for your
hacking pleasure. First, the regular drill:
This is a beta release of Red Hat Linux. It is not intended for
mission critical applications. It's not even intended for
non-mission critical applications. Important data should not be
entrusted to Pinstripe, as it may eat it and make loud belching
noises.
Significant changes have been made since the last version of Red Hat
Linux. We need your help to find and report bugs. Search for
existing bug reports for problems you find by using bugzilla at:
http://bugzilla.redhat.com/bugzilla/
Attach patches if you're motivated!
This beta includes so much cutting edge software, the binary packages
come on two iso images. The installation program now handles reading
packages from multiple CDs.
* Where can I get this release?
Pinstripe can be downloaded from our public FTP site at:
ftp://ftp.redhat.com/pub/redhat/beta/pinstripe
With the support of volunteers ftp site administrators, Pinstripe is
available from several mirrors. The following have complete copies of
Pinstripe, please use a mirror close to you:
North Carolina, USA:
ftp://metalab.unc.edu/pub/Linux/distributions/red
http://metalab.unc.edu/pub/Linux/distributions/re
California, USA:
ftp://ftp.sourceforge.net/pub/mirrors/redhat/redh
http://ftp.sourceforge.net/pub/mirrors/redhat/red
California, USA:
ftp://ftp.kernel.org/pub/mirrors/redhat/redhat/be
http://www.kernel.org/pub/mirrors/redhat/redhat/b
Connecticut, USA:
ftp://ftp.uselinux.org/pub/redhat/beta/pinstripe/
Indiana, USA:
ftp://csociety-ftp.ecn.purdue.edu/pub/redhat/beta
http://csociety-ftp.ecn.purdue.edu/pub/redhat/bet
Michigan, USA:
ftp://mrhankey.bizserve.com/pub/linux/redhat/ftp.
New York, USA:
ftp://ftp.ee.cornell.edu/pub/linux/redhat/beta/pi
Pennsylvania, USA:
ftp://carroll.cac.psu.edu/pub/linux/distributions
Pennsylvania, USA:
ftp://cronus.res.cmu.edu/pub/linux/ftp.redhat.com
Tennessee, USA:
ftp://sunsite.utk.edu/pub/linux/redhat/redhat/bet
http://sunsite.utk.edu/ftp/pub/linux/redhat/redha
Australia:
ftp://mirror.aarnet.edu.au/pub/redhat/beta/pinstr
http://mirror.aarnet.edu.au/pub/redhat/beta/pinst
Germany:
ftp://ftp.gmd.de/mirrors/redhat.com/redhat/beta/p
Germany:
ftp://ftp.uni-bayreuth.de/pub/linux/redhat/beta/p
http://ftp.uni-bayreuth.de/pub/linux/redhat/beta/
Norway:
(ISO images only)
ftp://carroll.cac.psu.edu/pub/linux/distributions
Peru:
ftp://sajino.terra.com.pe/pub/linux/redhat/beta/p
Japan:
ftp://ftp.kddlabs.co.jp/Linux/packages/RedHat/red
* What's new in this beta?
General system improvements:
o FHS compliant packaging of files
See http://www.pathname.com/fhs/ for more information
o Document roots for Apache and anonymous FTP are removed from
o Packages with services are automatically restarted on live
upgrades
o Expanded LDAP integration
o Expanded Kerberos integration
Core system components:
o glibc 2.1.91
o XFree86 4.0.1, XFree86 4.0.1 runtime environment
o XFree86 3.3.6 X servers included for maximum hardware compatibility
o GNOME 1.2
o kernel 2.2.16
o GCC 2.96
Expanded hardware support:
o Basic USB support (mouse and keyboards)
o Expanded hardware accelerated 3-D support
System service changes:
o inetd replaced by xinetd
o BSD lpr replaced by LPRng
A sampling of package upgrades:
o GIMP 1.1.24
o Perl 5.6.0
o Tcl/Tk 8.3.1
A sampling of Package additions:
o SDL, smpeg
o SANE
o gphoto
o MySQL
o AbiWord
o dia
o ispell has been replaced by aspell
o XEmacs
Next generation development library previews included:
o pango: Unicode font rendering
See http://www.pango.org/
o Inti: C++ foundation libraries including GTK+ GUI toolkit classes
See http://sources.redhat.com/inti/
Enjoy!
The OS Development Team
Red Hat, Inc.
Depends on your definitions...
There is actually creativity involved (if you can't accept that coming up with a different solution to a problem is creativity, think of creating the user interface).
Of course there's a difference between writing and coding, but there are also a couple of similarities (also, comparing this to technical writing is much more appropriate than comparing it to writing a poem; technical writing is a form of expression and thereby protected, as well!) - and these similarities are all that matters for deciding whether or not it is a type of expression and creativity:
So, coding IS a form of expression.
You might have to partition the DB into multiple files to get around the 2GB file size limit on Linux
Or patch the kernel so it doesn't have the limit.
Patches for this are available; if you don't want to build your own kernel, get the Red Hat Linux Enterprise Edition, which has this patch by default.
I wonder how this is going to affect PostgerSQL and MySQL?
Probably in 2 ways - the good side: stealing^H^H^H^H^H^H^H^H sharing code.
The bad side: losing users (and possibly developers) to Interbase.
While I'm here, did Slashdot miss [Red Hat]'s GPL release of Source Navigator?
No, they just chose to ignore it. I've submitted the story.
why would the average user need to have their X windows session remotely available, have a webserver, NFS, FTP and X Windows font server?
;)
Almost all of them are turned off in a default install as of Red Hat Linux 6.2.
Yes, we have bugs, but we (at least try to) fix them.