Actually, RPM has supported bzip in various forms for quite some time. RPM 3.0.5+ has support for bzip payloads. This isn't the big change in RPM 4; the change to db3 is.
Anyway, since many RH 7 binaries won't work properly on a 6.2 system, it's probably a good thing that it's a bit of work to get them to install.
Red Hat makes the extremely reasonable choice of not sticking to cruft. This is why this is a 7.0 release, not 6.something. Expect similar things to happen with RH 8. There is utterly nothing wrong with this. Other distributions will come across the same problems as they move to the newer C++ (either the same v2.96 snapshot or v3) and newer glibc. It'll all be in sync again eventually.
And, it should be noted that the *source* RPMs are still completely compatible.
I don't understand what you mean by "All possibilities of 'choice' within Linux being wiped out by them". There's a lot of choice.
Do you have a better suggestion for what to do with XFree86 4.0.x? It doesn't support a lot of very standard video cards to nearly the same level as 3.3.x. Or would you just ship the older X server system until 4 is perfect?
I'm not sure exactly what you mean about the kernel files being messed up; care to explain further?
And, I think the article linked to above explains the compiler issue well pretty well.
I'm not smoking anything, thanks. It's a serious problem that is a real drag on PC game development. There's a lot of weird and different hardware out there. Microsoft's DirectX has been a big benefit, since it does a good job of abstracting these things, but before that, getting your system configured to run various games on Windows/DOS was a serious pain.
The situation is different on Linux, but it still doesn't escape the base issues. Overall, having a diversity of hardware is a good thing, but needing to support it all is a lot of extra work which takes time away from making the actual games. A homogenous reference platform to develop for makes things drastically easier.
I think they get that. The article mentions having a "complex software development kits that change every generation" as a negative of other systems, and says Gildred's vision is to provide a "upgradable gaming system without the headache of PC incompatibility".
--
Re:Bush's the winner, Gore's the cracker!
on
Furby Bounty Paid
·
· Score: 1
You're just missing a key bit of data. The heavily republican-party counties tend to use more modern and accurate optical systems instead of the punch cards, whereas for whatever reason, the big democratic-party areas are still using out of date equipment. This isn't a conspiracy or anything, but the fact is, it's most likely more that Gore votes got lost. This is why Bush opposes the recount so much -- he knows there's a good chance of a turnaround.
All of a sudden, it's very possible that at some time in the distant past, a primitive(or maybe not so primitive) planet/moon was struck by a large meteorite, throwing up huge clouds of dust, full of organic materials(and maybe even primitive life, that survived the blast). A comet passes through the cloud, and carries said organic material all through the solar system.
OK, fine, but isn't most likely by far that this collision happened at the nearest life-bearing planet -- Earth? Especially when we *know* that we've been hit by pretty large things. Why the need for all the travelling through space, which while infintesimally possible, is still a very very small chance even after billions of years?
Well, Stephenson agrees with you, which is why he didn't want it reprinted for so long. But he probably also got sick of seeing people paying $600 for it. And, there's lots of demand.
Personally, I think it's a great book. *shrug*
Not so. Since the DNS is hierarchical, it'd scale very well. It might be necessary to add a new layer of servers between the root and the rest, but that wouldn't be difficult -- and probably wouldn't really be necessary.
The "real reason" you give is easy to solve -- don't let anyone have control over TLDs -- anyone can create them, but then, anyone can register any domain within the new TLD.
I *would* like to see a usenet-style hierarchy, but it's a bit late for that.
Sure, that makes sense 200 years ago, and maybe even 100 years ago. But with modern technology and transportation, isn't that a bit anachronistic? These days, the states really are just a convenient partitioning of land and people.
The problem is, by reducing the power of our democratically elected federal government, we'd be ceding more power to multinational corporations -- who don't have to answer to anybody but their own shareholders. Big government in any form is dangerous -- but big government run on the concept of one dollar, one vote would be even worse than what we have now.
I dunno. That's true in some cases, but the graphics and music and scope of games has improved vastly and continues to do so. (Gameplay is another question, of course.) There will always be a market for the latest and greatest games.
Exactly. This is the reasoning behind the adage "security through obscurity is no security at all". It gives a false sense that no one could ever find the weaknesses, when in truth, it just means that only the bad guys know.
I don't remember the history exactly, but I know there *was* a UK court case which affirmed that Sealand doesn't fall under UK juristiction. So they haven't been completely ignored.
It might not kill them, but it would definitely hurt. They've relied on security through obscurity for years, and suddenly, it's all exposed. If the code becomes public (or, perhaps worse, widely available in serious black hat circles), watch for a *lot* of exploits.
Slashdot Mirror
--
Anyway, since many RH 7 binaries won't work properly on a 6.2 system, it's probably a good thing that it's a bit of work to get them to install.
Red Hat makes the extremely reasonable choice of not sticking to cruft. This is why this is a 7.0 release, not 6.something. Expect similar things to happen with RH 8. There is utterly nothing wrong with this. Other distributions will come across the same problems as they move to the newer C++ (either the same v2.96 snapshot or v3) and newer glibc. It'll all be in sync again eventually.
And, it should be noted that the *source* RPMs are still completely compatible.
I don't understand what you mean by "All possibilities of 'choice' within Linux being wiped out by them". There's a lot of choice.
--
I'm not sure exactly what you mean about the kernel files being messed up; care to explain further?
And, I think the article linked to above explains the compiler issue well pretty well.
What were the other issues?
--
Sure, those things are good. They're working at solving the problem -- which does exist.
PS: I like SDL too.
--
The situation is different on Linux, but it still doesn't escape the base issues. Overall, having a diversity of hardware is a good thing, but needing to support it all is a lot of extra work which takes time away from making the actual games. A homogenous reference platform to develop for makes things drastically easier.
--
--
--
OK, fine, but isn't most likely by far that this collision happened at the nearest life-bearing planet -- Earth? Especially when we *know* that we've been hit by pretty large things. Why the need for all the travelling through space, which while infintesimally possible, is still a very very small chance even after billions of years?
--
--
Personally, I think it's a great book. *shrug*
--
--
--
I *would* like to see a usenet-style hierarchy, but it's a bit late for that.
--
--
--
--
--
--
--
--
--
--
--
--
--