Oops, I've been caught. Ok, time to tell the truth. I'm actually a shell script; a combination of wget, grep, cat FAQ and line 119: syntax error: unexpected end of file
Mostly the fact that 3.0.x -> 3.1 will break binary compatibility yet again, and will be out soon. Releasing a.0 release with gcc 3.0.x would mean having to do gcc 3.0.x throughout all.x releases, even after it's obsolete.
It's better to just skip 3.0.x and get a 3.1 or 3.2 based distribution out when it's ready.
You misunderstood me. This is a beta for *whatever the next release will be called* (look at the official announcement. We don't preannounce version numbers.)
It is. If you have the equipment, please give it a try. I've done the port of Kamera from the gphoto 2.0beta3 API to the gphoto 2.0final API, and I don't have the hardware to run any tests other than the Microsoftish "it compiles, therefore it works".
What about cdparanoia/lame and ogg bindings for the AudioCD IOSlave?
cdparanoia and ogg are built in, lame isn't because it's illegal (patent issues - if you want the support in, write to your government explaining why software patents are evil).
Support IPP (Internet Printing Protocol) -> autodetection of network printers
Support for PPD files -> better out-of-the-box support for many printers
Support for tray selection and other advanced features LPRng supports only through ugly hacks
Unified way for applications to get a list of available printers etc (libcups) - with lpr/LPRng, every application needs to write its own printcap parser
Actually most of the problems you're seeing don't have anything to do with the spooler you use - in fact, both LPRng and CUPS use ghostscript to talk to the printer [which actually does toe DPI and bi-directional things you're complaining about].
LPRng is hard to set up correctly (you apparently didn't), but once you did, it's not that bad.
Unless some miracle happens and KDE 3.0 is delayed by several weeks even though it works, the released version will have KDE 3.0 final.
A beta release doesn't mean we don't upgrade anything... It just (usually) means we won't do any major upgrades (if KDE 2.2.2 were in the beta, seeing 3.0 in the final would be extremely unlikely).
Knowing RedHat, I would expect them to put the development version [of gnome 2.0] in the final release
That's certainly not going to happen. We don't do major upgrades to an important part of the distribution after a beta, and if you compare any beta versions of RHL with their subsequent release version, you'll notice we never did.
I agree that CUPS is a better tool (that's why it was added in this release, and Qt, KDE and other applications have been compiled with libcups support), but LPRng isn't as bad as you make it sound.
One of the reasons to keep it for now is that it's more compatible with legacy systems, so someone upgrading from Solaris or HP/UX to Linux will find something familiar.
Nobody can foretell when this happens; chances are the current release plans will be delayed again or the 2.0 release will be as broken as some early 0.10 releases.
Also, since it totally breaks the API and most applications haven't been ported to the new API, staying with 1.x for a while has some additional reasons.
Not in the base OS. Webmin is a nice, user friendly tool, but it's code is horrible (at least to people who don't breathe perl instead of air;) ) and we usually don't ship stuff we can't support well.
Webmin is included on the almost-unsupported extra CD found in European boxes (bandwidth is very expensive in most European countries, so including another CD with stuff you could just download makes sense in the European box).
I can't reproduce this on any of our boxes, including 7.1, 7.2 and current beta installations.
A backtrace submitted to Bugzilla helps getting things fixed - how are we supposed to fix something we don't even know breaks for you? (Chances are this is a very weird local setup problem)
First of all, the article is bogus, we don't preannounce releases, the next release might be called 7.3, 8.0, 15.1, Linux XP or anything else.
Second, there's no strict rule on how many versions of a major release we do. The major number is determined by changes in binary compatibility, so it will usually be increased when switching to a major new glibc or a binary incompatible gcc.
Slashdot Mirror
Ok, the next release will be made as soon as the Microsoft loses its trademark in the MicrosoftLindows lawsuit, and it'll be called Windows LX.
But don't tell anyone, we don't want to spread the word and if you tell too many people, it might actually show up on slashdot.
Oops, I've been caught. Ok, time to tell the truth. I'm actually a shell script; a combination of wget, grep, cat FAQ and
line 119: syntax error: unexpected end of file
The kernel is 2.4.18+patches, so if 2.4.x started to work for you in 2.4.15, you should be ok.
We haven't had any problems with the 2.4.9 errata kernel for 7.2, though.
Mostly the fact that 3.0.x -> 3.1 will break binary compatibility yet again, and will be out soon. .0 release with gcc 3.0.x would mean having to do gcc 3.0.x throughout all .x releases, even after it's obsolete.
Releasing a
It's better to just skip 3.0.x and get a 3.1 or 3.2 based distribution out when it's ready.
You misunderstood me. This is a beta for *whatever the next release will be called* (look at the official announcement. We don't preannounce version numbers.)
Support for Cups?
Yes
Kamera support seems to be compiled in
It is. If you have the equipment, please give it a try.
I've done the port of Kamera from the gphoto 2.0beta3 API to the gphoto 2.0final API, and I don't have the hardware to run any tests other than the Microsoftish "it compiles, therefore it works".
What about cdparanoia/lame and ogg bindings for the
AudioCD IOSlave?
cdparanoia and ogg are built in, lame isn't because it's illegal (patent issues - if you want the support in, write to your government explaining why software patents are evil).
That's not compatible with the older versions, therefore the change will happen in the next .0 release.
Sure, the zlib stuff has been fixed in *whatever the release will be called*.
Simply use a virtual user table (/etc/postfix/virtual). The postfix README file tells you how to do it, but the layout of the file is simple:
@foo.net user@foo.com
Would send all mails to any address @foo.net to user@foo.com.
Yes. Off the top of my head:
Actually most of the problems you're seeing don't have anything to do with the spooler you use - in fact, both LPRng and CUPS use ghostscript to talk to the printer [which actually does toe DPI and bi-directional things you're complaining about].
LPRng is hard to set up correctly (you apparently didn't), but once you did, it's not that bad.
I agree that CUPS is better though.
The gcc3 packages are likely to return for the final, once a final decision on 3.0.4 vs 3.1 has been made.
Unless some miracle happens and KDE 3.0 is delayed by several weeks even though it works,
the released version will have KDE 3.0 final.
A beta release doesn't mean we don't upgrade anything... It just (usually) means we won't do any major upgrades (if KDE 2.2.2 were in the beta, seeing 3.0 in the final would be extremely unlikely).
Rawhide is the only truly e XP erimental release we make...
Try do that with Redhat
/pub/redhat/linux/beta/skipjack/en/ os/i386/
You need only one floppy to do a Red Hat ftp install. 8)
Get the image
here, boot it, and point the installer at ftp.redhat.com
Knowing RedHat, I would expect them to put the development version [of gnome 2.0] in the final release
That's certainly not going to happen. We don't do major upgrades to an important part of the distribution after a beta, and if you compare any beta versions of RHL with their subsequent release version, you'll notice we never did.
I agree that CUPS is a better tool (that's why it was added in this release, and Qt, KDE and other applications have been compiled with libcups support), but LPRng isn't as bad as you make it sound.
One of the reasons to keep it for now is that it's more compatible with legacy systems, so someone upgrading from Solaris or HP/UX to Linux will find something familiar.
Why didn't they wait until Gnome 2.0 is out?
Nobody can foretell when this happens; chances are the current release plans will be delayed again or the 2.0 release will be as broken as some early 0.10 releases.
Also, since it totally breaks the API and most applications haven't been ported to the new API, staying with 1.x for a while has some additional reasons.
What they should include instead is Webmin
;) ) and we usually don't ship stuff we can't support well.
Not in the base OS.
Webmin is a nice, user friendly tool, but it's code is horrible (at least to people who don't breathe perl instead of air
Webmin is included on the almost-unsupported extra CD found in European boxes (bandwidth is very expensive in most European countries, so including another CD with stuff you could just download makes sense in the European box).
It isn't.
It doesn't work the "Oh, we need to push a new release out of the door, let's call the current rawhide a beta!" way.
There is a QA cycle even for beta releases to make sure people who aren't asking for it (by using rawhide) aren't getting completely broken stuff.
Usually, X.X is a release, and X.X.XX is a beta.
The 4th and 5th CDs are source RPMs, so if you just want to give it a test run without looking at the code, you won't need them.
You boot in normal install mode and then select "Upgrade" when it prompts you for installation type.
The choice has been moved from the boot loader to the {T,G}UI.
I can't reproduce this on any of our boxes, including 7.1, 7.2 and current beta installations.
A backtrace submitted to Bugzilla helps getting things fixed - how are we supposed to fix something we don't even know breaks for you? (Chances are this is a very weird local setup problem)
First of all, the article is bogus, we don't preannounce releases, the next release might be called 7.3, 8.0, 15.1, Linux XP or anything else.
Second, there's no strict rule on how many versions of a major release we do.
The major number is determined by changes in binary compatibility, so it will usually be increased when switching to a major new glibc or a binary incompatible gcc.