Slashdot Mirror
RedHat 6.2 - RSN
It seems that Redhat 6.2 will be out Real Soon Now - the mirrors (at least at metalab) are starting to get it. The main Redhat FTP doesn't have it yet - but it should be there in the next few hours... I think that the beta idea was a really good one (and I know lots of problems have been fixed since the beta was out - look at the rawhide directory in their FTP server). I hope other Linux distributions will follow RedHat with a public beta test before releasing a new version. (Thanks Udi for the info).
Actually, someone from Redhat was on IRC and told me that they will release 6.2 RSN..
:)
And one of our members on Linux IL (Israel) User groups found it on metalab..
And - I'm a slashdot Author
Hetz (Heunique)
I noticed that Bero was posting a fair amount here, so I wondered if he, or anybody else, could answer a couple of quick questions.
When will Red Hat include a general-purpose security tool or hardening script? In particular, I'm thinking of Bastille Linux, which was designed specifically for RH6.0 and 6.1. And when I saw "include" I don't mean "stick it on the CD in between XEyes and an ancient version of GNUChess, I mean, actually making users aware of it and even incorporating it into a post-install stage. Around here, Linux has gotten a really bad reputation for security, becuase RH6 had a fair number of holes and admins didn't bother to plug them.
One of the biggest differences between a Linux distribution and a commercial Unix distribution is that most of the Unices ship with very, very, very little software (how the hell do they still take up so many CDs without a frickin' copy of bash?!?). However, this does put an extra responsibility on Linux companies to provide a centralized set of tools to remove, shut down, or otherwise patch included utilities that might be hazardous to the system.
Also, when is Red Hat going to make it easier and more foolproof to install necessary fixes? I think the priority FTP access is a nice start, and a good way to add value for your serious customers. But (and I haven't used Red Hat since 6.0, please correct me where I'm wrong) do you have a tool to automatically download secure updates when they become available? And are registered customers automatically notified by email of potential security holes or show-stopping bugs, along with steps to correct them? A lot of Linux systems don't have full-time administrators who can afford to read security sites every day, but that's the kind of service that we all want to pay a Linux distributor to do for us.
Thanks a lot, and I wish you guys well with 6.2!
--JRZ
GNU/Linux. The Freshmaker.
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
the people who are going to benefit from e16 are people who aren't running gnome. the way redhat ships pretty much relies on gnome or kde running, and someone who is concerned enough to customize what wm they are running and decides against running both gnome and kde is probably capable of getting an e16 rpm. one nice thing about this is that the e15 rpm can have good gnome/kde friendly settings and the e16 rpm can be setup for more of an enlightenment only install.
try to be more open minded about decisions that are made by linux distros, they really are less political than they seem at first glance
Don't be mean or my friend Oog will smash your head
1) zoot-i386.iso
2) RedHat 6.2
And check out my site, for my web-based Gnutella client, Phreedom.Net.
-Davidu
# Hack the planet, it's important.
zoot-doc.iso 594576 Kb Fri Mar 10 00:20:00 2000
zoot-i386.iso 656134 Kb Thu Mar 9 18:39:00 2000
zoot-sparc.iso 613072 Kb Thu Mar 9 18:42:00 2000
zoot-srpms.iso 580122 Kb Thu Mar 9 18:41:00 2000
And then I realized that minutes after I announce it it will be slashdotted and my download speed will drop.
Shall I be selfish?
sgc://qbjaybnq.fbheprsbetr.arg/cho/zveebef/erqu
----
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
There will be an announcement when 6.2 is actually released, not when mirrors are starting to download it and setting wrong permissions on the directories. ;)
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
I'm not trying to rain in the RedHat parade here or start a distro flamewar (trust me, I've seen enough already), but Debian - the non-profit Linux distribution has had public betas for each of their distributions for years now. It is under a development tree called "frozen" as opposed to the "stable" tree and the "unstable" tree (alpha testing).
However, Debian's testing periods, aka. freezes last for quarters on ends (the current freeze "Potato" has lasted for three months already, and I still haven't seen it about to end anytime soon) just to iron out nearly every bug as compared to other distrubutions. Just check out the update trees and see how short Debian's one is! Being a Debian user myself (and past RedHat user as well), I find it very frustrating that Debian takes forever to include new versions of packages, despite the advantages of the mature and proven.
But when one thinks about it, if anyone downloads the latest source code from each programmer that contributes to distros, then you'd have a distribution more cutting edge than any distro could provide you with. The only problem is that you risk cutting your hand off with a system filled with packages so new that they collide with each other due to inital teething. No one really has time for that, so let the distros do the packaging.
It's nice to see RedHat following Debian's innitiative of releasing public betas and publicising it too. I've always admired how cutting edge RedHat is when it comes to bundling new packages, but I've never really liked downloading 80MB worth of patches for every version of a distribution 6 months after the initial release. Let's hoped RedHat's upped the ante for the other commercial releases.
-- "I can't tell the future, I just work there." -- The Doctor
Subject says it all - don't judge a new version by what is on a mirror that's not done downloading (the fact that it's publically accessible while in this state is a bug).
/ iso.
Once they're finished downloading, the iso will be at
ftp://metalab. unc.edu/pub/Linux/distributions/redhat/redhat-6.2
Also, if you don't like it, let me know WHY (not that I'd agree). We're here to fix things.
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
"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).
This message is provided under the terms outlined at http://www.bero.org/terms.html
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).
This message is provided under the terms outlined at http://www.bero.org/terms.html
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...
This message is provided under the terms outlined at http://www.bero.org/terms.html