Oh, also, if the good compiler technology were to become available to the free software community as a whole, OS projects like (Free|Net|Open)BSD would benefit, as well.
The state of other compiler ports could be advanced, too. I'm sure there are a few optimization tricks in the GEM compilers that could be generally applied. That wouldn't necessarily help out Compaq/Digital, of course, but their "cool factor" would be ratcheted up yet another notch.
The better everything (yes, _everything_) runs on the Alpha, the more prestige Digital/Compaq gets. Their platform is seen to be faster doing everything (yes, _everything_) if everything is compiled with a good compiler. This _benefits_ DigiCompaqItal (stolen from someone else).
I'm not an RMS-loving free software nut, but something like a compiler is best if open (at least the parts of it that would make it possible to rearrange the call stack, pass in out-of-band data, emit variously named segments, and so on).
When did I say anything about Linux vis a vis the compiler suite? What I said was, I'd like to be able to modify the code of the compiler to do the things _I'd_ like it to do, by way of some research I'm doing. The result of this would be able to run at optimal speed on an Alpha if Digital's compilers/instruction scheduling/etc. were available in source-form.
Then I could _do_ the things I want to do, and learn what I want to learn, and have the ability to make something really cool on what is currently the most kick-ass platform out there.
Wow. What an enlightened post. You are obviously vastly more intelligent and superior in every way to this 'netbsd luhsur'.
Why do you consider *BSD an enemy? If you look at the code (and that's what it's all about, right?), you'll see that *BSD has contributed a lot to Linsux over the years, and will continue to contribute (their nice license makes that possible).
Why do you bash those with whom you _should_ be cooperating?
Oh, I forgot. Maybe you're just too 'l33t to have noticed.
It is worthless to me, as an OS-geek-researcher-hobbyist-type, to have a compiler whose source cannot be mucked about with in order to make it do things like rearranging the call stack, producing different section names, or producing slightly different symbols in its output.
Yes, it's a rather specific and highly unusual task, but one worth making possible. Especially if you want to sell hardware. Nothing is gained in this area by making stuff like this proprietary, and in the long run you might be shooting yourself in the foot by making it impossible or difficult for the next Linus Torvalds to tweak things in the way your compiler produces its output to make it meet his needs. Your hardware platform suffers.
Proprietary compilers are, in the end, a losing proposition for hardware vendors. If Digital are going to make cheap compilers available for Linux/Alpha, then more power to them. If they are going to begin integrating their best hacks into egcs, as someone in a different post said, then they've got my fullest support. Hell, I'll even buy one of the Linux compilers if it would be productive to do so in order to get that stuff into the egcs compiler (where _ALL_ can use it, to the eternal benefit of Digital).
As far as I can tell, the only reason NetBSD doesn't get more credit for their accomplishments is that, in some areas, they haven't accomplished what they've needed to.
Case in point: SMP. Case in point: Unified Buffer Cache. Case in point: Journal File System.
That NBSD will run on an 8400, and that it is chock-full of RAIDframe goodness, and that it is in many other ways very cool and very well done is a testament to the project. The userland, especially the compiler tool chain, is very nice indeed.
Why, though, in God's name, would I even *want* to run NetBSD on my 8400, which most likely has at least two CPUs? Why would I want to run NetBSD on that system, when DU has a better buffer cache setup (with AdvFS, that is... AFAIK, the UFS stuff still has a segmented buffer cache, which is silly considering the amount of money Digital must put into development of that Unix)? What on earth would possess me to run NetBSD on my 8400 when I need that system to serve files, and the filesystems have less of a chance of being recovered than a DU system using AdvFS? Oh, and not to mention, does NetBSD have logical volume management?
I'm not meaning to slam NetBSD here, because most of what I've said above also applies to Linsux, but these are the hurdles that must be lept in order for NetBSD to get its message across.
Let's say I decide to write the Next Big Thing [tm] in operating systems. This new jewel is the Perfect Operating System [tm], and will solve all problems for all people for all times. Now, suppose I want this wonder of modern technology to be free software. Further, because it is so radically different, binary formats and the like from a completely inferior OS, like Unix or Linux, simply won't fit. How do I get the maximum performance from an Alpha (and since this new operating system is The Bomb [tm], support for it will far outstrip anything else in existence)?
I want to be able to do research with a good compiler, to write my own binary organization standards, to fiddle with the stack and do neat-o things to tailor the system to my own exacting specifications. I have to, in that case, use the GNU compiler suite. Especially since my new OS project will run on more platforms than Linux and NetBSD combined.
If I use the GNU compilers, and tailor my code to use features of that compiler suite (and there will have to be compiler-dependent code, that can't be avoided if you want some of the nicest code-generation features), then it becomes very difficult to port all this stuff over to a different compiler for each different platform. I simply won't do it, and performance will suffer on the Alpha.
Thus, having a compiler that can't be taught new tricks by curious researchers will have sounded the death-knell for the Alpha processor.
... but it's not actually 5000 kids killed by guns. It's 5000 kids killed by morons wielding guns. Be those morons kids themselves, or no, those are the facts.
Guns don't kill people. People kill people.
Too much sensationalism. The only way to combat this type of thing is via EDUCATION, EDUCATION, EDUCATION. One of these days, hopefully, people will figure out that media is not there to disseminate news. Media exists to further the cause of media, just like bureaucracy exists to further its own existence. Sensationalism, hype, and demagoguery are the tools of media and politicians, and none of it is good for us. We all lose our rights and freedoms when the ignorant are cowed by these tyrannical forces.
Makes me want to live in a tar-paper shack in Montana and build bombs. Also makes me glad I don't own a bloody television.
I know this. It seems that a bit of sarcasm went undetected here.
The point I'm trying to make is that we have no will to do things the right way once and for all. If we are to be involved in this Yugoslavia mess, we should do it formally.
"Police Action" is a farce. Call a spade a spade. If it is war, then it's war, and we should declare it as such.
If we want a police action, then we should send in the police, right? I don't doubt that the parties involved would like the music, but I don't think it would solve any problems. Instead, we send in the military, an institution whose sole purposes are to kill people and break things, and ask them to keep peace! It's nonsense!
Let's arm the Albanians that have fled into Macedonia and Albania, you know, all those 640K refugees?
640K should be enough for anyone, right?
Anyway, let's use all our technology to feed, clothe, and equip these people, then send them back in to fight for themselves. We can keep them supplied with no problems, and then _they_ get to shoulder the responsibility for their own lives.
Let's set up a perimeter around Kosovo/Serbia and let them duke it out inside. If anyone, _anyone_ crosses the border, they are killed indiscriminately.
That, to me, sounds like a just and fair solution. Further intervention on our part need not be taken. This is a civil war. Maybe we should supply the Serbs with arms and such, too. Let the winner be decided there, once and for all.
The one true answer is to simply kill everyone in the region. A few nicely placed neutron bombs should do the trick. Then, once the radiation has subsided, the whole region should be nicely inhabitable by more reasonable folk.
Didn't the Albanians turn in the Serbs to Hitler during WWII, when they had most of the power (the Serbs didn't really regain their power until after the Soviet Union faded away, and Yugoslavia broke up)? I can't really say I blame the Serbs for their aggression, based on this perspective.
No, I used that term about 2 years ago in a discussion with some friends. We were discussing a licensing scheme for open software that wasn't so GNU-centric for some software we were/are going to write.
Agreed, installation on a bare drive is probably easier for someone not knowledgeable about computers, assuming the hardware is correctly set up for CD-booting and proper detection. There's one less level of crap to wade through to get the system up and running if you don't have to make allowances for another OS.
However, that wasn't the case in either of these articles, and it won't be the case for the vast majority of new linux installs in the near (or even the relatively distant) future.
I agree that it would be great to have Linux pre-installed, and that that will have to happen before Linux is palatable to the public at large. The fact is, though, that most installs will be of the type written about here.
There must be easy coexistance if Linux is to subsume the Windows installed base.
Without helping at all, sit your mom down in front of a PC with Windows installed, give her your favorite off-the-shelf Linux help/install guide, and have her install the OS.
Remember, give her no assistance.
In the general case, if she manages to do it, it will take a long time and be a very frustrating experience, even with such distros as RedHat and SuSE. That is one of the hurdles faced with Linux being on the desktop.
Given that it's just as hard and frustrating for me to install '98 (three hours, three tries to get the FS set up the way *I* want it, much cussing and fussing), usually some variant of DOS/Windows is already installed. That is your customer base. Now, philosophical debates about whether you want users of that stripe here or not, this is the general computing public.
Don't go too hard on these writers, especially the English-major chick. Linux is a bit daunting if all you know how to do is point and drool at a preinstalled Windows love-fest.
It's the patch issue that bugs me, actually. Let's just say I want to set up an integrated OS build tree (something like (O|F)BSD), wherein all that is included in the system is available in snapshot form from a central CVS repository. These sources include the latest and greatest version of the Qt library, since KDE is the desktop of choice in my hypothetical world. This is easy to manage, as it gives the Qt source tree adapted to my particular scheme of doing things a common base, and maintainers of that part of the tree a common place from which to work.
I don't mind submitting patches to Troll Tech, as I feel it is my duty, and makes the whole thing go much more smoothly in the long run. However, I want as many people to be able to download or upgrade, in one shot, the sources to my whizbang OS (including the Qt libs), compile it, install it, run it, debug it, live it, love it, learn it, and have children with it (okay, maybe not that extreme).
Making the patches available as an add-on to the Qt libraries wouldn't be a big deal, and the application of said patches could be handled by a makefile, but that's an extra bunch of stuff for developers to have to do when working on my neat-o keen spanking new OS-thingy.
I don't have a problem with Troll's license. It's a good one. I don't see myself using Qt in my shiny new OS for the reasons listed above. It's a pain in the rear to deal with from that standpoint.
Some folks can never stop bitching and pissing and moaning about "free/not-free/blah". If the Harmony project gets off the ground and, maybe with the help of RedHat's code-money, catches the Qt toolset as far as interface goes, KDE can use that to finally be "free" enough for all the crack-heads who like to complain about it.
If KDE is termed "free" by _everyone_, there will be no reason not to use it. It will get more exposure to all developers, and an open base for the toolkit may allow an eventual merging with the GNOME project (for things like a common ORB, common themeability, etc.).
IMNSHO, a "free" Qt toolkit is the only way to solve all these problems and stop people's whinging and griping and get some real work done.
There was a story once, I think it may have been on the new Twilight Zone (it's been a few years since I've seen it), where everyone had on them at all times at least three ways to keep in touch. Everyone had a mobile phone, a personal fax, a pager, and a couple other devices.
One guy got committed to a looney bin for having gone insane and pouring a chocolate malt into his fax machine, so rampant and entrenched was this stuff. At the end of the show, the doc that committed him couldn't get a minute to himself to think in peace, and ended up sending his secretary out for a chocolate malt.
I thought that was a beautiful statement about the world and the way I saw it headed back then. It's still applicable today.
When I'm away from the phone, it's because I _want_ to be away from it. When I'm driving, I don't _want_ to talk on the phone. It's dangerous, and stupid.
AFAIK, the only things that couldn't be easily done away with are the compilers. I've already written a proof-of-concept mini-libc (which has unfortunately disappeared over the course of time). Be it known, too, that the BSDs have perfectly reasonable libcs, rivalling even the vaunted *wretch* GNU libc.
If there was a different source of compilers that were at least reasonable, I'd use them to port the OpenBSD userland over to Linsux. That'd yank RMS' chain.;)
> I would say that an OS vendor should be under legal obligation to prove that their product is _not_ defective
No. You can't logically prove a negative.
> a money-back guarantee if it doesn't work.
That I can handle. Of course, given terms like "this software is not guaranteed to be suited for any particular purpose", yada yada yada, a vendor can skirt that issue easily.
Slashdot Mirror
Oh, also, if the good compiler technology were to become available to the free software community as a whole, OS projects like (Free|Net|Open)BSD would benefit, as well.
The state of other compiler ports could be advanced, too. I'm sure there are a few optimization tricks in the GEM compilers that could be generally applied. That wouldn't necessarily help out Compaq/Digital, of course, but their "cool factor" would be ratcheted up yet another notch.
The better everything (yes, _everything_) runs on the Alpha, the more prestige Digital/Compaq gets. Their platform is seen to be faster doing everything (yes, _everything_) if everything is compiled with a good compiler. This _benefits_ DigiCompaqItal (stolen from someone else).
I'm not an RMS-loving free software nut, but something like a compiler is best if open (at least the parts of it that would make it possible to rearrange the call stack, pass in out-of-band data, emit variously named segments, and so on).
--Corey
No, you're wrong.
When did I say anything about Linux vis a vis the compiler suite? What I said was, I'd like to be able to modify the code of the compiler to do the things _I'd_ like it to do, by way of some research I'm doing. The result of this would be able to run at optimal speed on an Alpha if Digital's compilers/instruction scheduling/etc. were available in source-form.
Then I could _do_ the things I want to do, and learn what I want to learn, and have the ability to make something really cool on what is currently the most kick-ass platform out there.
Now, where is the gross overstatement in that?
--Corey
> fsck off, netbsd luhsur.
Wow. What an enlightened post. You are obviously vastly more intelligent and superior in every way to this 'netbsd luhsur'.
Why do you consider *BSD an enemy? If you look at the code (and that's what it's all about, right?), you'll see that *BSD has contributed a lot to Linsux over the years, and will continue to contribute (their nice license makes that possible).
Why do you bash those with whom you _should_ be cooperating?
Oh, I forgot. Maybe you're just too 'l33t to have noticed.
--Corey
Perhaps I should qualify this, then.
It is worthless to me, as an OS-geek-researcher-hobbyist-type, to have a compiler whose source cannot be mucked about with in order to make it do things like rearranging the call stack, producing different section names, or producing slightly different symbols in its output.
Yes, it's a rather specific and highly unusual task, but one worth making possible. Especially if you want to sell hardware. Nothing is gained in this area by making stuff like this proprietary, and in the long run you might be shooting yourself in the foot by making it impossible or difficult for the next Linus Torvalds to tweak things in the way your compiler produces its output to make it meet his needs. Your hardware platform suffers.
Proprietary compilers are, in the end, a losing proposition for hardware vendors. If Digital are going to make cheap compilers available for Linux/Alpha, then more power to them. If they are going to begin integrating their best hacks into egcs, as someone in a different post said, then they've got my fullest support. Hell, I'll even buy one of the Linux compilers if it would be productive to do so in order to get that stuff into the egcs compiler (where _ALL_ can use it, to the eternal benefit of Digital).
--Corey
As far as I can tell, the only reason NetBSD doesn't get more credit for their accomplishments is that, in some areas, they haven't accomplished what they've needed to.
Case in point: SMP.
Case in point: Unified Buffer Cache.
Case in point: Journal File System.
That NBSD will run on an 8400, and that it is chock-full of RAIDframe goodness, and that it is in many other ways very cool and very well done is a testament to the project. The userland, especially the compiler tool chain, is very nice indeed.
Why, though, in God's name, would I even *want* to run NetBSD on my 8400, which most likely has at least two CPUs? Why would I want to run NetBSD on that system, when DU has a better buffer cache setup (with AdvFS, that is... AFAIK, the UFS stuff still has a segmented buffer cache, which is silly considering the amount of money Digital must put into development of that Unix)? What on earth would possess me to run NetBSD on my 8400 when I need that system to serve files, and the filesystems have less of a chance of being recovered than a DU system using AdvFS? Oh, and not to mention, does NetBSD have logical volume management?
I'm not meaning to slam NetBSD here, because most of what I've said above also applies to Linsux, but these are the hurdles that must be lept in order for NetBSD to get its message across.
--Corey
It was meant to be a rant, but...
Please, dissect what I've said and refute my faulty logic point by point. If you cannot, then your claim that my logic is faulty is insubstantial.
--Corey
Yes, worthless.
Let's say I decide to write the Next Big Thing [tm] in operating systems. This new jewel is the Perfect Operating System [tm], and will solve all problems for all people for all times. Now, suppose I want this wonder of modern technology to be free software. Further, because it is so radically different, binary formats and the like from a completely inferior OS, like Unix or Linux, simply won't fit. How do I get the maximum performance from an Alpha (and since this new operating system is The Bomb [tm], support for it will far outstrip anything else in existence)?
I want to be able to do research with a good compiler, to write my own binary organization standards, to fiddle with the stack and do neat-o things to tailor the system to my own exacting specifications. I have to, in that case, use the GNU compiler suite. Especially since my new OS project will run on more platforms than Linux and NetBSD combined.
If I use the GNU compilers, and tailor my code to use features of that compiler suite (and there will have to be compiler-dependent code, that can't be avoided if you want some of the nicest code-generation features), then it becomes very difficult to port all this stuff over to a different compiler for each different platform. I simply won't do it, and performance will suffer on the Alpha.
Thus, having a compiler that can't be taught new tricks by curious researchers will have sounded the death-knell for the Alpha processor.
--Corey
... but it's not actually 5000 kids killed by guns. It's 5000 kids killed by morons wielding guns. Be those morons kids themselves, or no, those are the facts.
Guns don't kill people. People kill people.
Too much sensationalism. The only way to combat this type of thing is via EDUCATION, EDUCATION, EDUCATION. One of these days, hopefully, people will figure out that media is not there to disseminate news. Media exists to further the cause of media, just like bureaucracy exists to further its own existence. Sensationalism, hype, and demagoguery are the tools of media and politicians, and none of it is good for us. We all lose our rights and freedoms when the ignorant are cowed by these tyrannical forces.
Makes me want to live in a tar-paper shack in Montana and build bombs. Also makes me glad I don't own a bloody television.
--Corey
I know this. It seems that a bit of sarcasm went undetected here.
The point I'm trying to make is that we have no will to do things the right way once and for all. If we are to be involved in this Yugoslavia mess, we should do it formally.
"Police Action" is a farce. Call a spade a spade. If it is war, then it's war, and we should declare it as such.
If we want a police action, then we should send in the police, right? I don't doubt that the parties involved would like the music, but I don't think it would solve any problems. Instead, we send in the military, an institution whose sole purposes are to kill people and break things, and ask them to keep peace! It's nonsense!
--Corey
One question:
The president has claimed that the three soldiers captured and detained in Kosovo/Serbia/whatever are Prisoners Of War.
Does this, then, mean that this is a war?
If so, why have we not formally declared war on Serbia?
--Corey
How about this:
Let's arm the Albanians that have fled into Macedonia and Albania, you know, all those 640K refugees?
640K should be enough for anyone, right?
Anyway, let's use all our technology to feed, clothe, and equip these people, then send them back in to fight for themselves. We can keep them supplied with no problems, and then _they_ get to shoulder the responsibility for their own lives.
Let's set up a perimeter around Kosovo/Serbia and let them duke it out inside. If anyone, _anyone_ crosses the border, they are killed indiscriminately.
That, to me, sounds like a just and fair solution. Further intervention on our part need not be taken. This is a civil war. Maybe we should supply the Serbs with arms and such, too. Let the winner be decided there, once and for all.
--Corey
The one true answer is to simply kill everyone in the region. A few nicely placed neutron bombs should do the trick. Then, once the radiation has subsided, the whole region should be nicely inhabitable by more reasonable folk.
--Corey
Didn't the Albanians turn in the Serbs to Hitler during WWII, when they had most of the power (the Serbs didn't really regain their power until after the Soviet Union faded away, and Yugoslavia broke up)? I can't really say I blame the Serbs for their aggression, based on this perspective.
--Corey
I wonder what kind of snap-on attachment the likes of Dr. John's will make for the pet-bots.
Katz, you listening?
--Corey
For a good time, go have a look at Spacemoose.
;-)
--Corey
No, I used that term about 2 years ago in a discussion with some friends. We were discussing a licensing scheme for open software that wasn't so GNU-centric for some software we were/are going to write.
:P
;)
Heheh...
Anyway, you can have it.
--C
Where's an URL for the Gerber?
--C
Agreed, installation on a bare drive is probably easier for someone not knowledgeable about computers, assuming the hardware is correctly set up for CD-booting and proper detection. There's one less level of crap to wade through to get the system up and running if you don't have to make allowances for another OS.
However, that wasn't the case in either of these articles, and it won't be the case for the vast majority of new linux installs in the near (or even the relatively distant) future.
I agree that it would be great to have Linux pre-installed, and that that will have to happen before Linux is palatable to the public at large. The fact is, though, that most installs will be of the type written about here.
There must be easy coexistance if Linux is to subsume the Windows installed base.
--Corey
Without helping at all, sit your mom down in front of a PC with Windows installed, give her your favorite off-the-shelf Linux help/install guide, and have her install the OS.
Remember, give her no assistance.
In the general case, if she manages to do it, it will take a long time and be a very frustrating experience, even with such distros as RedHat and SuSE. That is one of the hurdles faced with Linux being on the desktop.
Given that it's just as hard and frustrating for me to install '98 (three hours, three tries to get the FS set up the way *I* want it, much cussing and fussing), usually some variant of DOS/Windows is already installed. That is your customer base. Now, philosophical debates about whether you want users of that stripe here or not, this is the general computing public.
Don't go too hard on these writers, especially the English-major chick. Linux is a bit daunting if all you know how to do is point and drool at a preinstalled Windows love-fest.
My $.02
--Corey
It's the patch issue that bugs me, actually. Let's just say I want to set up an integrated OS build tree (something like (O|F)BSD), wherein all that is included in the system is available in snapshot form from a central CVS repository. These sources include the latest and greatest version of the Qt library, since KDE is the desktop of choice in my hypothetical world. This is easy to manage, as it gives the Qt source tree adapted to my particular scheme of doing things a common base, and maintainers of that part of the tree a common place from which to work.
I don't mind submitting patches to Troll Tech, as I feel it is my duty, and makes the whole thing go much more smoothly in the long run. However, I want as many people to be able to download or upgrade, in one shot, the sources to my whizbang OS (including the Qt libs), compile it, install it, run it, debug it, live it, love it, learn it, and have children with it (okay, maybe not that extreme).
Making the patches available as an add-on to the Qt libraries wouldn't be a big deal, and the application of said patches could be handled by a makefile, but that's an extra bunch of stuff for developers to have to do when working on my neat-o keen spanking new OS-thingy.
I don't have a problem with Troll's license. It's a good one. I don't see myself using Qt in my shiny new OS for the reasons listed above. It's a pain in the rear to deal with from that standpoint.
--C
Some folks can never stop bitching and pissing and moaning about "free/not-free/blah". If the Harmony project gets off the ground and, maybe with the help of RedHat's code-money, catches the Qt toolset as far as interface goes, KDE can use that to finally be "free" enough for all the crack-heads who like to complain about it.
If KDE is termed "free" by _everyone_, there will be no reason not to use it. It will get more exposure to all developers, and an open base for the toolkit may allow an eventual merging with the GNOME project (for things like a common ORB, common themeability, etc.).
IMNSHO, a "free" Qt toolkit is the only way to solve all these problems and stop people's whinging and griping and get some real work done.
--Corey
Amen, brother! Preach it!
There was a story once, I think it may have been on the new Twilight Zone (it's been a few years since I've seen it), where everyone had on them at all times at least three ways to keep in touch. Everyone had a mobile phone, a personal fax, a pager, and a couple other devices.
One guy got committed to a looney bin for having gone insane and pouring a chocolate malt into his fax machine, so rampant and entrenched was this stuff. At the end of the show, the doc that committed him couldn't get a minute to himself to think in peace, and ended up sending his secretary out for a chocolate malt.
I thought that was a beautiful statement about the world and the way I saw it headed back then. It's still applicable today.
When I'm away from the phone, it's because I _want_ to be away from it. When I'm driving, I don't _want_ to talk on the phone. It's dangerous, and stupid.
Blah, blah, blah...
--Corey
AFAIK, the only things that couldn't be easily done away with are the compilers. I've already written a proof-of-concept mini-libc (which has unfortunately disappeared over the course of time). Be it known, too, that the BSDs have perfectly reasonable libcs, rivalling even the vaunted *wretch* GNU libc.
;)
If there was a different source of compilers that were at least reasonable, I'd use them to port the OpenBSD userland over to Linsux. That'd yank RMS' chain.
--Corey
> I would say that an OS vendor should be under legal obligation to prove that their product is _not_ defective
No. You can't logically prove a negative.
> a money-back guarantee if it doesn't work.
That I can handle. Of course, given terms like "this software is not guaranteed to be suited for any particular purpose", yada yada yada, a vendor can skirt that issue easily.
--C
Hahahah!
Nice guy? Lawyer-to-be? Nice won't last.
j/k
--Corey