We wanted to include KDE 2.0 the last time around - unfortunately, its release schedule didn't go along well with ours. We can't include anything in a release that is released some weeks after we go gold, can we?
We're definitely glad we finally have a version of KDE that doesn't depend on a not-100%-free version of Qt, and especially one that works this well (posting this from Konqueror).
Sure you can make a few suggestions... However, I don't think we'll do anything for them:
xinetd: making the switch was the correct (and IMO overdue) choice, both for ease of use and for security (xinetd implements IP based access control), and for compatibility with the future (xinetd can do IPv6). Handling legacy inetd.conf files is a problem: If a service is described in both, which do you take? Also, inetd.conf has no way of providing information like permitted/rejected IPs.
If we never dared to change anything because of compatibility issues, we'd still be punching holes in cards for programming.
You can configure xinetd by hand (my favorite system configuration tool is and will always be vim) - its config files aren't more difficult to understand than inetd.conf. They're just more powerful.
This is very different from changing / to C:\ -
one was a big step forward, the other would make no sense at all and be a big step backwards.
wine: We're shipping it on Powertools.
Putting a lot of resources into wine wouldn't make much sense. First of all, there's two sides to wine. Of course it's nice that I can run a Windoze application on Linux if I need to (I'm doing my tax declarations with wine, for example), but if it runs too well, companies won't see a need to write native Linux applications ("But our Windows version works for you, why should we do anything else?").
Second, the desktop isn't our primary target, and there's no reason whatsoever to run wine on a server or embedded device.
gcc: This has been discussed to death many times. Go to http://www.bero.org/gcc296.html and let me know if this doesn't answer your questions.
What we do at "work": Coding, packaging and fixing bugs. Have you ever used the Linux kernel? glibc? gcc? KDE? GNOME? rpm? If you answered yes to any of those, you've used Red Hat code. (No, I'm not claiming we invented them or did all the work on them, but all of them contain a lot of code we wrote).
Since everything we do is released under the GPL or LGPL, many people aren't aware of the fact that they're using a lot of our code even if they aren't using Red Hat Linux. (Yes, the same goes for most other distributions to an extent.)
Our kernel is in no way proprietary. We're shipping the whole source and all of the patches.
We're not using 2.4.3 because it was released way too late. Porting patches and testing take some time.
Some of our fixes are in 2.4.3 (not all of them, simply because they were too late).
And yes, all of our fixes have been submitted to what you call the real kernel.
You can of course build your own kernel and it'll work - but we don't officially support anything that hasn't passed our QA.
It's up and running despite the 5515 accesses within the last 15 minutes (great stability test for 7.1, which is already running on the server). It's on a relatively slow line though (connectivity is terribly expensive around here, monopolists suck!), so you might be getting timeouts.
The FS corruption problems have been fixed. Tracking them down was rather difficult, that's why the release is this late after the beta.
We don't ship releases with known corruption problems.
This is a bug in the JVM, not in Red Hat Linux.
The JVM can't deal with some of glibc 2.2.2's new features, and since we don't have the source, there's nothing we can do about it (another reason not to use proprietary software unless absolutely necessary).
IIRC, it should work with the i386 version of glibc since (unlike the i686 version) it doesn't support floating stacks.
Red Hat does not ship proprietary software (with the sole exception of Netscape which was still needed until not too long ago; the last piece of proprietary **** will disappear in one of the next releases, when Konqueror and Mozilla can replace it completely), so we won't ever include PM unless they decide to opensource it, which is unlikely.
We think helping GNU parted to get ready is a much nicer way to address this problem.
Kernel: It's 2.4.2 with a lot of patches (mostly bugfixes, including one for a filesystem corruption bug).
RPM: It uses the same v4 package format 7.0 used. The packages won't work on ancient versions of rpm (3.0.x, x 5), which doesn't matter because at least AFAIK there's no distribution out there that uses rpm 3.0.x and glibc 2.2.x (which is needed anyway).
We're keeping kgcc for people who want to run 2.2.x kernels for whatever reason.
It's definitely not needed for 2.4.x kernels - our kernel has passed all stress tests without causing filesystem corruption, crashing, or otherwise acting up oddly.
Also, gcc 2.96 has stabilized a lot between 7.0 and 7.1. (not that the 7.0 version was as bad as some people claim it was).
I've just downloaded this thingy - since we're constantly running out of space on our CDs, I thought of lzip-compressing the emacs packages to save space (come on, any change to emacs including an exit(1); right after main() { makes this thing better;) )
Unfortunately, it doesn't work as expected.
I've hacked up a quick fix based on the same lossy algorithm. It's not quite as advanced as lzip (it's just kind of a preprocessor for gzip and bzip2), but it's quite efficient nevertheless...
It's shell code for now, if I have the time I'll optimize it by rewriting it in C.
#!/bin/sh
# lzip preprocessor
# (c) 2001 Red Hat, Inc.
#
# Released under the FO2L license, see
# lzip.sourceforge.net for details
#
if [ -z "$1" -o -n "$2" ]; then
echo "Usage: lzip filename"
exit 1
fi
dd if=/dev/zero of=$1 bs=1 \
count=`stat $1 |head -n2 |tail -n1 \
|cut -d" " -f4
echo "Preprocessing done. You can now gzip or bzip2 the file $1."
Essentially as the linux market matures the
best Red Hat employees will do better for themselves
by setting up their own consulting companies than
working for Red Hat.
Umm, not really. I don't know if I can be considered one of Red Hat's best employees, but I'm sure some of them think about this just the way I do.
Yes, I could probably make more money by setting up my own linux consulting company, but money isn't everything.
I think I'm doing much better for myself when I'm doing what I like to do (hacking on open source code) than getting more money by setting up systems and possibly having to take care of financial matters.
If I'm ever fired, I'll probably do just that - but I'd much rather stay with Red Hat where I can do fun stuff almost all the time.
Re:And the debian packages have font-Antialiasing!
on
KDE 2.1 Is Out
·
· Score: 2
Same for the Red Hat packages, by the way - we're using a patched Qt 2.2.4.
Re:Optimizing the source build
on
KDE 2.1 Is Out
·
· Score: 2
This isn't true. Any reasonably modern version of gcc (such as 2.96) can handle -mpentiumpro, -march=i686 and the likes.
Why? Having several options for graphical toolkits really can't hurt as long as I can run gnome stuff in KDE and vice versa.
I can see why people would prefer Qt (I do), but I can also see why people who have never done C++ would prefer gtk rather than learning a "new language" - why not give people both (or even more) options?
Slashdot Mirror
We wanted to include KDE 2.0 the last time around - unfortunately, its release schedule didn't go along well with ours. We can't include anything in a release that is released some weeks after we go gold, can we?
We're definitely glad we finally have a version of KDE that doesn't depend on a not-100%-free version of Qt, and especially one that works this well (posting this from Konqueror).
If we never dared to change anything because of compatibility issues, we'd still be punching holes in cards for programming.
You can configure xinetd by hand (my favorite system configuration tool is and will always be vim) - its config files aren't more difficult to understand than inetd.conf. They're just more powerful.
This is very different from changing / to C:\ -
one was a big step forward, the other would make no sense at all and be a big step backwards.
Putting a lot of resources into wine wouldn't make much sense. First of all, there's two sides to wine. Of course it's nice that I can run a Windoze application on Linux if I need to (I'm doing my tax declarations with wine, for example), but if it runs too well, companies won't see a need to write native Linux applications ("But our Windows version works for you, why should we do anything else?").
Second, the desktop isn't our primary target, and there's no reason whatsoever to run wine on a server or embedded device.
Since everything we do is released under the GPL or LGPL, many people aren't aware of the fact that they're using a lot of our code even if they aren't using Red Hat Linux. (Yes, the same goes for most other distributions to an extent.)
Our kernel is in no way proprietary. We're shipping the whole source and all of the patches.
We're not using 2.4.3 because it was released way too late. Porting patches and testing take some time.
Some of our fixes are in 2.4.3 (not all of them, simply because they were too late).
And yes, all of our fixes have been submitted to what you call the real kernel.
You can of course build your own kernel and it'll work - but we don't officially support anything that hasn't passed our QA.
Not yet - ext3 hasn't been ported to kernel 2.4 yet and reiserfs still hasn't stabilized enough.
This (actually both of these points) will almost certainly change in the next release.
It's up and running despite the 5515 accesses within the last 15 minutes (great stability test for 7.1, which is already running on the server). It's on a relatively slow line though (connectivity is terribly expensive around here, monopolists suck!), so you might be getting timeouts.
It's not in there, simply because it hasn't been ported to kernel 2.4 yet. The current version for 2.2.x kernels is stable though.
It'll almost certainly be in the next version.
I'm a developer, not a product manager...
But I can tell you that the sparc build machines are still in the build system, so even if there isn't an official product, you can get rawhide.
I don't have a sparc and I'm not in an office with many test machines, so I can't tell you how well it works.
The FS corruption problems have been fixed. Tracking them down was rather difficult, that's why the release is this late after the beta.
We don't ship releases with known corruption problems.
We aren't shipping it, but we've fixed up and extended up2date to provide pretty much the same functionality (and yes, it works in text mode).
This is a bug in the JVM, not in Red Hat Linux.
The JVM can't deal with some of glibc 2.2.2's new features, and since we don't have the source, there's nothing we can do about it (another reason not to use proprietary software unless absolutely necessary).
IIRC, it should work with the i386 version of glibc since (unlike the i686 version) it doesn't support floating stacks.
Check the release notes for details.
Darn, we forgot.
;)
It'll probably take us years to catch up with the only os that has to be really stable since it already reached version 2000.0.
I'm going to quit my job, we obviously can't get anywhere since we're that far behind.
You *can* install it. If you want to use a stoneage compiler with tons of known issues, that's your choice.
You don't need to, though.
Red Hat does not ship proprietary software (with the sole exception of Netscape which was still needed until not too long ago; the last piece of proprietary **** will disappear in one of the next releases, when Konqueror and Mozilla can replace it completely), so we won't ever include PM unless they decide to opensource it, which is unlikely.
We think helping GNU parted to get ready is a much nicer way to address this problem.
From the kernel's make {menu,x,}config USB section:
Audio devices
Bluetooth devices
Storage devices
Modems
Printers
Keyboards, Mice, Joysticks
DAB (Digital Audio Broadcasting)
Network devices
USB-Parport
USB-Serial converter
various USB scanners and cameras
MP3 players
Kernel: It's 2.4.2 with a lot of patches (mostly bugfixes, including one for a filesystem corruption bug).
RPM: It uses the same v4 package format 7.0 used. The packages won't work on ancient versions of rpm (3.0.x, x 5), which doesn't matter because at least AFAIK there's no distribution out there that uses rpm 3.0.x and glibc 2.2.x (which is needed anyway).
We don't introduce any features after the beta cycle. Untested features don't help anyone.
We're keeping kgcc for people who want to run 2.2.x kernels for whatever reason.
It's definitely not needed for 2.4.x kernels - our kernel has passed all stress tests without causing filesystem corruption, crashing, or otherwise acting up oddly.
Also, gcc 2.96 has stabilized a lot between 7.0 and 7.1. (not that the 7.0 version was as bad as some people claim it was).
Sure. See http://www.bero.org/gcc296.html
Since we're using kernel 2.4.2 (with many fixes), you won't need kgcc anymore unless you're planning on downgrading the kernel.
The need for kgcc was caused by bugs in 2.2.x kernels, preventing it from compiling with compilers that do the right thing(tm).
I've just downloaded this thingy - since we're constantly running out of space on our CDs, I thought of lzip-compressing the emacs packages to save space (come on, any change to emacs including an exit(1); right after main() { makes this thing better ;) )
Unfortunately, it doesn't work as expected.
I've hacked up a quick fix based on the same lossy algorithm. It's not quite as advanced as lzip (it's just kind of a preprocessor for gzip and bzip2), but it's quite efficient nevertheless...
It's shell code for now, if I have the time I'll optimize it by rewriting it in C.
#!/bin/sh
# lzip preprocessor
# (c) 2001 Red Hat, Inc.
#
# Released under the FO2L license, see
# lzip.sourceforge.net for details
#
if [ -z "$1" -o -n "$2" ]; then
echo "Usage: lzip filename"
exit 1
fi
dd if=/dev/zero of=$1 bs=1 \
count=`stat $1 |head -n2 |tail -n1 \
|cut -d" " -f4
echo "Preprocessing done. You can now gzip or bzip2 the file $1."
Essentially as the linux market matures the
best Red Hat employees will do better for themselves
by setting up their own consulting companies than
working for Red Hat.
Umm, not really. I don't know if I can be considered one of Red Hat's best employees, but I'm sure some of them think about this just the way I do.
Yes, I could probably make more money by setting up my own linux consulting company, but money isn't everything.
I think I'm doing much better for myself when I'm doing what I like to do (hacking on open source code) than getting more money by setting up systems and possibly having to take care of financial matters.
If I'm ever fired, I'll probably do just that - but I'd much rather stay with Red Hat where I can do fun stuff almost all the time.
Same for the Red Hat packages, by the way - we're using a patched Qt 2.2.4.
This isn't true. Any reasonably modern version of gcc (such as 2.96) can handle -mpentiumpro, -march=i686 and the likes.
Why? Having several options for graphical toolkits really can't hurt as long as I can run gnome stuff in KDE and vice versa.
I can see why people would prefer Qt (I do), but I can also see why people who have never done C++ would prefer gtk rather than learning a "new language" - why not give people both (or even more) options?
The command line space's working directory would be whatever the current working directory in the file manager is
KDE has this - open konqueror, then select "Show Terminal Emulator" from the Window menu.