I think it's not so much about backwards compatibility, and not as much "x86-64 is good" as "ia64 sucks".
I'm all but a fan of x86, but ia64 beats it at sucking, and x86-64 is at least a bit better.
Not really...
on
Is RPM Doomed?
·
· Score: 5, Insightful
While the article raises a couple of valid points (such as the crazy incompatibilities between some versions of rpm, a lack of standard package file names and standard locations), its conclusions are wrong.
Let's see:
1. An RPM-based distribution is risky to upgrade
Not quite. Red Hat, for example, still supports upgrading from Red Hat Linux 4.x to current versions, if you use the official updating process. You can run into problems if you upgraded some stuff by yourself, which is true for any package manager. A good package manager doesn't downgrade packages during an upgrade process. How is it supposed to handle an "upgrade" from a custom kdebase 3.0.1 installation (compiled with libc 5.x) to the kdebase 3.0.0 package found in the distribution you're trying to update to? Downgrade things in the process? I think that would make people complain, as well.
Similarily, apt-get works quite nicely for Conectiva users.
2. A more complex binary RPM package is often hard, if not impossible, to install
Again, this is not exactly specific to RPM. The problem here is that RPM is used much more widely than any other package manager, therefore RPM packages are typically built on a wider range of potentionally VERY different systems than other packages. If, say, 200 distributions used.deb, you'd run into just the same problem here - your system uses, say, glibc 2.2 and libstdc++ from gcc 2.95.4 while the package you've downloaded was built with glibc 2.3 and libstdc++ from gcc 3.1. No difference at all.
3. The incompatibilities between different versions of the RPM Package Manager added another layer of complexity.
This is true, and the only real rpm specific problem. There's always a tradeoff between new features and backwards compatibility, and rpm does seem to lean a bit too much towards new features.
4. The developers are forced to consider differences between distributions and create multiple binary packages.
This is just restating point 2, and is just as invalid.
Same for the suggested "solutions":
1. Learn to build your own RPMs
This actually does fix some problems... But of course you can't expect everyone to do it. (See also #5)
2. Petition the RPM distributions to adhere to common standards.
Nice in theory, but because there's no real standard ATM, this would mean breaking compatibility with older versions of the distributions (by e.g. adapting a common scheme for naming packages so you won't need to make a difference between Red Hat'ish "Requires: kdelibs >= 3.0.0" and Mandrake'ish "Requires: kdelibs3"), possibly breaking the update path.
3. Use more advanced package management tools, such as urpmi or apt-rpm
I agree with this one (add up2date to the list, btw). The availability of those tools shows that rpm is actually a good and flexible package manager - it just needs some extra tools to simplify some common tasks. It's really the Unix way of doing things - have the tool do one job, and have it doing that one job (handling individual packages without resolving dependencies by itself, in the case of rpm) well. Then write other tools making use of the tool (rpm) to get more advanced functionality.
4. Switch to Debian or Slackware
As shown above, their package managers do not solve the problems mentioned in the article. The problems just happen not to show up so frequently because there aren't many distributions using these package management systems, and the ones that do are usually pretty close to the distribution they're based on. Much closer than completely different distributions like e.g. Red Hat and SuSE, which really don't have much in common except for the package manager.
If, say, Red Hat switched to using.debs, you'd immediately run into the problem that, due to totally different base systems, Red Hat.debs wouldn't run on Debian without changes and vice versa.
So this switch wouldn't gain anything.
5. Switch to source-based Linux distributions, such as Gentoo or Sorcerer
This does solve the problem, but introduces others. It's a good thing for some people, but certainly isn't a universal solution to all problems.
Source based distributions are really nice for people who want to tweak things a lot, but they aren't very useful for a traditional desktop user (who typically doesn't have all that much of a clue and doesn't want to spend a lot of time learning), and they introduce problems even for users who can handle them.
Let's assume you have a source based package manager that is dumbed down enough to allow a user to install a package by clicking on a package file in Konqueror or Nautilus.
Here's some of the problems you'd still need to solve (and some of them really aren't fixable):
The user needs to have all development tools installed - including, depending on what packages they want to install, compilers for very obscure languages (how many of us have installed compilers for, say, Modula 3 and Objective-CAML?)
Installation takes forever. This is not a problem for small packages, but how do you explain to Joe User that, after clicking "Install KDE 3.0", he can't use his new KDE 3.0 for a couple of hours? This is a real problem on slower machines - Compiling, for example, OpenOffice takes approximately 13 hours on an Athlon 1800 with 1.5 GB RAM. Imagine installing it from source on a Pentium with 128 MB RAM...)
How do you handle binary-only stuff? In an ideal world, of course, you don't use any. But try explaining to Joe User why he can't see websites using Flash... I'm all for banning binary-only software, while it's there it needs to be handled.
No beginner-friendly error messages. How do you explain a newbie what foo.cc:123: invalid conversion from `const void*' to `void*' is supposed to mean? (It's typically an indication of broken code that happened to work with gcc 2.x, but doesn't work with gcc 3.x anymore - but how does a newbie know or fix it?)
Besides, rpm is powerful enough to provide this functionality for people who want it, combining the best of both worlds - it's typically as easy as
This still has the same problems as a pure source based distribution, but with rpm, you get the choice between building from source and installing the binary.
It's the primary reasons why I prefer rpms over debs, by the way - they're much easier to build.
And what if a company only sends say 10% spam and the rest is legitimate e-mail. Is it fair for them to get blacklisted, and their legitimate business damaged for the small amount of spam they send?
Yes, absolutely. If a shop sells goods, where 90% are legitimate and 10% are stolen, they're in trouble - and this is just the same thing.
Even if someone sends only one piece of spam, he should be kicked off the net until he realizes he was in error.
Anyone sending spam is not allowed to touch a computer until he sent a note to some central authority that he realized the error in his ways and won't do it again.
Anyone doing it again is permanently banned from touching a computer, and is sent to prison for 10 years if he violates the rule.
This may sound harsh, but it's really not that harsh - if you keep crossing red lights, you're banned from using a car, after all. This is much the same thing, with the exception that spam hurts people, and crossing a red light (it it's safe) doesn't.
One reason the EU might be more advanced is because of the widespread use of mobile phones and the belief (one day) that a mobile device will be your main Internet connection. With per-minute or per-bit charges, getting spammed is going to end up costing people some serious coin if spam continues to grow out of control.
In most European countries, you don't need a mobile connection to pay per minute.;)
At least in.de - unless you're fortunate enough to live in a place that has DSL (available only in and near bigger cities ATM), your only option is pay-per-minute dialup (the concept of free local calls is US specific).
Germany has had a similar law before, and it didn't do anything.
I've reported spammers to the cops repeatedly, and usually got a letter 2 weeks later stating something along the lines of "yes, they violated the law, but we won't go after them for such a small offense because they're too busy with real crime (It's not like they're committing a major crime jike going 55 in a 50 zone, or crossing a traffic light 5 seconds after it turned red...)
I don't think this piece of legislation will be any different.
Legitimate businesses that may worry about their reputation never sent spam in the first place.
There has been no official statement on this yet, and probably the final wording of the license isn't done yet, but in short, this will not be used against any open source projects or companies.
Software patents are evil, yes. But if you can't get rid of them, you unfortunately have to play the dirty game if you don't want to be sued for infringing on patents like "text in a window".
There are several things I totally dislike about Red Hat (such as their ultimately stupid choice of default desktops), but there are plenty of other things that keep me here, like the strong commitment to Open Source. If that were to change, I'd be out of here the same day.
As long as you see my posting from a *@*redhat* address, don't worry about things like this.
True, legally enforced government monopolies are bad... But private monopolies are worse. Take a look at what happened in Germany, for example: The government-enforced monopoly on telecommunications was dropped, and all the hardware (including cables) was given to the ex-monopolist. Potential competitors must use the ex-monopolist's lines for virtually everything, and even if they have a couple of exchanges by themselves, they have to route the last line through the ex-monopolist's network, at a price mostly dictated by the ex-monopolist (and it's slightly higher than what they charge their direct customers; the EU has recently filed a suit against them because of this, but because of the "whoever has the cash owns the courts" rule which seems to be prevalent almost everywhere these days (Microsoft trial, anyone?), I don't expect much to come out of it.
The current situation in.de is pretty much what you'd expect: The ex-monopolist pretty much owns the market, and you can switch to a competitor only if you're in a big (and therefore profitable) city.
If you're in a rural area, your only choice is still (and will remain for quite a while) the ex-monopolist, and they're much more evil than in their government times.
Privatization is the right thing to do only if you do it right (such as not giving the ex-monopolist an unfair advantage), which AFAIK hasn't happened anywhere.
I have been underwhelmed by Red Hat's packaging of KDE in the past. For example, in a boxed release (either 7.1 or 7.2), kdehelp's "back" and "forward" buttons didn't work.
This must be related to your setup. It doesn't happen here, and it doesn't happen to anyone else, at least not to anyone who cares about it enough to report it (as always, I can't fix problems I'm not aware of).
Even if a problem seems obvious to you (say, a crash on startup), go ahead and report it because chances are it happens only on your setup or your hardware. If it were really as obvious as it seems to you, it would have been fixed.
When KDE 2.2.2 RPMs were released, they helpfully included (and required) a version of Qt that froze the desktop
Also, for your setup only. Worked perfectly here.
The current KDE3 RPMs for RH 7.2 from Red Hat have their own glitches: ksplash goes kblooie at startup
This is a known problem. It only occurs on first startup though, which is why I didn't notice it before uploading the packages to kde.org. It has been fixed since, and is fixed in 7.3, along with several other problems we've noticed.
and konqueror seems to have this big memory leak that bloats its footprint over time.
Not reproducable here. Report details here or here.
I wonder if anyone at Red Hat even tries to use KDE.
Yes. Plenty of us do. I haven't seen any other desktop running on any machine in our.de office for quite some time.
The only two desktops I ever use are KDE and text mode. Konqueror and lynx are my favorite browsers.
First of all, don't use 2.4.7-anything. It has some major problems including a remote root exploit. Please upgrade to either the 7.2 errata kernel, 2.4.9-something, which fixes all known security problems, or the 7.3 kernel.
So there are two possibilities: 1) fsked up my 2.4.18 config, and thus ended up compiling a really crappy kernel. But I've been compiling kernels since 1.2.13, and have yet to have one behave anywhere NEAR this badly. 2) RH have significantly hacked 2.4.7 to make it useful. Does anyone know whether the same hacks have happened for the 7.3 kernel?
2, and possibly 1 as well.
Red Hat kernels are always patched quite a bit to make them more stable/usable, but 2.4.18 doesn't look THAT bad for me (maybe related to different hardware or different setups).
Since kjournald appears to be the culprit, the Red Hat version of 2.4.18 is likely to fix the problem because it uses a newer version of ext3 and everything related to it.
Re:Does the distribution still include Netscape?
on
Red Hat Linux 7.3 Released
·
· Score: 4, Interesting
There are several problems in the license. The part I'm referring to is this:
2. License to Distribute Software. Subject to the terms and conditions of this Agreement, including, but not limited to Section 4 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified (unless otherwise specified in the applicable README file) and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software (unless otherwise specified in the applicable README file), (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. (vi) include the following statement as part of product documentation (whether hard copy or electronic), as a part of a copyright page or proprietary rights notice page, in an "About" box or in any other form reasonably designed to make the statement visible to users of the Software: "This product includes code licensed from RSA Security, Inc.", and (vii) include the statement, "Some portions licensed from IBM are available at http://oss.software.ibm.com/icu4j/".
IANAL, but for me, this implies:
non-transferable -- we can't allow anyone else to copy our CDs
bundled as part of, and for the sole purpose of running, your Programs -- we don't write anything in Java, so we'd be shipping it for a different purpose, e.g. to view someone else's Java applets -> we'd violate the license.
You do not distribute additional software intended to replace any component(s) of the Software -- while this is probably meant to say you can't require someone to install JDK and then remove javac to replace it with something else, it can be interpreted as "If you ship JDK, you may not ship any replacements for parts of it [such as GCJ, Jikes or Kaffe]". We ship gcj.
Earlier versions than 2.96 are not an option because they don't do real C++ (see http://www.bero.org/gcc296.html). 3.0.x releases are rather broken and don't have any real advantages over the current builds of 2.96.
gcc 3.1 will be a very good release, even better than 2.96. It is what we're likely to use in the next major release (unless, of course, gcc 3.2 comes first and is good).
It's not. OpenOffice 1.0 was released way too late to get through the QA process (can't reveal the schedule of course, but take a look at the changelogs in packages to get an idea about when the release had to be deep-frozen;) ).
There are a couple of other things that prevent it from getting into Rawhide at the moment.
Off the top of my head (there are probably some more):
It doesn't build without Sun JDK. We're looking into porting to gcj, but it's quite a way to go. Since gcj in any gcc prior to 3.1 is rather sucky, this was not even possible for a 7.x release.
The UNO stuff requires a specific version of gcc, and it's not the "right" one.
The installation process is not suitable for packaging. (Try building an RPM of something requiring GUI input during installation...)
These are all fixable because it's Open Source, but they require a considerable amount of time.
Also, the database application is missing (because it couldn't be relicensed), and some people depend on it.
I'm expecting OpenOffice in the base distribution in the next release... But this is not an official statement and much less a promise.
Re:Does the distribution still include Netscape?
on
Red Hat Linux 7.3 Released
·
· Score: 5, Informative
It's still included.
Both Konqueror and Mozilla are better for most stuff by now, but unfortunately, Netscape 4.x is still the only browser that does Java without the need of shipping a not legally redistributable JDK.
My setup (catches some of the more commonly used spambots) uses mod_rewrite to send spammers to a trap. Setup details at http://www.bero.org/NoSpam/isp.php
Either ISPs or a government tax should charge one cent per email. The average user who probably sends less than a dollar's worth per day would hardly notice the charge. The spammer would be paralyzed.
This is a horrible idea. Think of the things you couldn't do anymore...
The linux-kernel mailing list has more than 1000 subscribers, and gets about 300 mails a day.
Running it means sending about 300 * 1000 = 300000 mails a day, which would cost $3000 a day by your suggestion.
The same goes for kde-devel, kde-core-devel and kde-cvs, and probably their equivalents in the gnome world.
Who would pay those? Right, nobody.
Introducing such a thing may not kill Open Source, but it would make it VERY hard. ("What? I'm supposed to PAY to share the fix I've come up with???").
OpenOffice will be included when it's ready. This means among other things that it must build without relying on proprietary crap like Sun JDK, and the resulting binaries must work.
We're trying to get it to build with gcj for the Java parts, but that doesn't work yet. No promises or estimates.
Slashdot Mirror
I think it's not so much about backwards compatibility, and not as much "x86-64 is good" as "ia64 sucks".
I'm all but a fan of x86, but ia64 beats it at sucking, and x86-64 is at least a bit better.
Let's see:
1. An RPM-based distribution is risky to upgrade
Not quite. Red Hat, for example, still supports upgrading from Red Hat Linux 4.x to current versions, if you use the official updating process.
You can run into problems if you upgraded some stuff by yourself, which is true for any package manager. A good package manager doesn't downgrade packages during an upgrade process. How is it supposed to handle an "upgrade" from a custom kdebase 3.0.1 installation (compiled with libc 5.x) to the kdebase 3.0.0 package found in the distribution you're trying to update to?
Downgrade things in the process? I think that would make people complain, as well.
Similarily, apt-get works quite nicely for Conectiva users.
2. A more complex binary RPM package is often hard, if not impossible, to install
Again, this is not exactly specific to RPM. The problem here is that RPM is used much more widely than any other package manager, therefore RPM packages are typically built on a wider range of potentionally VERY different systems than other packages.
If, say, 200 distributions used
3. The incompatibilities between different versions of the RPM Package Manager added another layer of complexity.
This is true, and the only real rpm specific problem.
There's always a tradeoff between new features and backwards compatibility, and rpm does seem to lean a bit too much towards new features.
4. The developers are forced to consider differences between distributions and create multiple binary packages.
This is just restating point 2, and is just as invalid.
Same for the suggested "solutions":
1. Learn to build your own RPMs
This actually does fix some problems... But of course you can't expect everyone to do it.
(See also #5)
2. Petition the RPM distributions to adhere to common standards.
Nice in theory, but because there's no real standard ATM, this would mean breaking compatibility with older versions of the distributions (by e.g. adapting a common scheme for naming packages so you won't need to make a difference between Red Hat'ish "Requires: kdelibs >= 3.0.0" and Mandrake'ish "Requires: kdelibs3"), possibly breaking the update path.
3. Use more advanced package management tools, such as urpmi or apt-rpm
I agree with this one (add up2date to the list, btw). The availability of those tools shows that rpm is actually a good and flexible package manager - it just needs some extra tools to simplify some common tasks. It's really the Unix way of doing things - have the tool do one job, and have it doing that one job (handling individual packages without resolving dependencies by itself, in the case of rpm) well. Then write other tools making use of the tool (rpm) to get more advanced functionality.
4. Switch to Debian or Slackware
As shown above, their package managers do not solve the problems mentioned in the article. The problems just happen not to show up so frequently because there aren't many distributions using these package management systems, and the ones that do are usually pretty close to the distribution they're based on. Much closer than completely different distributions like e.g. Red Hat and SuSE, which really don't have much in common except for the package manager.
If, say, Red Hat switched to using
So this switch wouldn't gain anything.
5. Switch to source-based Linux distributions, such as Gentoo or Sorcerer
This does solve the problem, but introduces others. It's a good thing for some people, but certainly isn't a universal solution to all problems.
Source based distributions are really nice for people who want to tweak things a lot, but they aren't very useful for a traditional desktop user (who typically doesn't have all that much of a clue and doesn't want to spend a lot of time learning), and they introduce problems even for users who can handle them.
Let's assume you have a source based package manager that is dumbed down enough to allow a user to install a package by clicking on a package file in Konqueror or Nautilus.
Here's some of the problems you'd still need to solve (and some of them really aren't fixable):
This is a real problem on slower machines - Compiling, for example, OpenOffice takes approximately 13 hours on an Athlon 1800 with 1.5 GB RAM. Imagine installing it from source on a Pentium with 128 MB RAM...)
foo.cc:123: invalid conversion from `const void*' to `void*' is supposed to mean? (It's typically an indication of broken code that happened to work with gcc 2.x, but doesn't work with gcc 3.x anymore - but how does a newbie know or fix it?)
Besides, rpm is powerful enough to provide this functionality for people who want it, combining the best of both worlds - it's typically as easy as
rpm --rebuild foo-1.0-1.src.rpm
rpm -ivh
This still has the same problems as a pure source based distribution, but with rpm, you get the choice between building from source and installing the binary.
It's the primary reasons why I prefer rpms over debs, by the way - they're much easier to build.
I think that they always are in agreement when science is done correctly.
Make that, when both science and religion are done correctly.
Correctly done science is certain to run into trouble with a religion asserting earth is flat, or sun circles around earth.
And what if a company only sends say 10% spam and the rest is legitimate e-mail. Is it fair for them to get blacklisted, and their legitimate business damaged for the small amount of spam they send?
Yes, absolutely.
If a shop sells goods, where 90% are legitimate and 10% are stolen, they're in trouble - and this is just the same thing.
Even if someone sends only one piece of spam, he should be kicked off the net until he realizes he was in error.
Propoesed (but unfortunately irrealistic/utopian) spam legislation:
Anyone sending spam is not allowed to touch a computer until he sent a note to some central authority that he realized the error in his ways and won't do it again.
Anyone doing it again is permanently banned from touching a computer, and is sent to prison for 10 years if he violates the rule.
This may sound harsh, but it's really not that harsh - if you keep crossing red lights, you're banned from using a car, after all. This is much the same thing, with the exception that spam hurts people, and crossing a red light (it it's safe) doesn't.
One reason the EU might be more advanced is because of the widespread use of mobile phones and the belief (one day) that a mobile device will be your main Internet connection. With per-minute or per-bit charges, getting spammed is going to end up costing people some serious coin if spam continues to grow out of control.
;)
.de - unless you're fortunate enough to live in a place that has DSL (available only in and near bigger cities ATM), your only option is pay-per-minute dialup (the concept of free local calls is US specific).
In most European countries, you don't need a mobile connection to pay per minute.
At least in
spam has always cost Europeans real money.
Germany has had a similar law before, and it didn't do anything.
I've reported spammers to the cops repeatedly, and usually got a letter 2 weeks later stating something along the lines of "yes, they violated the law, but we won't go after them for such a small offense because they're too busy with real crime (It's not like they're committing a major crime jike going 55 in a 50 zone, or crossing a traffic light 5 seconds after it turned red...)
I don't think this piece of legislation will be any different.
Legitimate businesses that may worry about their reputation never sent spam in the first place.
There has been no official statement on this yet, and probably the final wording of the license isn't done yet, but in short, this will not be used against any open source projects or companies.
Software patents are evil, yes. But if you can't get rid of them, you unfortunately have to play the dirty game if you don't want to be sued for infringing on patents like "text in a window".
There are several things I totally dislike about Red Hat (such as their ultimately stupid choice of default desktops), but there are plenty of other things that keep me here, like the strong commitment to Open Source.
If that were to change, I'd be out of here the same day.
As long as you see my posting from a *@*redhat* address, don't worry about things like this.
True, legally enforced government monopolies are bad... But private monopolies are worse.
.de is pretty much what you'd expect: The ex-monopolist pretty much owns the market, and you can switch to a competitor only if you're in a big (and therefore profitable) city.
Take a look at what happened in Germany, for example:
The government-enforced monopoly on telecommunications was dropped, and all the hardware (including cables) was given to the ex-monopolist.
Potential competitors must use the ex-monopolist's lines for virtually everything, and even if they have a couple of exchanges by themselves, they have to route the last line through the ex-monopolist's network, at a price mostly dictated by the ex-monopolist (and it's slightly higher than what they charge their direct customers; the EU has recently filed a suit against them because of this, but because of the "whoever has the cash owns the courts" rule which seems to be prevalent almost everywhere these days (Microsoft trial, anyone?), I don't expect much to come out of it.
The current situation in
If you're in a rural area, your only choice is still (and will remain for quite a while) the ex-monopolist, and they're much more evil than in their government times.
Privatization is the right thing to do only if you do it right (such as not giving the ex-monopolist an unfair advantage), which AFAIK hasn't happened anywhere.
I have been underwhelmed by Red Hat's packaging of KDE in the past. For example, in a boxed release (either 7.1 or 7.2), kdehelp's "back" and "forward" buttons didn't work.
.de office for quite some time.
This must be related to your setup. It doesn't happen here, and it doesn't happen to anyone else, at least not to anyone who cares about it enough to report it (as always, I can't fix problems I'm not aware of).
Even if a problem seems obvious to you (say, a crash on startup), go ahead and report it because chances are it happens only on your setup or your hardware. If it were really as obvious as it seems to you, it would have been fixed.
When KDE 2.2.2 RPMs were released, they helpfully included (and required) a version of Qt that froze the desktop
Also, for your setup only. Worked perfectly here.
The current KDE3 RPMs for RH 7.2 from Red Hat have their own glitches: ksplash goes kblooie at startup
This is a known problem. It only occurs on first startup though, which is why I didn't notice it before uploading the packages to kde.org.
It has been fixed since, and is fixed in 7.3, along with several other problems we've noticed.
and konqueror seems to have this big memory leak that bloats its footprint over time.
Not reproducable here. Report details here or here.
I wonder if anyone at Red Hat even tries to use KDE.
Yes. Plenty of us do. I haven't seen any other desktop running on any machine in our
The only two desktops I ever use are KDE and text mode. Konqueror and lynx are my favorite browsers.
Remove Ximian first. They're playing the rpm Epoch game, so installing their packages breaks updates unless they are removed prior to updating.
First of all, don't use 2.4.7-anything.
It has some major problems including a remote root exploit. Please upgrade to either the 7.2 errata kernel, 2.4.9-something, which fixes all known security problems, or the 7.3 kernel.
So there are two possibilities:
1) fsked up my 2.4.18 config, and thus ended up compiling a really crappy kernel. But I've been compiling kernels since 1.2.13, and have yet to have one behave anywhere NEAR this badly.
2) RH have significantly hacked 2.4.7 to make it useful. Does anyone know whether the same hacks have happened for the 7.3 kernel?
2, and possibly 1 as well.
Red Hat kernels are always patched quite a bit to make them more stable/usable, but 2.4.18 doesn't look THAT bad for me (maybe related to different hardware or different setups).
Since kjournald appears to be the culprit, the Red Hat version of 2.4.18 is likely to fix the problem because it uses a newer version of ext3 and everything related to it.
The part I'm referring to is this:
2. License to Distribute Software. Subject to the terms and conditions of this Agreement, including, but not limited to Section 4 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified (unless otherwise specified in the applicable README file) and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software (unless otherwise specified in the applicable README file), (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. (vi) include the following statement as part of product documentation (whether hard copy or electronic), as a part of a copyright page or proprietary rights notice page, in an "About" box or in any other form reasonably designed to make the statement visible to users of the Software: "This product includes code licensed from RSA Security, Inc.", and (vii) include the statement, "Some portions licensed from IBM are available at http://oss.software.ibm.com/icu4j/".
IANAL, but for me, this implies:
There's not much of a problem with 2.96.
Earlier versions than 2.96 are not an option because they don't do real C++ (see http://www.bero.org/gcc296.html).
3.0.x releases are rather broken and don't have any real advantages over the current builds of 2.96.
gcc 3.1 will be a very good release, even better than 2.96. It is what we're likely to use in the next major release (unless, of course, gcc 3.2 comes first and is good).
OpenOffice 1.0 was released way too late to get through the QA process (can't reveal the schedule of course, but take a look at the changelogs in packages to get an idea about when the release had to be deep-frozen
There are a couple of other things that prevent it from getting into Rawhide at the moment.
Off the top of my head (there are probably some more):
These are all fixable because it's Open Source, but they require a considerable amount of time.
Also, the database application is missing (because it couldn't be relicensed), and some people depend on it.
I'm expecting OpenOffice in the base distribution in the next release... But this is not an official statement and much less a promise.
It's still included.
Both Konqueror and Mozilla are better for most stuff by now, but unfortunately, Netscape 4.x is still the only browser that does Java without the need of shipping a not legally redistributable JDK.
Error in the announcement. It's actually 0.9.9.
This also makes it invisible to anyone who disabled JavaScript, and anyone using a browser that doesn't do JavaScript (lynx, links, etc.)
My setup (catches some of the more commonly used spambots) uses mod_rewrite to send spammers to a trap.
Setup details at http://www.bero.org/NoSpam/isp.php
A good way to see one is adding
strcpy(NULL, "Microsoft sucks!");
in kernel/signal.c
That's what I did some years ago because I was curious as to what a "Linux bluescreen" looks like.
The code needed to get M$ Office to run will be merged back into base wine (the joys of LGPL :) ), so sooner or later you'll get it for free.
configuring an ISDN-card or DSL-modem is simply NOT an easy task for an average user.
Except if the distribution does it for him - in recent Red Hat Linux versions, it comes down to entering the username and password for DSL.
Either ISPs or a government tax should charge one cent per email. The average user who probably sends less than a dollar's worth per day would hardly notice the charge. The spammer would be paralyzed.
This is a horrible idea. Think of the things you couldn't do anymore...
The linux-kernel mailing list has more than 1000 subscribers, and gets about 300 mails a day.
Running it means sending about 300 * 1000 = 300000 mails a day, which would cost $3000 a day by your suggestion.
The same goes for kde-devel, kde-core-devel and kde-cvs, and probably their equivalents in the gnome world.
Who would pay those? Right, nobody.
Introducing such a thing may not kill Open Source, but it would make it VERY hard. ("What? I'm supposed to PAY to share the fix I've come up with???").
If you have an HP printer, get hpijs. It's at least as good as Windoze printing.
It's included in Skipjack, now that it's under a sane license (its old license was preventing its inclusion in earlier releases).
Other important added patches:
OpenOffice will be included when it's ready.
This means among other things that it must build without relying on proprietary crap like Sun JDK, and the resulting binaries must work.
We're trying to get it to build with gcj for the Java parts, but that doesn't work yet. No promises or estimates.