Not without flaw, but the second best around - the best being NeXT. The irony is that, in going to the NeXT derived OS 10, Apple has chosen to saddle their users with the abomination known as Aqua, a hideous GUI no better than what MS offers, and far inferior to the prior MAC guis, let alone NeXT.
The issue of how much autonomy states have on issues the federal gov't considers important enough was settled, as the major
issue, in the Civil War. The Federal gov't won.
The victory of the aggressors proved nothing to anyone except those that accept the axiom of might makes right.
Haven't we been here before?
on
MAPS Sued Again
·
· Score: 3
Haven't we had this discussion before? Why not post with your handle instead of AC?
ORBS is listing you correctly - Manual do not test. SOME ORBS users choose to block that status along with know relays - others do not. It's up to the user - ORBS returns the correct code and the user determines which codes to block. Probably most ORBS users do choose to block that code. You know why? Because several extremely annoying high traffic relays are in there - thinking they will be real clever and sneak their spam through by preventing testing.
The probing they do won't harm your system in any way, and there's really no sane reason to tell them not to probe (unless you have something to hide) - many consider that probing a service, helping them to make sure their server is secure. If you insist on not being probed, that's your choice, but don't be surprised when that means that some users decline to accept mail from you.
Human lifespan on Mars may also be severely shortened.
Highly unlikely. Low g is far more likely to extend lifespan, not shorten it. Far less stress on the body - the circulatory system in particular will be able to work with far less effort and strain.
However, you are certainly correct that after adapting to a low G environment, returning to earth will be difficult to impossible. A few months is doable, but years? Natives born there? Not a chance. This is not necessarily a bad thing, however.
Well, personally I can't stand KDE as a "Desktop Environment" (or Gnome either, for that matter, I use WindowMaker) but both projects have produced some nice applications that I find useful. It's a bloody huge download for the odd app, and some of them have (at least in previous releases) had some major issues with unwanted "features" that you can't turn off (like the so-called "desktop handlers" built into the file managers - gmc at least will voluntarily exit completely, kfm in the past has required an explicit kill) and upgrading all the libraries can be painfull too - so I'll probably wait until the actual release to get it myself. But, if you have the storage space to spare, I do recommend getting it eventually - if only to see what they've been doing all this time. Not knowing what all has changed, comparing the earlier release to Gnome, some of the apps were definately better done - kpackage, ark, and ktop in particular. Having two sets of libraries is annoying and resource eating, but most X-boxen have the resources for it available.
I never had a ZX81, I had the TS2068, very similar but with more memory and colour. Very nice computer at the time, light years ahead of the competition back then, but a trifle out of date right now I fear. Still, a fun thing to play with. The system used the high ascii characters to represent basic keywords and one used keyboard shortcuts to input them, which was actually a very handy feature once you got used to it. And of course you could use basic commands to load and execute Z80 machine code for your most commonly called functions, allowing for some very fast programs. The peripherals were interesting too, there were endless loop tape drives for instance, that actually were pretty comparable to the much more expensive hard drives available in the day - high seek times, of course;^) but linear read/write functions were blindingly fast for the day.
This wouldn't be a bad machine at all for someone that wants to learn Z80 machine code (NOT assembler) - anyone out there working on embedded systems with that particular chip? But as for putting Linux on it, forget that right off, the Z80 has, what, 64k of address space if memory serves. No way you can run any sort of *nix on that - this isn't segment:offset, it's just one segment, period. Still, if you are clever and don't mind a little work, you can do some pretty amazing things in 64k.;^)
Anyone got info on the actual hardware behind it? I'd be interested in knowing how much trouble it would be to replace the ROMs with EPROMs, make it work with python or something like that instead of basic, maybe rewire it with an LCD display too... you might could make a really cool PDA or something out of one of these...
Let me add a little... a fairly balanced comparison of IIS and Apache is here
Keep in mind too, that Apache is not the only *nix web server out there, by any means. It's stable and well accepted, but it's not even trying to be the performance-above-all-else champ. Especially if you need a lot of dynamic content, you might want to look at AOL Server for instance.
Debian is a great choice for those comfortable with it, but for the type of user that really wants what RedHat offered, Caldera may be the best bet. All the points you brought up as to why some people would rather have RedHat than Debian are well dealt with by Caldera. Or SuSE, or Mandrake for that matter.
Flamebait? Why ARE you trying to destroy linux?
on
KBasic
·
· Score: 1
Not the best written post by an means, but it certainly isn't flamebait. The poster is just asking the question I know a lot of us are thinking. A couple of amok moderators here that need to read the guidelines again (and be slapped down hard on meta-mod as well.)
Basic is a brain-damaging product that's directly responsible for the mental handicapping of a good number of once-promising programmers. A lot of people find the IDE to be handy, I do not, but for those who do there are already clones of it out to handle real programming languages. Python, for instance, is comparable to VB for ease of learning and rapidity of development, but without the brain damage and limitations. Deliberately porting such an inferior product should raise some eyebrows and some questions. Moderating people down for asking those questions is wrong.
Ya know, it's posts like this, not to mention most of the other posts I've read so far, that really makes me wonder if anybody in this community really wants Linux to become the dominant desktop OS.
Who cares?
Really. I like linux because it works right. If making it work like that other dog of an OS is needed to make it "become the dominant desktop OS" then screw that, I sure as hell don't want it! If I wanted that crap I'd be using that crap already!
But projects like GNOME and KDE are necessary for they will help bring Linux to the masses.
And the people that work on those projects are perfectly entitled to spend their time and their talent where they see fit, however stupid I might think their choices are. But bringing Linux to the masses IS stupid. Let the masses come to Linux, when and if they learn to appreciate it. Dumbing it down and imitating the same bloated ugly monster that drove most linux users to try it in the first place is just plain insane. And useless.
I am not a big fan of Xfce - I tried it, I didn't particularly like it, I went back to WindowMaker. But a lot of people do like it, and that's the whole point - it serves the needs of some users a lot better than any of these damn stupid world dominations schemes will ever serve anyone. Except Bill Gates, of course. He's very well served by this whole mindset that computers have to cater to the lowest common denominator, and he has the bank account to prove it.
Compaq has released the compilers on linux now, which is a good short-term help. In the long run, gcc still needs to get up to speed for the platform, of course. This is an issue on all RISC architectures - all those lovely registers don't do much good if the compiler doesn't know about them.
For a replacement board you might try DGC - it's the only discount outlet for Alpha hardware I know about at the moment. They don't seem to be advertising the boards, but they do make their own, give em a call, it can't hurt. This guy in england sells boards, prices look real high though. You might check usenet too...
Yeah, Alphas are the likely competition for this crowd. Intel and AMD offerings have made a lot of advances, and the price is always great because of economies of scale, but for real workstations they still aren't real competitive. The Alpha, on the other hand, can stand toe to toe with SPARC and win. There are still reasons to buy Sun, of course, but only if you are talking about a really big box, say over 16 processors, running Solaris, not Linux. Linux performs a lot better than Solaris on uniprocessor boxes, but those 100 processor monster servers are better handled by Solaris still - that's what it's designed for.
And they are cheaper, best I can tell. About 3k sounds right for a base config - where do you see Suns cheaper than that? DCG is AFAIK one of the cheapest sources for SUN or Alpha hardware, their DCG L-1 with 128MB SDRAM 15.2GB storage, 600 Mhz Alpha, 2 MB Cache and all the other junk you expect on a Workstation (fast graphics, cdrom, NIC, etc.) sells for $3,850. Their Sun line starts at $3,595, with 9GB storage, a wimpier vidcard, and a 366mhz processor.
Sounds like a workable solution, given your hardware. I do wonder why you don't run vmware under a minimalistic Linux install rather than NT... but if it ain't broke don't fix it is as good a reason as any I suppose.
Re:Another one bites the du5t.
on
Kuro5hin Update
·
· Score: 2
Hrmm man, you do great art, but sometimes your posts strike me as a little nuts (also outspoken, which I normally like, except when it's nuts.) I agree with you that slashdot has gone downhill, and I share your frustration with some of the things that happen here. But... well, read on, and no offense is intended, but this has to be said.
Maybe you can explain why accepting a donated VALinux box makes K5 such a sellout that you feel compelled to denounce them and delink them, yet you are making this announcement on slashot which is actually owned by Andover? How much sense does that make?
Not to mention that your site is being hosted at the newly renamed ibiblio.org, running on money from RedHat themselves! Doesn't that make your post just a little hypocritical man? I mean, really, as long as RedHat doesn't try to influence your content, why should you be anything but thankful that they are underwriting your host? You shouldn't be... any more than the K5 team should have turned down VAs generous donation that helped them get up and running again...
Well I was not able to confirm this, although there is a lot of excellent humour and information, there are only three very brief mentions of MFS in the FreeBSD FAQ and none of them say anything about it resizing itself (although it might be inferrable from the fact that there is no mention of a flag to set it's size.)
I am curious as to what purpose this serves, however. If, as was my impression, FreeBSD has the same sort of dynamic caching that Linux uses, this would only add an extra layer of overhead - and hurt, not help, performance. Any FreeBSD folks want to enlighten me? Is there actually any situation where this is useful, or is it an artifact from a time when the caching algorithm really sucked, or what?;^)
Yeah, it's a dumb dog. Norton cache isn't much better. I disagree with sizing it to match the fat though, it's worthwhile at 2 megs.
Sector caching isn't horribly sophisticated, but it works. It's not that the file has to start and stop on sector boundaries - just that if it doesn't then some other stuff gets cached along with it. Which, of course, also happens with your hardware cache on your hard drive and (in some cases) disk controller . The real problem is just that the cache really doesn't know how to efficiently use more than a few megs of ram, let alone how to dynamically resize itself in response to system usage.
Of course you can. Hence the push towards "trusted client" hardware - that's the only way to eliminate that recourse. See this recent article on Technocrat.
But, while it's an option, it's not a very satisfactory one. It's a rather involved process, and I think there may be some loss issues, depending on your hardware and software setup perhaps. Could be wrong on that, maybe someone that's done some low level sound work can clarify that...
The reason ramdisks were so useful on your old Amiga was the absence of a good disk caching program. Linux has excellent dynamic disk caching, you're better off letting the kernel have that memory to play with instead of locking it into a ramdisk.
The results of the performance test that I ran were somewhat surprising - it seems the machine with the hard disk actually performed _better_ than the machine with the ramdisk.
This is exactly what I would suspect - I'm glad you posted this because I don't have time today to test it myself, but this is the result I would bet on.
The reason ramdisks aren't very useful with Linux is that the kernel has very good buffer/caching code - the effect is the same as having a ramdisk, except that the kernel can dynamically determine the contents based on actual usage. If you stick commonly used data on the ramdisk, you should be able to beat any caching algorithm, in theory, but this requires that there is certain data that you know will always be the most frequently accessed. In the real world, this rarely works out.
Say you put 16 megs of what you think is the most commonly used data on a ramdisk. Say further that you are right - over time, that 16 megs of data is the most frequently accessed data in your system, by far. If your box is hitting that data constantly, every bit of it, every few cycles, you might get a small performance boost. But more than likely some parts of it will not be hit all that frequently, and there are also likely to be times when it's not being hit at all. Put the same data on hard disk and let the kernel have the ram to manage, and it will manage things on the fly, responding to the actual demands of the system... it's very hard to beat.
Now, if the caching algorithm was more primitive, something like smartdrv for instance, then you can get a big performance boost out of the ramdisks. I used to play that game quite frequently. But this only worked because smartdrv really isn't very smart.
Well we aren't talking about RedHat here (it would be embarrasing for them to do this, and counterproductive as well - they designed RPM for the needs of the market they are going after, and it servest them fairly well) but Conectiva - a very different distribution designed for a different market. It is Conectiva that desires the apt functionality - RedHat does not. And yes, it would be a pain to switch over in midstream, but it would be equally a pain to try and hack RPM into doing things that it's designers consciously eschewed - AND THEN deal with the support nightmare created by using what amounts to a different architecture by the same name - i.e. other rpms will no longer work, but there will be no readily apparent clue to the users that they won't or why they won't.
When a fundamental decision was made in mistake, correcting it after is always a pain. Every package in the distribution will have to be remade either way. Compatibility with packages from other distributions will be broken either way..
The original poster seemed to be implying that we'd run into compatibility problems by making additions to RPM.
Not at all. What I'm saying is that the pre-existing packages are no advantage, because you'll have to make new ones to support the exapanded functionality. Which means that the primary motivation given for trying to make.rpm do these things instead of simply using.debs for their distribution is specious. Why re-invent the wheel?
These guys are making a fundamental mistake. What they want is to make.rpm act like.deb. This is not going to happen in any meaningful way..RPM and.deb are the result of fundamentally different design philosophies.
Yes, it is possible to make apt work with.rpms - but this will ONLY work satisfactorily with.rpms that are written with this in mind. The reasons given for using.rpm instead of.deb here basically boil down to there being more.rpms and more people using.rpm - but since all new.rpms will have to be produced to work with this system anyway, this is a false advantage. The installed base, the already existing library of.rpms, are going to be useless to this project in any case.
Obviously what they should do is just use.deb. The pre-existing base for.deb may be smaller than for.rpm, but it's infinitely larger than the pre-existing base of.rpms that contain the information needed to make this work, because that set doesn't exist at all.
Well, yeah, anyone putting a stock RedHat box on the net is an idiot. Anyone putting a stock *anything* box on the net is probably an idiot too.;^)
However it's true that RedHat is particularly bad - that doesn't mean Linux is bad - RedHat != Linux. If you want a Linux distro that is reasonably secure by default, give Slack a try. I know it gets a bad rap for supposedly being hard to install, but 1) if you are using OBSD already that's surely not a concern for you and 2) when I finally gave it a try, I found it to be little if any harder to install than RedHat or Mandrake were anyway. The selection of packages available with the native package management system is smaller than the RPM collection, of course, but it usually includes all the important stuff and is very up to date - check out LinuxMafia if you need something that isn't included. Plus you can always compile yourself, use the included rpm conversion tools (rpms usually but not always will work fine after a quick conversion) or even install RPM if you want to. YMMV, but I've found Slack to provide a very nice middle ground between OBSD and RedHat.
Hmm, as I understand Aqua is just a "desktop" using Quartz and DisplayPDF to do lowlevel drawing. I would rather
doubt that Aqua is written in PPC assembly or using other Mac specific stuff. It might be rather portable once
Quartz is ported.
You might be right, but even if so, there is no reason I have seen to think Apple would even consider doing that.
Slashdot Mirror
Not without flaw, but the second best around - the best being NeXT. The irony is that, in going to the NeXT derived OS 10, Apple has chosen to saddle their users with the abomination known as Aqua, a hideous GUI no better than what MS offers, and far inferior to the prior MAC guis, let alone NeXT.
The victory of the aggressors proved nothing to anyone except those that accept the axiom of might makes right.
Haven't we had this discussion before? Why not post with your handle instead of AC?
ORBS is listing you correctly - Manual do not test. SOME ORBS users choose to block that status along with know relays - others do not. It's up to the user - ORBS returns the correct code and the user determines which codes to block. Probably most ORBS users do choose to block that code. You know why? Because several extremely annoying high traffic relays are in there - thinking they will be real clever and sneak their spam through by preventing testing.
The probing they do won't harm your system in any way, and there's really no sane reason to tell them not to probe (unless you have something to hide) - many consider that probing a service, helping them to make sure their server is secure. If you insist on not being probed, that's your choice, but don't be surprised when that means that some users decline to accept mail from you.
Highly unlikely. Low g is far more likely to extend lifespan, not shorten it. Far less stress on the body - the circulatory system in particular will be able to work with far less effort and strain.
However, you are certainly correct that after adapting to a low G environment, returning to earth will be difficult to impossible. A few months is doable, but years? Natives born there? Not a chance. This is not necessarily a bad thing, however.
Well, personally I can't stand KDE as a "Desktop Environment" (or Gnome either, for that matter, I use WindowMaker) but both projects have produced some nice applications that I find useful. It's a bloody huge download for the odd app, and some of them have (at least in previous releases) had some major issues with unwanted "features" that you can't turn off (like the so-called "desktop handlers" built into the file managers - gmc at least will voluntarily exit completely, kfm in the past has required an explicit kill) and upgrading all the libraries can be painfull too - so I'll probably wait until the actual release to get it myself. But, if you have the storage space to spare, I do recommend getting it eventually - if only to see what they've been doing all this time. Not knowing what all has changed, comparing the earlier release to Gnome, some of the apps were definately better done - kpackage, ark, and ktop in particular. Having two sets of libraries is annoying and resource eating, but most X-boxen have the resources for it available.
I never had a ZX81, I had the TS2068, very similar but with more memory and colour. Very nice computer at the time, light years ahead of the competition back then, but a trifle out of date right now I fear. Still, a fun thing to play with. The system used the high ascii characters to represent basic keywords and one used keyboard shortcuts to input them, which was actually a very handy feature once you got used to it. And of course you could use basic commands to load and execute Z80 machine code for your most commonly called functions, allowing for some very fast programs. The peripherals were interesting too, there were endless loop tape drives for instance, that actually were pretty comparable to the much more expensive hard drives available in the day - high seek times, of course ;^) but linear read/write functions were blindingly fast for the day.
This wouldn't be a bad machine at all for someone that wants to learn Z80 machine code (NOT assembler) - anyone out there working on embedded systems with that particular chip? But as for putting Linux on it, forget that right off, the Z80 has, what, 64k of address space if memory serves. No way you can run any sort of *nix on that - this isn't segment:offset, it's just one segment, period. Still, if you are clever and don't mind a little work, you can do some pretty amazing things in 64k. ;^)
Anyone got info on the actual hardware behind it? I'd be interested in knowing how much trouble it would be to replace the ROMs with EPROMs, make it work with python or something like that instead of basic, maybe rewire it with an LCD display too... you might could make a really cool PDA or something out of one of these...
Let me add a little... a fairly balanced comparison of IIS and Apache is here
Keep in mind too, that Apache is not the only *nix web server out there, by any means. It's stable and well accepted, but it's not even trying to be the performance-above-all-else champ. Especially if you need a lot of dynamic content, you might want to look at AOL Server for instance.
Debian is a great choice for those comfortable with it, but for the type of user that really wants what RedHat offered, Caldera may be the best bet. All the points you brought up as to why some people would rather have RedHat than Debian are well dealt with by Caldera. Or SuSE, or Mandrake for that matter.
Not the best written post by an means, but it certainly isn't flamebait. The poster is just asking the question I know a lot of us are thinking. A couple of amok moderators here that need to read the guidelines again (and be slapped down hard on meta-mod as well.)
Basic is a brain-damaging product that's directly responsible for the mental handicapping of a good number of once-promising programmers. A lot of people find the IDE to be handy, I do not, but for those who do there are already clones of it out to handle real programming languages. Python, for instance, is comparable to VB for ease of learning and rapidity of development, but without the brain damage and limitations. Deliberately porting such an inferior product should raise some eyebrows and some questions. Moderating people down for asking those questions is wrong.
Who cares?
Really. I like linux because it works right. If making it work like that other dog of an OS is needed to make it "become the dominant desktop OS" then screw that, I sure as hell don't want it! If I wanted that crap I'd be using that crap already!
And the people that work on those projects are perfectly entitled to spend their time and their talent where they see fit, however stupid I might think their choices are. But bringing Linux to the masses IS stupid. Let the masses come to Linux, when and if they learn to appreciate it. Dumbing it down and imitating the same bloated ugly monster that drove most linux users to try it in the first place is just plain insane. And useless.
I am not a big fan of Xfce - I tried it, I didn't particularly like it, I went back to WindowMaker. But a lot of people do like it, and that's the whole point - it serves the needs of some users a lot better than any of these damn stupid world dominations schemes will ever serve anyone. Except Bill Gates, of course. He's very well served by this whole mindset that computers have to cater to the lowest common denominator, and he has the bank account to prove it.
Compaq has released the compilers on linux now, which is a good short-term help. In the long run, gcc still needs to get up to speed for the platform, of course. This is an issue on all RISC architectures - all those lovely registers don't do much good if the compiler doesn't know about them.
For a replacement board you might try DGC - it's the only discount outlet for Alpha hardware I know about at the moment. They don't seem to be advertising the boards, but they do make their own, give em a call, it can't hurt. This guy in england sells boards, prices look real high though. You might check usenet too...
Yeah, Alphas are the likely competition for this crowd. Intel and AMD offerings have made a lot of advances, and the price is always great because of economies of scale, but for real workstations they still aren't real competitive. The Alpha, on the other hand, can stand toe to toe with SPARC and win. There are still reasons to buy Sun, of course, but only if you are talking about a really big box, say over 16 processors, running Solaris, not Linux. Linux performs a lot better than Solaris on uniprocessor boxes, but those 100 processor monster servers are better handled by Solaris still - that's what it's designed for.
And they are cheaper, best I can tell. About 3k sounds right for a base config - where do you see Suns cheaper than that? DCG is AFAIK one of the cheapest sources for SUN or Alpha hardware, their DCG L-1 with 128MB SDRAM 15.2GB storage, 600 Mhz Alpha, 2 MB Cache and all the other junk you expect on a Workstation (fast graphics, cdrom, NIC, etc.) sells for $3,850. Their Sun line starts at $3,595, with 9GB storage, a wimpier vidcard, and a 366mhz processor.
Sounds like a workable solution, given your hardware. I do wonder why you don't run vmware under a minimalistic Linux install rather than NT... but if it ain't broke don't fix it is as good a reason as any I suppose.
Hrmm man, you do great art, but sometimes your posts strike me as a little nuts (also outspoken, which I normally like, except when it's nuts.) I agree with you that slashdot has gone downhill, and I share your frustration with some of the things that happen here. But... well, read on, and no offense is intended, but this has to be said.
Maybe you can explain why accepting a donated VALinux box makes K5 such a sellout that you feel compelled to denounce them and delink them, yet you are making this announcement on slashot which is actually owned by Andover? How much sense does that make?
Not to mention that your site is being hosted at the newly renamed ibiblio.org, running on money from RedHat themselves! Doesn't that make your post just a little hypocritical man? I mean, really, as long as RedHat doesn't try to influence your content, why should you be anything but thankful that they are underwriting your host? You shouldn't be... any more than the K5 team should have turned down VAs generous donation that helped them get up and running again...
Well I was not able to confirm this, although there is a lot of excellent humour and information, there are only three very brief mentions of MFS in the FreeBSD FAQ and none of them say anything about it resizing itself (although it might be inferrable from the fact that there is no mention of a flag to set it's size.)
I am curious as to what purpose this serves, however. If, as was my impression, FreeBSD has the same sort of dynamic caching that Linux uses, this would only add an extra layer of overhead - and hurt, not help, performance. Any FreeBSD folks want to enlighten me? Is there actually any situation where this is useful, or is it an artifact from a time when the caching algorithm really sucked, or what? ;^)
Yeah, it's a dumb dog. Norton cache isn't much better. I disagree with sizing it to match the fat though, it's worthwhile at 2 megs.
Sector caching isn't horribly sophisticated, but it works. It's not that the file has to start and stop on sector boundaries - just that if it doesn't then some other stuff gets cached along with it. Which, of course, also happens with your hardware cache on your hard drive and (in some cases) disk controller . The real problem is just that the cache really doesn't know how to efficiently use more than a few megs of ram, let alone how to dynamically resize itself in response to system usage.
Of course you can. Hence the push towards "trusted client" hardware - that's the only way to eliminate that recourse. See this recent article on Technocrat.
But, while it's an option, it's not a very satisfactory one. It's a rather involved process, and I think there may be some loss issues, depending on your hardware and software setup perhaps. Could be wrong on that, maybe someone that's done some low level sound work can clarify that...
The reason ramdisks were so useful on your old Amiga was the absence of a good disk caching program. Linux has excellent dynamic disk caching, you're better off letting the kernel have that memory to play with instead of locking it into a ramdisk.
This is exactly what I would suspect - I'm glad you posted this because I don't have time today to test it myself, but this is the result I would bet on.
The reason ramdisks aren't very useful with Linux is that the kernel has very good buffer/caching code - the effect is the same as having a ramdisk, except that the kernel can dynamically determine the contents based on actual usage. If you stick commonly used data on the ramdisk, you should be able to beat any caching algorithm, in theory, but this requires that there is certain data that you know will always be the most frequently accessed. In the real world, this rarely works out.
Say you put 16 megs of what you think is the most commonly used data on a ramdisk. Say further that you are right - over time, that 16 megs of data is the most frequently accessed data in your system, by far. If your box is hitting that data constantly, every bit of it, every few cycles, you might get a small performance boost. But more than likely some parts of it will not be hit all that frequently, and there are also likely to be times when it's not being hit at all. Put the same data on hard disk and let the kernel have the ram to manage, and it will manage things on the fly, responding to the actual demands of the system... it's very hard to beat.
Now, if the caching algorithm was more primitive, something like smartdrv for instance, then you can get a big performance boost out of the ramdisks. I used to play that game quite frequently. But this only worked because smartdrv really isn't very smart.
Well we aren't talking about RedHat here (it would be embarrasing for them to do this, and counterproductive as well - they designed RPM for the needs of the market they are going after, and it servest them fairly well) but Conectiva - a very different distribution designed for a different market. It is Conectiva that desires the apt functionality - RedHat does not. And yes, it would be a pain to switch over in midstream, but it would be equally a pain to try and hack RPM into doing things that it's designers consciously eschewed - AND THEN deal with the support nightmare created by using what amounts to a different architecture by the same name - i.e. other rpms will no longer work, but there will be no readily apparent clue to the users that they won't or why they won't.
When a fundamental decision was made in mistake, correcting it after is always a pain. Every package in the distribution will have to be remade either way. Compatibility with packages from other distributions will be broken either way..
Not at all. What I'm saying is that the pre-existing packages are no advantage, because you'll have to make new ones to support the exapanded functionality. Which means that the primary motivation given for trying to make .rpm do these things instead of simply using .debs for their distribution is specious. Why re-invent the wheel?
These guys are making a fundamental mistake. What they want is to make .rpm act like .deb. This is not going to happen in any meaningful way. .RPM and .deb are the result of fundamentally different design philosophies.
Yes, it is possible to make apt work with .rpms - but this will ONLY work satisfactorily with .rpms that are written with this in mind. The reasons given for using .rpm instead of .deb here basically boil down to there being more .rpms and more people using .rpm - but since all new .rpms will have to be produced to work with this system anyway, this is a false advantage. The installed base, the already existing library of .rpms, are going to be useless to this project in any case.
Obviously what they should do is just use .deb. The pre-existing base for .deb may be smaller than for .rpm, but it's infinitely larger than the pre-existing base of .rpms that contain the information needed to make this work, because that set doesn't exist at all.
Well, yeah, anyone putting a stock RedHat box on the net is an idiot. Anyone putting a stock *anything* box on the net is probably an idiot too. ;^)
However it's true that RedHat is particularly bad - that doesn't mean Linux is bad - RedHat != Linux. If you want a Linux distro that is reasonably secure by default, give Slack a try. I know it gets a bad rap for supposedly being hard to install, but 1) if you are using OBSD already that's surely not a concern for you and 2) when I finally gave it a try, I found it to be little if any harder to install than RedHat or Mandrake were anyway. The selection of packages available with the native package management system is smaller than the RPM collection, of course, but it usually includes all the important stuff and is very up to date - check out LinuxMafia if you need something that isn't included. Plus you can always compile yourself, use the included rpm conversion tools (rpms usually but not always will work fine after a quick conversion) or even install RPM if you want to. YMMV, but I've found Slack to provide a very nice middle ground between OBSD and RedHat.
You might be right, but even if so, there is no reason I have seen to think Apple would even consider doing that.
And just what are you doing to help?