The first few levels were great. It was actually so scary that somewhere early on, I had to press pause, remove my headphones and ask myself whether I really _enjoy_ being that scared while playing a game. However, as the game went on, and your characters got more powerful, it really faltered. Also, some things really annoyed me, like finding ammo for your modern weapons lying around in the monastery when you travel back in time. Undying could have been a really great game, but just fell short in a lot of ways.
My god... where do all these people who actually WERE "innocent" as children come from?
Personally, I remember my wild childhood imagination thinking up scenes just as dirty as anything on the Evil Internet with my favorite comic book characters back when I was just 7-8 or so, and most of my friends back then were just as dirty-minded little bastards.
Of course, sex and superheroes were both about equally "unreal" to us... Perhaps that's an excuse.:)
Although I'm definitely not going to question your basic statement of the Itanium being a terrible performer in "day-to-day tasks", compilation is probably a VERY unfair thing to use for benchmarking. Remember that one of the big problems with the EPIC architecture is that the compiler has all responsibility for optimizing the binary code in such a way that the maximum number of instructions can be exectuted in parallel.
The process of compilation and optimization is hence probably massively more difficult and CPU-intensive than compilation for most other architectures. A fairer benchmark for compilation efficiency might be to do a cross-compile that produces x86 binaries.
"No attempt" indeed. I guess you are right, but only because IBM hasn't "attempted" to give Linux missing enterprise features, but rather simply DONE it.
Or did we all just hallucinate EVMS, the port of jfs, and the work IBM have done to help better SMP scalability on large systems? Sheesh.
There are VERY few "enterprise features" that commercial UNIX's have which linux doesn't, by now. Massive SSI multiprocessor scalability still isn't competitive with Irix or Solaris. AFAIK, there is still no support for hot-swapping memory in linux, even on hardware that supports that featre. But apart from that, I really can't think of much in the OS itself. Maturity of _documentation_ on the other hand is an area where some catching up is needed.
Here we go again with more confusion of OS and Hardware capability and other factual errors.
Linux handles more than 4 Gigs just fine, on 64-bit architectures. The x86 architecture on the other hand needs terrible cludges (PAE) to handle more than 4 Gigs. Solaris does even worse than Linux at this on the x86 architecture. That said, Solaris's VM in general is probably more roboust than the current mainline Linux VM.
As for Linux's SMP scaling, it scales fine up to 8 CPU's on Intel hardware. SGI claims that on their Altix architecture, it scales well up to 64 CPU's. Given that they are probably the only ones who have even tested Linux on a SSI computer of that scale, they are the only ones who have actual facts to say anything about its scaling. Would be nice to see some figures, though, for sure.
Solaris's "high performance, high reliability filesystems"? Oh you mean Veritas VXFS? That's an add-on product, not part of Solaris. A fairly expensive add-on product, at that. Veritas sells VXFS for Linux too, in case you wonder, but you rarely see it on Linux systems because the need is simply not as great. Solaris's native filesystem UFS is a _joke_ for performance, and the journalling that is now available for it is a bolted-on kludge. Hence, any serious Solaris system is likely to have VXFS installed. The exception is when the machines are running applications that use raw partitions for their data, which is very common to see (Oracle, Tivoli Storage Manager, etc).
The XFS port for Linux is not a beta, and has not been for a long time. It is not yet part of the main kernel tree, but that doesn't make it in any way a "beta" or "untested". You would be surprised if you knew how many commercially sold NAS solutions run Linux with XFS under the hood. XFS is still an add-on product, but one that is in some ways more capable than VXFS, and on top of that, free.
Oh yea. And XFS supports ACLs on Linux and works well together with samba, which is part of the reason why its common in those NAS boxes.
I used to wonder why people heaped so much derision on CmdrTaco. He's like that annoying bastard who keeps setting the network printer to make two copies of everything as the default. Gah.
If it's anything like previous "gold" releases of MS products, it is "going gold" the way a lump of lead will "go gold" if you dip it in a solution of gold nitrate....:)
ACL support for Linux has been available through SGI's XFS for a LONG time. SGI even provides pre-compiled kernels based on the Redhat kernels, for those who are scared of patching and compiling on their own. Redhat 9 will have support for ACLs out of the box.
Small bit of trivia: the working title for the screenplay to Brazil was "1984½". However, I must say that despite the superficial similarities between Brazil and 1984, Brazil's literary parentage seems to have far more of Philip K. Dick's genes in it than George Orwell's.
Hell yes. My favorite movie of all time. Seen it eight times on the big screen, and probably around twenty or so times on the small screen, and I _still_ keep noticing little details in it that i've missed on previous viewings. Pure brilliance.
As far as I'm concerned, no amount of appreciation for this movie would ever make it appreciated enough, so i guess it IS underappreciated, despite its huge cult following, classic-status and heaps of critical praise.:)
Actually, _most_ Quayle quotes are in fact real. However, funnily enough, his quotes tend to get "re-used" and re-attributed to Dubya and sometimes Gore. A lot of false Bush/Gore quotes will turn out to be real Quayle-quotes, if you do some digging.
There was (is?) actually a video sold with actually footage of Quayle delivering many of his most famous goofs.
My favorite quote about the Turing test comes from Jaron Lanier:
"Only a fucked-up gay Englishman being tortured with hormone injections could possibly have supposed that consciousness was some kind of social exam you had to pass."
Ummm... I haven't played NWN, but claiming Morrowind isn't user-extensible just sounds VERY odd to me, given the nice construction kit that comes with the game when you buy it. There are some astonishingly high quality user-made extensions and modifications to Morrowind out there already. The one thing that I find lacking in Morrowind mod-making is the scripting language, both in flexibility/power, and in documentation.
I once shot a piece of crumpled toilet paper right through a wooden fence on an inner-city backyard. I did use a cannon, and plenty of actual gunpowder though.The entire backyard was afterwards filled with a thick gunsmoke fog. I'm still surprised that neither the police nor the firedepartment showed up.
I must add that although I lit the fuse on the cannon, I claim complete lack of responsibility for the air and noise pollution, as well as the damage to the fence. All blame shall lie with the crazy author of children's novels whose 50th birthday was the occasion for the abovementioned event.:)
Re:Not surprising for other reasons...
on
KDE 3.1 Released
·
· Score: 1
Well, bleeding-edge addicts can simply chose RawHide as their redhat release of choice, and keep updating... updating... updating...;)
Seriously, though - it's not that redhat _can't_ do it, its that they _won't_ do it - its not in line with their update policy. If you don't like RedHat's policy on updates, you should just stay away from that distro altogether, which is a perfectly valid choice. Just don't try to make it out as a KDE-specific issue.
Not surprising for other reasons...
on
KDE 3.1 Released
·
· Score: 1
...namely that RedHat generally never releases packages for new packages for _anything_ to current distributions, other than to fix bugs.
Now, I realize that the parent post in this case is not actually clear on whether the complaint is about packages for Redhat by the KDE project itself, or lack of KDE 3.1 packages from Redhat. Therefore, if the case is the former, I'll apologize for the somewhat angry tone below, and ask that it be considered reserved for the whiners elsewhere in this thread.
I can't help but notice that KDE users seem to be demanding _privilieged_ treatement from Redhat, rather than merely the same treatment as other projects get.
Redhat have never provided packages for new gnome releases either. Redhat provides the same treatement to KDE as they give to every other app shipped with their distros - bugfixes only. New versions will be shipped with new distro releases.
And incidentally - If you check the updates for RedHat 8, you'll find they have released more fixes for KDE apps than they have for gnome. Of course you could argue that this might be because they shipped KDE in a buggier state. I can't comment since I don't use KDE. The fact, nevertheless, is worth noting.
Thank you for bringing it up. Now I will have flashbacks, and have to go back to therapy for a few months to get the nervous tics to stop.
More seriously, though, I shouldn't complain. It prolonged the project I was working on for many months, and I bill by the hour, the flakyness and flaws of Unicenter made me a lot of extra money.
Ultimately, it is possible to get Unicenter to work "well" on Linux, but if my experiences are typical, it takes a lot of time, money, and a crapload of workarounds before it does what its supposed to do.
I should, in fairness, point out that we were early adopters, had a very customized and not completely standard Linux setup for, and that we got CA to fix some bugs that we ran into. Future users of Unicenter on Linux may have a less bumpy ride.
Even "many", or "most" would have been okay. Either would have made it a valid opinion, instead of a blatantly sweeping generalization put forward in a way that makes it sound like you believe you're stating an absolute fact of general applicability on anyone who calls themselves a "skeptic".
It seems the fundamental problem, both with "believers" and "debunkers", that they confuse opinions, beliefs, or "current best models/theories" with hard facts and knowledge.
Personally, I think Sagan's "Demon Haunted World", Gardners "Facts and Fallacies in the Name of Science", as well as Wilson's "The New Inquisition" should all be required reading for those who wants to call themselves skeptics.
Please don't "translate" what people say - read what's written and reply to that.
When I wrote my initial comment, I had some small hope that you'd actually counter with a compelling argument against RPMs being included in the LSB. You could have done that, and made me listen, if you'd shown you understood the additional requirements of a package format as opposed to plain tar, and more specifically, that you understood RPMs. However, you will not make me inclined to listen to your arguments when you consistently display complete lack of understanding of the RPM format, and make numerous factual errors. If you disapprove of the rpm format, you need to show you "know your enemy". The remark that you "translated" into a personal insult was a request for you to make sure you do that before you argue further.
You now instead continue to show you that you don't, but, against my better judgement, I'll respond to your arguments anyway.
The difference between an archive and a package is one of semantics.
I'll concede that there's no (to my knowledge) formal specification of "package" versus "archive". My definition is based on working with other package systems, under AIX and Solaris specifically. In case you didn't know, "tar" is not "standard package format" under those *nixes either, and if you think RPM is nasty, you should take a look at AIX's lpp. In any case, they all provide something more than a mere archive like cpio or tar.
A tarball can easilly contain all of the information necessary for a package to be built, indeed, most source tarballs these days do exactly that.
Interesting. In stating that a tarball CAN contain all information to BUILD a package, you inadvertently admit that tar itself _isn't_ a "package". And yes... indeed, today, many source tarballs today do contain all the information necessary to build a package - they contain a.spec file, which you can use to produce an RPM.
But do not in the process favor one distribution over another,
I don't see how any distribution is favored over another. RPM is an open, well documented format. Any distribution can use it, and more distributions do use RPM than the competing DEB package format. I'm not entirely certain that RPM was chosen over DEB on purely technical reasons, or whether the "popularity" of the format played a part in the decision, but in either case, it was a format that was favored, not a distribution.
or chuck out a perfectly good archival approach
The archival approach is not "perfectly good". At the risk of sounding like a broken record, I have to say again that you seem woefully unaware of just how much more rpm does than a tar. Its not just dependency information.
that is a widely adopted, cross-platform standard for one that is obfuscated, inferior, less widely adopted, and less generic.
RPM is also cross-platform. You can get it for Solaris, AIX, and even non-unix platforms like OS/2. And there's a reason it's been ported, and I can assure you that the reason is not "because it sucks", or because the LSB dictates it. "Obfuscated" is simply untrue, "inferior" is merely opinion, which you consistently fail to support with any kind of factual or insightful arguments. Less generic is certainly true, but then, a package format has a somewhat more specific purpose than a mere archive.
Furthermore, not all distributions use binaries. Any standard that makes an assumption that all od (as LSB to some extent does, by adopting RPM) is inherently inadequate and broken.
I can only read this as further evidence of your complete ignorance about RPMs. RPM is designed to build the binary packages directly from source. If you don't want the binary RPMs pre-compiled by the distributor, you can grab the source RPMs and re-build them for your system, with whatever optimizations you want. A source RPM contains the pristine, untouched source tarball, keeping any patches a vendor might want to add to it separate while still automating and standardizing the patching procedure during a re-build. Since my own systems (and some of the systems i've designed for customers) are very heavily customized, I frequently do just that.
For example, many distributions, such as Gentoo and Source Mage, use source and build the installation dynamically.
There is nothing preventing doing an RPM-based distribution that does exactly that. In fact, I've toyed with the idea of doing that myself as an exercise. Gentoo is very cool, and their portage system looks nice. However, I have not yet delved into its intricacies deep enough to say whether it gives all the benefits that RPM does. Perhaps you can inform me of how to do the equivalent of "rpm -f file" or "rpm -Va" with Gentoo's system.
In short, there are compelling reasons why adding a binary package format, particularly one such as RPM, will not have a beneficial affect for Linux as a whole (though it certainly does benefit Red Hat).
The reasons might have been compelling if you actually knew what the hell you were talking about, and didn't labor under the completely erroneous base assumption that RPM is a "binary package format".
If that is indeed its purpose (and I don't dispute that), then it is already a miserable failure. Suse and Redhat RPMs that are LSB compliant still break from time to time when used on the other platform, so clearly LSB compliance alone isn't enough to guarantee compatability anyway.
Firstly, did you make sure that the packages you had trouble with were built against the same release of the LSB? The LSB has versions too, you know. Second, even if they were, that still is not a failure of the package format, but rather a failure of the packager. No technical spec or format can safeguard against human error.
By including RPM in the standard they've created a Red Hat specific loop everyone is expected to jump through,
In which way, even if the compatibility problems you've pointed out HAD been true, is it "Red Hat specific loop" more than Mandrake-specific or Suse-specific or specific to any other distro aspiring to LSB-compliance? This just sounds like paranoia to me.
yet the dubious benefits it purports to offer remain unrealized,
I think I've already established that you don't even know the benefits to begin with.
And that, again, brings us back to the remark which you "translated" into a personal insult. I asked you not to make a reply until you had your facts straight. You didn't listen, and as a result, I have now wasted time pointing out your factual errors, instead of perhaps being swayed by good arguments based on a solid understanding of the thing you're attacking. That could have been the case, had you listened to my request instead of "translating" it into something you thought I meant.
I could now list all the advantages that RPM provide over the "perfectly good archival approach", because even in the process of correcting your fact errors, I have only mentioned a few of them. But I won't. I asked you to check that out for yourself, but you didn't. I'm just going to tell you again to read up on the RPM format, and then make arguments for a tar-based system that provides all those benefits and tools.
1. A package format is expected to provide more than a mere compressed archive of files. Tar is an _archive_ format, not a _package_ format. I'd ask you kindly not to post a response to this comment until you understand the difference.
2. Using incompatability between rpm's produced by different distros as an argument against rpm as the LSB standard package format is really back-asswards, given that the one of the main points of the LSB is to _ensure_ distribution interoperability. An rpm made in adherence to the LSB spec will work on any LSB-compliant distribution.
As I see it, there are really only three measurements that have any relevance at all in the real world: the performance/$, the performance/W, and possibly the absolute maximum available performance, in case you have a Wallet of Unlimited Depth.
Performace/Clock may be of interest to chip designers and processor architecture students, but anyone who would buy a system that delivers less actual performance per $YOUR_LOCAL_CURRENCY just because its "faster per clock cycle" or "a better/purer/more beautiful CPU-architecture" is suffering from either a bad case of geekitis or devoutness to the Church of $BRAND.
Slashdot Mirror
The first few levels were great. It was actually so scary that somewhere early on, I had to press pause, remove my headphones and ask myself whether I really _enjoy_ being that scared while playing a game.
However, as the game went on, and your characters got more powerful, it really faltered. Also, some things really annoyed me, like finding ammo for your modern weapons lying around in the monastery when you travel back in time.
Undying could have been a really great game, but just fell short in a lot of ways.
My god... where do all these people who actually WERE "innocent" as children come from? Personally, I remember my wild childhood imagination thinking up scenes just as dirty as anything on the Evil Internet with my favorite comic book characters back when I was just 7-8 or so, and most of my friends back then were just as dirty-minded little bastards. Of course, sex and superheroes were both about equally "unreal" to us... Perhaps that's an excuse. :)
Although I'm definitely not going to question your basic statement of the Itanium being a terrible performer in "day-to-day tasks", compilation is probably a VERY unfair thing to use for benchmarking. Remember that one of the big problems with the EPIC architecture is that the compiler has all responsibility for optimizing the binary code in such a way that the maximum number of instructions can be exectuted in parallel. The process of compilation and optimization is hence probably massively more difficult and CPU-intensive than compilation for most other architectures. A fairer benchmark for compilation efficiency might be to do a cross-compile that produces x86 binaries.
"No attempt" indeed. I guess you are right, but only because IBM hasn't "attempted" to give Linux missing enterprise features, but rather simply DONE it.
Or did we all just hallucinate EVMS, the port of jfs, and the work IBM have done to help better SMP scalability on large systems? Sheesh.
There are VERY few "enterprise features" that commercial UNIX's have which linux doesn't, by now. Massive SSI multiprocessor scalability still isn't competitive with Irix or Solaris. AFAIK, there is still no support for hot-swapping memory in linux, even on hardware that supports that featre. But apart from that, I really can't think of much in the OS itself. Maturity of _documentation_ on the other hand is an area where some catching up is needed.
Here we go again with more confusion of OS and Hardware capability and other factual errors.
Linux handles more than 4 Gigs just fine, on 64-bit architectures. The x86 architecture on the other hand needs terrible cludges (PAE) to handle more than 4 Gigs. Solaris does even worse than Linux at this on the x86 architecture. That said, Solaris's VM in general is probably more roboust than the current mainline Linux VM.
As for Linux's SMP scaling, it scales fine up to 8 CPU's on Intel hardware. SGI claims that on their Altix architecture, it scales well up to 64 CPU's. Given that they are probably the only ones who have even tested Linux on a SSI computer of that scale, they are the only ones who have actual facts to say anything about its scaling. Would be nice to see some figures, though, for sure.
Solaris's "high performance, high reliability filesystems"? Oh you mean Veritas VXFS? That's an add-on product, not part of Solaris. A fairly expensive add-on product, at that. Veritas sells VXFS for Linux too, in case you wonder, but you rarely see it on Linux systems because the need is simply not as great.
Solaris's native filesystem UFS is a _joke_ for performance, and the journalling that is now available for it is a bolted-on kludge. Hence, any serious Solaris system is likely to have VXFS installed. The exception is when the machines are running applications that use raw partitions for their data, which is very common to see (Oracle, Tivoli Storage Manager, etc).
The XFS port for Linux is not a beta, and has not been for a long time. It is not yet part of the main kernel tree, but that doesn't make it in any way a "beta" or "untested". You would be surprised if you knew how many commercially sold NAS solutions run Linux with XFS under the hood. XFS is still an add-on product, but one that is in some ways more capable than VXFS, and on top of that, free.
Oh yea. And XFS supports ACLs on Linux and works well together with samba, which is part of the reason why its common in those NAS boxes.
Oh, if only.
I used to wonder why people heaped so much derision on CmdrTaco. He's like that annoying bastard who keeps setting the network printer to make two copies of everything as the default. Gah.
If it's anything like previous "gold" releases of MS products, it is "going gold" the way a lump of lead will "go gold" if you dip it in a solution of gold nitrate.... :)
ACL support for Linux has been available through SGI's XFS for a LONG time. SGI even provides pre-compiled kernels based on the Redhat kernels, for those who are scared of patching and compiling on their own.
Redhat 9 will have support for ACLs out of the box.
Small bit of trivia: the working title for the screenplay to Brazil was "1984½". However, I must say that despite the superficial similarities between Brazil and 1984, Brazil's literary parentage seems to have far more of Philip K. Dick's genes in it than George Orwell's.
Hell yes. My favorite movie of all time. Seen it eight times on the big screen, and probably around twenty or so times on the small screen, and I _still_ keep noticing little details in it that i've missed on previous viewings. Pure brilliance.
:)
As far as I'm concerned, no amount of appreciation for this movie would ever make it appreciated enough, so i guess it IS underappreciated, despite its huge cult following, classic-status and heaps of critical praise.
Actually, _most_ Quayle quotes are in fact real. However, funnily enough, his quotes tend to get "re-used" and re-attributed to Dubya and sometimes Gore. A lot of false Bush/Gore quotes will turn out to be real Quayle-quotes, if you do some digging.
There was (is?) actually a video sold with actually footage of Quayle delivering many of his most famous goofs.
I'd say it's definitely just familiarity.
For anyone confused about the "what goes where" in a Linux system, I warmly recommend taking a look at:
http://www.pathname.com/fhs/
which describes the Filesystem Hierarchy Standard, part of the Linux Standards Base. It should clear things up.
My favorite quote about the Turing test comes from Jaron Lanier:
"Only a fucked-up gay Englishman being tortured with hormone injections could possibly have supposed that consciousness was some kind of social exam you had to pass."
> mmm, freshly baked Athlon
:)
I baked an Athlon MP last spring. I can assure you the reaction to the smell is not "mmmm...."
Oh wait. Actually, I guess that was because I _fried_ it. Oh yea. Thats it.
In any case, it was the most _expensive_ bad smell I've ever smelled.
Ummm... I haven't played NWN, but claiming Morrowind isn't user-extensible just sounds VERY odd to me, given the nice construction kit that comes with the game when you buy it. There are some astonishingly high quality user-made extensions and modifications to Morrowind out there already.
The one thing that I find lacking in Morrowind mod-making is the scripting language, both in flexibility/power, and in documentation.
I once shot a piece of crumpled toilet paper right through a wooden fence on an inner-city backyard. I did use a cannon, and plenty of actual gunpowder though.The entire backyard was afterwards filled with a thick gunsmoke fog. I'm still surprised that neither the police nor the firedepartment showed up.
:)
I must add that although I lit the fuse on the cannon, I claim complete lack of responsibility for the air and noise pollution, as well as the damage to the fence. All blame shall lie with the crazy author of children's novels whose 50th birthday was the occasion for the abovementioned event.
Well, bleeding-edge addicts can simply chose RawHide as their redhat release of choice, and keep updating... updating... updating... ;)
Seriously, though - it's not that redhat _can't_ do it, its that they _won't_ do it - its not in line with their update policy. If you don't like RedHat's policy on updates, you should just stay away from that distro altogether, which is a perfectly valid choice. Just don't try to make it out as a KDE-specific issue.
...namely that RedHat generally never releases packages for new packages for _anything_ to current distributions, other than to fix bugs.
Now, I realize that the parent post in this case is not actually clear on whether the complaint is about packages for Redhat by the KDE project itself, or lack of KDE 3.1 packages from Redhat. Therefore, if the case is the former, I'll apologize for the somewhat angry tone below, and ask that it be considered reserved for the whiners
elsewhere in this thread.
I can't help but notice that KDE users seem to be demanding _privilieged_ treatement from Redhat, rather than merely the same treatment as other projects get.
Redhat have never provided packages for new gnome releases either. Redhat provides the same treatement to KDE as they give to every other app shipped with their distros - bugfixes only. New versions will be shipped with new distro releases.
And incidentally - If you check the updates for RedHat 8, you'll find they have released more fixes for KDE apps than they have for gnome. Of course you could argue that this might be because they shipped KDE in a buggier state. I can't comment since I don't use KDE. The fact, nevertheless, is worth noting.
Yes. I have.
Thank you for bringing it up. Now I will have flashbacks, and have to go back to therapy for a few months to get the nervous tics to stop.
More seriously, though, I shouldn't complain. It prolonged the project I was working on for many months, and I bill by the hour, the flakyness and flaws of Unicenter made me a lot of extra money.
Ultimately, it is possible to get Unicenter to work "well" on Linux, but if my experiences are typical, it takes a lot of time, money, and a crapload of workarounds before it does what its supposed to do.
I should, in fairness, point out that we were early adopters, had a very customized and not completely standard Linux setup for, and that we got CA to fix some bugs that we ran into. Future users of Unicenter on Linux may have a less bumpy ride.
... I would have modded you up.
Even "many", or "most" would have been okay. Either would have made it a valid opinion, instead of a blatantly sweeping generalization put forward in a way that makes it sound like you believe you're stating an absolute fact of general applicability on anyone who calls themselves a "skeptic".
It seems the fundamental problem, both with "believers" and "debunkers", that they confuse opinions, beliefs, or "current best models/theories" with hard facts and knowledge.
Personally, I think Sagan's "Demon Haunted World", Gardners "Facts and Fallacies in the Name of Science", as well as Wilson's "The New Inquisition" should all be required reading for those who wants to call themselves skeptics.
Please don't "translate" what people say - read what's written and reply to that. When I wrote my initial comment, I had some small hope that you'd actually counter with a compelling argument against RPMs being included in the LSB. You could have done that, and made me listen, if you'd shown you understood the additional requirements of a package format as opposed to plain tar, and more specifically, that you understood RPMs. However, you will not make me inclined to listen to your arguments when you consistently display complete lack of understanding of the RPM format, and make numerous factual errors. If you disapprove of the rpm format, you need to show you "know your enemy". The remark that you "translated" into a personal insult was a request for you to make sure you do that before you argue further.
.spec file, which you can use to produce an RPM.
You now instead continue to show you that you don't, but, against my better judgement, I'll respond to your arguments anyway.
The difference between an archive and a package is one of semantics.
I'll concede that there's no (to my knowledge) formal specification of "package" versus "archive". My definition is based on working with other package systems, under AIX and Solaris specifically. In case you didn't know, "tar" is not "standard package format" under those *nixes either, and if you think RPM is nasty, you should take a look at AIX's lpp. In any case, they all provide something more than a mere archive like cpio or tar.
A tarball can easilly contain all of the information necessary for a package to be built, indeed, most source tarballs these days do exactly that.
Interesting. In stating that a tarball CAN contain all information to BUILD a package, you inadvertently admit that tar itself _isn't_ a "package". And yes... indeed, today, many source tarballs today do contain all the information necessary to build a package - they contain a
But do not in the process favor one distribution over another,
I don't see how any distribution is favored over another. RPM is an open, well documented format. Any distribution can use it, and more distributions do use RPM than the competing DEB package format. I'm not entirely certain that RPM was chosen over DEB on purely technical reasons, or whether the "popularity" of the format played a part in the decision, but in either case, it was a format that was favored, not a distribution.
or chuck out a perfectly good archival approach
The archival approach is not "perfectly good". At the risk of sounding like a broken record, I have to say again that you seem woefully unaware of just how much more rpm does than a tar. Its not just dependency information.
that is a widely adopted, cross-platform standard for one that is obfuscated, inferior, less widely adopted, and less generic.
RPM is also cross-platform. You can get it for Solaris, AIX, and even non-unix platforms like OS/2. And there's a reason it's been ported, and I can assure you that the reason is not "because it sucks", or because the LSB dictates it. "Obfuscated" is simply untrue, "inferior" is merely opinion, which you consistently fail to support with any kind of factual or insightful arguments. Less generic is certainly true, but then, a package format has a somewhat more specific purpose than a mere archive.
Furthermore, not all distributions use binaries. Any standard that makes an assumption that all od (as LSB to some extent does, by adopting RPM) is inherently inadequate and broken.
I can only read this as further evidence of your complete ignorance about RPMs. RPM is designed to build the binary packages directly from source. If you don't want the binary RPMs pre-compiled by the distributor, you can grab the source RPMs and re-build them for your system, with whatever optimizations you want. A source RPM contains the pristine, untouched source tarball, keeping any patches a vendor might want to add to it separate while still automating and standardizing the patching procedure during a re-build. Since my own systems (and some of the systems i've designed for customers) are very heavily customized, I frequently do just that.
For example, many distributions, such as Gentoo and Source Mage, use source and build the installation dynamically.
There is nothing preventing doing an RPM-based distribution that does exactly that. In fact, I've toyed with the idea of doing that myself as an exercise. Gentoo is very cool, and their portage system looks nice. However, I have not yet delved into its intricacies deep enough to say whether it gives all the benefits that RPM does. Perhaps you can inform me of how to do the equivalent of "rpm -f file" or "rpm -Va" with Gentoo's system.
In short, there are compelling reasons why adding a binary package format, particularly one such as RPM, will not have a beneficial affect for Linux as a whole (though it certainly does benefit Red Hat).
The reasons might have been compelling if you actually knew what the hell you were talking about, and didn't labor under the completely erroneous base assumption that RPM is a "binary package format".
If that is indeed its purpose (and I don't dispute that), then it is already a miserable failure. Suse and Redhat RPMs that are LSB compliant still break from time to time when used on the other platform, so clearly LSB compliance alone isn't enough to guarantee compatability anyway.
Firstly, did you make sure that the packages you had trouble with were built against the same release of the LSB? The LSB has versions too, you know. Second, even if they were, that still is not a failure of the package format, but rather a failure of the packager. No technical spec or format can safeguard against human error.
By including RPM in the standard they've created a Red Hat specific loop everyone is expected to jump through,
In which way, even if the compatibility problems you've pointed out HAD been true, is it "Red Hat specific loop" more than Mandrake-specific or Suse-specific or specific to any other distro aspiring to LSB-compliance? This just sounds like paranoia to me.
yet the dubious benefits it purports to offer remain unrealized,
I think I've already established that you don't even know the benefits to begin with. And that, again, brings us back to the remark which you "translated" into a personal insult. I asked you not to make a reply until you had your facts straight. You didn't listen, and as a result, I have now wasted time pointing out your factual errors, instead of perhaps being swayed by good arguments based on a solid understanding of the thing you're attacking. That could have been the case, had you listened to my request instead of "translating" it into something you thought I meant.
I could now list all the advantages that RPM provide over the "perfectly good archival approach", because even in the process of correcting your fact errors, I have only mentioned a few of them. But I won't. I asked you to check that out for yourself, but you didn't. I'm just going to tell you again to read up on the RPM format, and then make arguments for a tar-based system that provides all those benefits and tools.
1. A package format is expected to provide more than a mere compressed archive of files. Tar is an _archive_ format, not a _package_ format. I'd ask you kindly not to post a response to this comment until you understand the difference.
2. Using incompatability between rpm's produced by different distros as an argument against rpm as the LSB standard package format is really back-asswards, given that the one of the main points of the LSB is to _ensure_ distribution interoperability. An rpm made in adherence to the LSB spec will work on any LSB-compliant distribution.
---
Death to the sarcasm-impaired!
As I see it, there are really only three measurements that have any relevance at all in the real world: the performance/$, the performance/W, and possibly the absolute maximum available performance, in case you have a Wallet of Unlimited Depth.
Performace/Clock may be of interest to chip designers and processor architecture students, but anyone who would buy a system that delivers less actual performance per $YOUR_LOCAL_CURRENCY just because its "faster per clock cycle" or "a better/purer/more beautiful CPU-architecture" is suffering from either a bad case of geekitis or devoutness to the Church of $BRAND.
-----------------
Death to the sarcasm-impaired!
Actually, no. This carbon rod is quite animate, at least as long as the chemical reaction is still progressing.
:)
And I really doubt the rod produced in this process would hold any shuttle doors shut...
Support & maintenance contracts on Sun hardware are brutally expensive. This may account for the difference.