Re:Does this include ftpd,httpd(apache),samba etc
on
RedHat 6.2 - RSN
·
· Score: 2
That's exactly what we're doing in 6.2.
Re:follow redhats public beta testing??
on
RedHat 6.2 - RSN
·
· Score: 1
It's Sunday and it's 10:30 pm - I may be fanatic (yes, yes, I even admit I have a "vi admin.cc" task running on another tty), but not even I work 24 hours a day, 7 hours a week.
6.2 already comes with much more secure default settings - nearly all deamons default to off now, and standard workstation installs don't install the servers. For security updates, there's up2date, which basically automates downloading of updates.
Security packages have always been a problem because of the US export restrictions (Doesn't bastille linux require SSH?); we've started fixing that with 6.2.
Did you actually see 6.1 or 6.2? We have up2date, which does pretty much the same as MandrakeUpdate. And you can always download the full 6.2 (as well as individual packages from it) from our ftp server or one of the mirrors. The Updates we're selling are primarily for people who either need support (every Red Hat Linux package includes support) and for people who can't download (In some countries, downloading 640 MB is way more expensive than buying a Red Hat Linux package. In some countries, net access is not very common.)
As I've pointed out before, XFree86 4.0 is not even near ready for being in a main release (SuSE 6.4 [to be released soon] still uses 3.3.6, as well); a RedHatUpdate program is included (and has been updated to fix most of the problems the version included in 6.1 had), and we can't ship a DVD player while DeCSS is illegal.
Re:Explanations...(Some packages are really outdat
on
RedHat 6.2 - RSN
·
· Score: 3
Deprecated doesn't mean removed; it's just a recommendation not to use it anymore and a warning that it might disappear or be replaced in a future version.
Re:features..?/Already in Mandrake since 6.1!
on
RedHat 6.2 - RSN
·
· Score: 1
Not surprising (not most of them, by the way, just some), considering I made them in both distribs.;)
Both of these bugs are specific to the beta and can be fixed by updating to the release (or at least some packages from the release). The KDE problem is caused by an incomplete patch in the kdebase RPM, so you'll want to update that one.
Re:follow redhats public beta testing??
on
RedHat 6.2 - RSN
·
· Score: 2
Actually we're releasing both betas (6.2-beta) and the development tree (rawhide), so unless I'm missing something, there's no need to follow anyone on this.
Definitely - Kernel 2.3.99 is already in the tree that will become rawhide as soon as someone updates the ftp servers.
Re:Why not delay this some more?
on
RedHat 6.2 - RSN
·
· Score: 5
That all will be in 7.0; check rawhide once the current version has been pushed on the ftp servers.
It's impossible to adapt to these changes that quickly without releasing a totally buggy distribution.
We're almost ready for Kernel 2.4 (2.3.99 is in the tree that will soon be rawhide), but I'd rather not expect 2.4.0 to be the most stable release we've seen, waiting for 2.4.5 or something before releasing a distribution that has to be 100% stable probably makes sense; XFree86 will definitely take a while because it needs fixing up (works ok on x86, but not on anything else), Xconfigurator and the X configuration part of the installer need to be almost rewritten,...
By the time XFree86 4.0 has been patched enough to actually do something useful and kernel 2.4 has stabilized, it's time for the next Red Hat Linux release anyway...
Re:did raster piss you off that bad ?
on
RedHat 6.2 - RSN
·
· Score: 5
It's not a lame excuse. I'm a developer, not a marketeer. The general idea is to include the version that makes most sense.
In our default setup, enlightenment is used only when GNOME is running. e 16 does not have many new features that make sense in that environment, but it is a lot bigger, so it makes this environment slower on low-memory machines.
Including the Qt beta makes sense because almost nothing uses Qt 2.0, but some interesting stuff uses Qt 2.1 (which is compatible with everything 2.0 did).
If this were for political reasons, 'rm -f enlightenment*; sed -e "s,enlightenment,sawmill,g" $CONFIG_FILES' would be a much more consistent decision (so that would be what we would have done).
Re:Other distros *do* produce betas/Mandrake first
on
RedHat 6.2 - RSN
·
· Score: 3
There have been other reasons than payment (some technical stuff, too early releases, and some more stuff). Introducing new features often also introduces new bugs; if it had been my decision, the releases would definitely have had more testing.
Red Hat does NOT consider itself as the only Linux distribution. I know as well as anyone else that Linux is 99% made from community work, but Mandrake taking ideas from RH is not a joke at all (and there's nothing wrong with that; anything that works both ways is good); check most spec files to see what's going on.
Explanations...(Some packages are really outdated)
on
RedHat 6.2 - RSN
·
· Score: 5
Outdated packages: In 6.x releases, one of the primary goals is to remain fully compatible with prior 6.x releases, therefore we usually won't update libraries with API and ABI changes, such as current readline, slang or tcl/tk. Stuff that was built for 6.0 or 6.1 must be able to run on 6.2 without having to recompile, which is not possible with a change like readline 2.2.1->4.0. The current versions are all in our internal development tree (which will become rawhide on Tuesday). SVGALIB Deprecated because it causes a lot of problems on some systems (try switching terminals from X to SVGALIB and vice versa on a Matrox G200 card, for example). DOSEMU We needed more space on the main CD for more important packages, so we moved some not-so-important packages like dosemu to powertools. This doesn't mean they aren't available or supported through bugzilla. Versioning scheme lynx-2.8.3-2 means it's the second version of a Red Hat Linux RPM containing a 2.8.3 release of lynx. The -2 indicates changes to the.spec file used to build the RPMs. Other packages Diskspace issue; some of the packages you mentioned are in powertools, I'll check whether it makes sense to add the others to powertools as well.
Re:Other distros *do* produce betas/Mandrake first
on
RedHat 6.2 - RSN
·
· Score: 2
Wrong, by the way - Raw Hide has been around longer than the Mandrake distribution.
Yes, we are taking ideas from Mandrake - after all, they're taking ideas from us, as well. There's nothing wrong with that...
And why would you call us arrogant? If we were, would our people be caught posting on slashdot?
"Thanks" to the RSA patent, we can't ship SSH or OpenSSL (which is required by OpenSSH). We are building RPMs for it at Red Hat Germany (where there is no RSA patent) though; they can be downloaded at ftp://ftp.redhat.de/pub/rh-addons/s ecurity/6.2.
We will include them as soon as the RSA patent expires (later this year).
It's primarily a gnome integration thing. 0.16 introduces some features that are simply doubling functionality that's already provided by gnome; in our default configuration, it doesn't add much aside from stuff that would be turned off and a larger memory footprint.
With sawmill probably becoming the default window manager for gnome, we'll probably update enlightenment for the next version.
It was the latest beta at the time the CDs went into production. And the big difference is that Qt 2.1.0 is a beta, but very stable, and XFree86 4 is called a release but it won't be anywhere near ready for quite a while.
Including Qt 2.0 wouldn't make much sense because close to nothing uses it [and the few apps that do can deal with 2.1]. Qt 2.1 can be used to run the KDE 2 betas, including interesting stuff like KOffice, so including the beta here definitely makes sense.
XFree86 4.0 didn't make it because it isn't ready for prime time. I've posted some reasons (and an RPM download location) on a different thread here; check this.
It won't be delayed as long as it was in 6.1. The big problem with alphas is that their binaries are huge - most of the time it's a problem getting everything to fit on a CD.
We're not including XFree86 4.0 because it's not ready. It doesn't compile at all on sparc (we're currently working on fixing this), doesn't compile out of the box on alpha (we've already fixed that), doesn't have all the drivers 3.3.x used to have (fixing that is a LOT of work), it doesn't have a working configuration tool yet (XFree86 -configure is a start, but it won't let you configure international keyboards and such), and there are a bit too many bugs for a stable release even in the drivers that are there.
Slashdot Mirror
That's exactly what we're doing in 6.2.
It's Sunday and it's 10:30 pm - I may be fanatic (yes, yes, I even admit I have a "vi admin.cc" task running on another tty), but not even I work 24 hours a day, 7 hours a week.
jdk is not free, and not even freely redistributable; in short we can't include it because of its restrictive license.
We're working on some alternatives though.
6.2 already comes with much more secure default settings - nearly all deamons default to off now, and standard workstation installs don't install the servers.
For security updates, there's up2date, which basically automates downloading of updates.
Security packages have always been a problem because of the US export restrictions (Doesn't bastille linux require SSH?); we've started fixing that with 6.2.
Did you actually see 6.1 or 6.2?
We have up2date, which does pretty much the same as MandrakeUpdate.
And you can always download the full 6.2 (as well as individual packages from it) from our ftp server or one of the mirrors.
The Updates we're selling are primarily for people who either need support (every Red Hat Linux package includes support) and for people who can't download (In some countries, downloading 640 MB is way more expensive than buying a Red Hat Linux package. In some countries, net access is not very common.)
As I've pointed out before, XFree86 4.0 is not even near ready for being in a main release (SuSE 6.4 [to be released soon] still uses 3.3.6, as well); a RedHatUpdate program is included (and has been updated to fix most of the problems the version included in 6.1 had), and we can't ship a DVD player while DeCSS is illegal.
Deprecated doesn't mean removed; it's just a recommendation not to use it anymore and a warning that it might disappear or be replaced in a future version.
Not surprising (not most of them, by the way, just some), considering I made them in both distribs. ;)
Both of these bugs are specific to the beta and can be fixed by updating to the release (or at least some packages from the release).
The KDE problem is caused by an incomplete patch in the kdebase RPM, so you'll want to update that one.
Actually we're releasing both betas (6.2-beta) and the development tree (rawhide), so unless I'm missing something, there's no need to follow anyone on this.
2.2.15 as in 6.2 beta == 2.2.15pre-something + patches.
2.2.14 as in 6.2 final == 2.2.14 + some but not all patches from 2.2.15pre + patches - 2.2.15 was not released in time.
Definitely - Kernel 2.3.99 is already in the tree that will become rawhide as soon as someone updates the ftp servers.
That all will be in 7.0; check rawhide once the current version has been pushed on the ftp servers.
...
It's impossible to adapt to these changes that quickly without releasing a totally buggy distribution.
We're almost ready for Kernel 2.4 (2.3.99 is in the tree that will soon be rawhide), but I'd rather not expect 2.4.0 to be the most stable release we've seen, waiting for 2.4.5 or something before releasing a distribution that has to be 100% stable probably makes sense; XFree86 will definitely take a while because it needs fixing up (works ok on x86, but not on anything else), Xconfigurator and the X configuration part of the installer need to be almost rewritten,
By the time XFree86 4.0 has been patched enough to actually do something useful and kernel 2.4 has stabilized, it's time for the next Red Hat Linux release anyway...
It's not a lame excuse. I'm a developer, not a marketeer. The general idea is to include the version that makes most sense.
In our default setup, enlightenment is used only when GNOME is running. e 16 does not have many new features that make sense in that environment, but it is a lot bigger, so it makes this environment slower on low-memory machines.
Including the Qt beta makes sense because almost nothing uses Qt 2.0, but some interesting stuff uses Qt 2.1 (which is compatible with everything 2.0 did).
If this were for political reasons, 'rm -f enlightenment*; sed -e "s,enlightenment,sawmill,g" $CONFIG_FILES' would be a much more consistent decision (so that would be what we would have done).
There have been other reasons than payment (some technical stuff, too early releases, and some more stuff). Introducing new features often also introduces new bugs; if it had been my decision, the releases would definitely have had more testing.
Red Hat does NOT consider itself as the only Linux distribution.
I know as well as anyone else that Linux is 99% made from community work, but Mandrake taking ideas from RH is not a joke at all (and there's nothing wrong with that; anything that works both ways is good); check most spec files to see what's going on.
Outdated packages: .spec file used to build the RPMs.
In 6.x releases, one of the primary goals is to remain fully compatible with prior 6.x releases, therefore we usually won't update libraries with API and ABI changes, such as current readline, slang or tcl/tk.
Stuff that was built for 6.0 or 6.1 must be able to run on 6.2 without having to recompile, which is not possible with a change like readline 2.2.1->4.0.
The current versions are all in our internal development tree (which will become rawhide on Tuesday).
SVGALIB
Deprecated because it causes a lot of problems on some systems (try switching terminals from X to SVGALIB and vice versa on a Matrox G200 card, for example).
DOSEMU
We needed more space on the main CD for more important packages, so we moved some not-so-important packages like dosemu to powertools. This doesn't mean they aren't available or supported through bugzilla.
Versioning scheme
lynx-2.8.3-2 means it's the second version of a Red Hat Linux RPM containing a 2.8.3 release of lynx.
The -2 indicates changes to the
Other packages
Diskspace issue; some of the packages you mentioned are in powertools, I'll check whether it makes sense to add the others to powertools as well.
Wrong, by the way - Raw Hide has been around longer than the Mandrake distribution.
Yes, we are taking ideas from Mandrake - after all, they're taking ideas from us, as well. There's nothing wrong with that...
And why would you call us arrogant? If we were, would our people be caught posting on slashdot?
"Thanks" to the RSA patent, we can't ship SSH or OpenSSL (which is required by OpenSSH).
We are building RPMs for it at Red Hat Germany (where there is no RSA patent) though; they can be downloaded at
ftp://ftp.redhat.de/pub/rh-addons/s ecurity/6.2.
We will include them as soon as the RSA patent expires (later this year).
It's primarily a gnome integration thing.
0.16 introduces some features that are simply doubling functionality that's already provided by gnome; in our default configuration, it doesn't add much aside from stuff that would be turned off and a larger memory footprint.
With sawmill probably becoming the default window manager for gnome, we'll probably update enlightenment for the next version.
It was the latest beta at the time the CDs went into production.
And the big difference is that Qt 2.1.0 is a beta, but very stable, and XFree86 4 is called a release but it won't be anywhere near ready for quite a while.
Including Qt 2.0 wouldn't make much sense because close to nothing uses it [and the few apps that do can deal with 2.1]. Qt 2.1 can be used to run the KDE 2 betas, including interesting stuff like KOffice, so including the beta here definitely makes sense.
piglet is the beta. You don't want to get that.
XFree86 4.0 is not ready for prime time.
If you want RPMs nevertheless, get them
here.
XFree86 4.0 didn't make it because it isn't ready for prime time.
I've posted some reasons (and an RPM download location) on a different thread here; check
this.
It won't be delayed as long as it was in 6.1.
The big problem with alphas is that their binaries are huge - most of the time it's a problem getting everything to fit on a CD.
We're not including XFree86 4.0 because it's not ready.
It doesn't compile at all on sparc (we're currently working on fixing this), doesn't compile out of the box on alpha (we've already fixed that), doesn't have all the drivers 3.3.x used to have (fixing that is a LOT of work), it doesn't have a working configuration tool yet (XFree86 -configure is a start, but it won't let you configure international keyboards and such), and there are a bit too many bugs for a stable release even in the drivers that are there.
In short, it's not even ready for Raw Hide.
I have put up RPMs at
http://people.redhat.com/bero/experimen tal though, for those who have x86es and don't like waiting.