The patent would have expired in a few weeks anyway...
And it's not like they would lose any business these weeks - they still sell their software, and not many would buy an RSA-specific license knowing it expires soon anyway.
They try to get some goodwill out of it, but when looking into it, they're not giving much.
We are not moving away from python - if anything, we're writing more and more tools in python and converting old ones.
Python is the language used in the installer and in lots of small tools...
What is probably going to go away is tcl - ugh.
In my RedHat inetd.conf, there are a whole lot of things open that I've never even heard of, but of which I don't know what will happen when I switch them off. And the daemons... well, don't speak about the things RedHat 6.0 launches;-)
Red Hat Linux doesn't include inetd by default for workstation installs, and hasn't for a couple of releases - I think 6.1 may be the release this was changed.
This attitude needs changing.
Okay. Calling DPKG a security problem because it doesn't allow package signing? I'll grant that's kind of valid.. but how many signed packages are their in any other linux distribution? I don't believe I've ever seen even a single one! (in other words.. who cares if RPM can do this if nobody uses it).
We always sign the packages shipped in Red Hat's packages and our updates.
Crypt passwords (instead of md5) by default. HELLO.. the screen ASKS you what you want to use, and just happens to have 'crypt' already selected.
Not a big problem, IMHO - as you write, just choose MD5. However, there shouldn't be problems doing that - Red Hat has used pam for years with MD5 support (and for quite some time used as default), so problems should be long gone.
And they *are* right.
Oh wait.. you could always just INSTALL RPM!
Red Hat's versioning is based on binary compatibility (well, at least it has been for some time - 3.0.3 could just as well have been 2.2) - with a new toolchain (glibc, compilers etc) the version number goes up.
Of course, it would have been nice if the 2.4 kernel had made it as well...
As for Slackware, they just increased their number to match the competitors
Mandrake used to be Red Hat+0.1, but went to 7 when they wrote their own installer instead of just copying the Red Hat one.
Not only AMD - before I started working here, I did High Performance Computing. In my own benchmarks, egcs-1.1.2 and gcc 2.95.x (I don't remember which x, but I don't think it matters) code compiled for pentium usually slowed down (-O3/6 with and without march={pentium,pentiumpro}) for pentium, pII and Celeron. Just a few percent, but definitely no increase.
I would be very interested in some feedback in how the current optimizations affect K6-2, though.
Mozilla is PowerTools (not main distro), 2.2 will be the supported kernel, XFree86 works OK for some cards - and we also ship and use XFree 3.3.6 servers for cars we don't know for sure will work with XFree 4. KDE will probably be reverted, though.
We are aiming for better binaries - more ones, less zeros.
Seriously speaking, we compile with optimizations for pentiumpro but no architecture specific commands (selected packages excepted, like glibc and the kernel). And since we use a compiler with a new x86 backend, we should actually see some performance gain - previously, "optimizing for pentium" with gcc was just a gimmick.
We have a new glibc, compilers, GNOME and XFree. We even have a preview of the Inti foundation libraries. Other goodies are FHS compliance, xinetd, LPRng and rpm 4.0 When it comes to problems wrt. releasing fixes for 2.2.14, one major issue was that the 2.2.16 was rather buggy (look at the start of the 2.2.17pre patches to understand just how buggy it was...) - we needed something more solid before we could ship it.
Surely, you are thinking of Corel, not Caldera. And that is basically Debian with a better installation and a customized KDE-derivative. As I mentioned, RPM is also the packager used in LSB. As for rpm not having the functionality of deb - not the case. The functionality of apt and up2date are not that dependent on the underlying package formats.
RPM is the standard package system - used by everybody but Slackware (doesn't really have a system) and Debian (deb) (OK - not everybody, but at least the major ones: Red Hat, SuSE, Turbo and Caldera and derivatives (like Mandrake)).
The problem with compatibility is not package formats, but libraries, file locations etc - binary compatibility is much better than what it used to be, thanks to glibc, but is still in need of improvement.
Very little of the memory used by netscape is used by the binary - it is mostly data, pixmaps etc. Trust me, running netscape on a shared server is a bad idea. Environments I've been working in typically allows you to run most programs but netscape on the server - memory is one issue, CPU is another (netscape doesn't always die when you want it to) - and confining netscape to the desktops is by far the safest way. Also, animated gifs (I hate them, but they are present) can present a strain on the network.
I believe this would be a bad idea - 64 MB should be installed as it allows more applications to be run locally (you do not want people running netscape on a server - it is too memory hungry, and falls over a lot, consuming all the CPU it gets), the X server consumes a lot of memory anyway and you have some memory for caching.
You pay for support, and of course there is a markup for developing the software: Paying people isn't free. You get the source and it is GPLed, but that doesn't means it's free as in "no cost" - you can share it, of course, but there is a price tag on the edition Red Hat believes businesses would want to buy.
Slashdot Mirror
How about people not commenting on it until they actually know something about it, except rumours? That would make a nice change...
The patent would have expired in a few weeks anyway...
And it's not like they would lose any business these weeks - they still sell their software, and not many would buy an RSA-specific license knowing it expires soon anyway.
They try to get some goodwill out of it, but when looking into it, they're not giving much.
We are not moving away from python - if anything, we're writing more and more tools in python and converting old ones. Python is the language used in the installer and in lots of small tools... What is probably going to go away is tcl - ugh.
In my RedHat inetd.conf, there are a whole lot of things open that I've never even heard of, but of which I don't know what will happen when I switch them off. And the daemons... well, don't speak about the things RedHat 6.0 launches ;-)
Red Hat Linux doesn't include inetd by default for workstation installs, and hasn't for a couple of releases - I think 6.1 may be the release this was changed.
This attitude needs changing.
Okay. Calling DPKG a security problem because it doesn't allow package signing? I'll grant that's kind of valid.. but how many signed packages are their in any other linux distribution? I don't believe I've ever seen even a single one! (in other words.. who cares if RPM can do this if nobody uses it).
We always sign the packages shipped in Red Hat's packages and our updates.
Crypt passwords (instead of md5) by default. HELLO.. the screen ASKS you what you want to use, and just happens to have 'crypt' already selected.
Not a big problem, IMHO - as you write, just choose MD5. However, there shouldn't be problems doing that - Red Hat has used pam for years with MD5 support (and for quite some time used as default), so problems should be long gone. And they *are* right. Oh wait.. you could always just INSTALL RPM!
You can find lots of linux hardware here - preconfigured with Linux and with support
There is Linux links on the sidebar in the biz sections, but not in the consumer section.
Red Hat's versioning is based on binary compatibility (well, at least it has been for some time - 3.0.3 could just as well have been 2.2) - with a new toolchain (glibc, compilers etc) the version number goes up.
Of course, it would have been nice if the 2.4 kernel had made it as well...
As for Slackware, they just increased their number to match the competitors
Mandrake used to be Red Hat+0.1, but went to 7 when they wrote their own installer instead of just copying the Red Hat one.
netscape w/128 bit encryption and gnupg are already included in Red Hat Linux 6.2 as these don't have issues with the RSA patent
What about E 16.4, will Redhat bother to update that?
Enlightement 0.16.4 is included, but is no longer the default wm - the default wm is now sawfish.
what about gnome 1.2?
GNOME 1.2 is included.
Not only AMD - before I started working here, I did High Performance Computing. In my own benchmarks, egcs-1.1.2 and gcc 2.95.x (I don't remember which x, but I don't think it matters) code compiled for pentium usually slowed down (-O3/6 with and without march={pentium,pentiumpro}) for pentium, pII and Celeron. Just a few percent, but definitely no increase.
I would be very interested in some feedback in how the current optimizations affect K6-2, though.
Yes, it should.
Mozilla is PowerTools (not main distro), 2.2 will be the supported kernel, XFree86 works OK for some cards - and we also ship and use XFree 3.3.6 servers for cars we don't know for sure will work with XFree 4. KDE will probably be reverted, though.
We are aiming for better binaries - more ones, less zeros.
Seriously speaking, we compile with optimizations for pentiumpro but no architecture specific commands (selected packages excepted, like glibc and the kernel). And since we use a compiler with a new x86 backend, we should actually see some performance gain - previously, "optimizing for pentium" with gcc was just a gimmick.
We have a new glibc, compilers, GNOME and XFree. We even have a preview of the Inti foundation libraries. Other goodies are FHS compliance, xinetd, LPRng and rpm 4.0 When it comes to problems wrt. releasing fixes for 2.2.14, one major issue was that the 2.2.16 was rather buggy (look at the start of the 2.2.17pre patches to understand just how buggy it was...) - we needed something more solid before we could ship it.
Yes, the main distribution is now on 2 CDs.
Surely, you are thinking of Corel, not Caldera. And that is basically Debian with a better installation and a customized KDE-derivative. As I mentioned, RPM is also the packager used in LSB. As for rpm not having the functionality of deb - not the case. The functionality of apt and up2date are not that dependent on the underlying package formats.
It would have worked after reinstalling Windows, since that would probably take a couple of hours... ;)
RPM is also the system specified in the current LSB draft
The problem with compatibility is not package formats, but libraries, file locations etc - binary compatibility is much better than what it used to be, thanks to glibc, but is still in need of improvement.
Very little of the memory used by netscape is used by the binary - it is mostly data, pixmaps etc. Trust me, running netscape on a shared server is a bad idea. Environments I've been working in typically allows you to run most programs but netscape on the server - memory is one issue, CPU is another (netscape doesn't always die when you want it to) - and confining netscape to the desktops is by far the safest way. Also, animated gifs (I hate them, but they are present) can present a strain on the network.
I've used it quite a few times, with good results. Note that I made my own kickstart files instead of creating one from an installed workstation.
I believe this would be a bad idea - 64 MB should be installed as it allows more applications to be run locally (you do not want people running netscape on a server - it is too memory hungry, and falls over a lot, consuming all the CPU it gets), the X server consumes a lot of memory anyway and you have some memory for caching.
You pay for support, and of course there is a markup for developing the software: Paying people isn't free. You get the source and it is GPLed, but that doesn't means it's free as in "no cost" - you can share it, of course, but there is a price tag on the edition Red Hat believes businesses would want to buy.
Red Hat also makes PowerTools available, i.e. not just the basic system.