First of all, the language is less important than the motivation. Pick a project that will interest them, just to motivate them to learn. Sure, they want to learn now, but they haven't tried debugging yet. Finding flaws is the cross that we programers have to bear.
IIRC SmallTalk was designed to teach 6 year olds how to program. It doesn't have too many syntactic wrinkles and they'll be starting with OO (which is supposedly easier, not that I'd know).
Of course, another approach is to just "jump in with both feet" and show them exactly what you are doing. No contrived examples, and it should be a domain that you know fairly well. While they are young, don't assume that they're too stupid to learn.
When I moved from NC to France (Paris) back in '95 I got about the same salary, low-40s. But the US was coming out of a slump and being a native english speaker helps in France.
I got a small raise when I moved from France to the Alps (Grenoble), but that was because they needed a liason to the US ASAP. But the dollar was stronger, so I was making less than $40k. Don't exchange rates suck?
I moved back to North Carolina at the start of the year, and nearly doubled my previous salary.
Not only is the software industry booming in the US, France has can't-fire laws, so companies are less likely to want to hire. They just outsource everything, so there is less pressure for salaries to go up.
In defense of France, the cash is lower, but there are a lot more perks. 5+ weeks of vacation, cheeper medical bills (at least for the routine stuff), nicer day care system, etc, etc. Don't let cash alone regulate your life.
If anyone is interested in France, starting (fresh out) salaries in the Alps last year were about 150kf ($30k). A few years of experience and you'll be upto 180-200kf ($38-40k). There are too many folks who want to work in the Alps. If you are interested in Paris, add 50% or so to those numbers. Then remember the cost of living too. Paris is expensive.
Avoid SSIIs (service companies & contract shops) as they want low ball salaries. I guess that's true everywhere.
I'm not sure about "common" definitions, but for me the RISC idea is one-instruction per cycle. That isn't explicit in the name, but that is what was pushed as RISC in the early days. When RISC became a buzzword, everything is RISC. Most computers today have multiple piplelines, out-of-order execution, speculative branching and so on. This isn't what I consder true RISC. If my definition is showing my age, I'm sorry.
I am fully aware that newer IA32 CPUs (PII, K7, etc) have "RISC cores", and I think that this is the way to go (although I dislike the IA32 instruction set). RISC makes no software person's life easier, and CISC does. I don't care so much about the EEs doing the hardware, as I'm not one (yes, I'm callous).
You are right that "RISC is supposed to make the hardware solve the same problem in a smaller amount of time than a CISC design in the same process with the same constraints (cost, power..) and the same amount of development money." The gain in RISC though wasn't in the instruction set per-se, it was in letting the different parts of the CPU work in parallel. That can be done in CISC too, although some of the most complicated instructions may need to go away. C'est la vie.
Newer CPUs require that all instructions are the same length. This is required for RISC, but not for older CISC machines. Most modern CPUs (hybreds, the whole lot) have this restriction to simplify the fetcher's job. This is a fair tradeoff although some funky instructions go away, but it is worth it.
I like the observation that "Some say it's because pre-RISC cpus were designed for assembler programmers and RISC CPUs are designed for compilers." This is more that most programmers would go crazy coding big stuff (whole applications) in RISC. Compiler folks are already crazy, so it is no loss. Fortunatly, most of us code in C or something else, so this is a moot point.
As for your arguement "The flaw with this example is that you assume that we won't use C for some time", which is true in that case. Lets try a different example: think about a stack pointer. It is a common tactic to
move value => (--stackpointer)
There are three primitive instructions here: 1)change the stackpointer register, 2)get value from memory, and 3) store value in memory. It is quite possible that "value" will be used again in the near future, so saving it in a register is useless. Obviously as registers become more common, there is less motiviation to conserve them, so maybe this isn't important.
For starters, let me agree that fewer and fewer coders actually touch assembly as we let the compiler writers worry about such things. But I was following up a CISC vs RISC statement, so we're talking about that small minority. Most folks just use a higher level language and forget about the details (as well they should).
You are absolutely right that if a compiler can break down an instruction into smaller pieces, the hardware has less work to do. The is pushing some of the work from run time to compile time. In general, this is a good thing.
I just don't think that the savings are all that important, and there are things that cannot be known until run time. The compiler cannot do everything.
Most modern microprocessors (and I guess the bigger ones too) have fetchers that read in instructions, break them down, and feed the pipelines. All the complexity of CISC goes away at this point. Instead of one instruction being pushed into a pipeline, two or more instructions get pushed (hopefully into different pipelines). This here is the wonder of the superscalar concept.
The fetcher gets a bit more hairy, as does some of the speculative branch handling (more things to invalidate), but my goal wasn't to simplify the hardware. Anyway, the hardware already has some of this, so it isn't like we're adding anything new.
Conceptually, I prefer the idea of pushing as much of the info down as possible (CISC) so that the lower bits has a larger view of what is going on. Think of "peephole optimization" in a compiler: the larger the peephole, the better the optimization (within reason).
Compilers are handicapped that they often compile to the lowest common denominator. In the IA32 world, the instruction set hasn't changed too much in years, so many people forget that not all CPUs in the same family are identical. Think about the older PowerPCs: 601, 602, and 604 (I'm showing my age, eh?). The 601 was a hybred, so it had some odd opcodes. The compiler had options to generate for one of the CPU types, or target the lowest common denominator. Guess which one most applications used? Even if you stuck to the 603 and 604, life wasn't much better. I think that they had identical instruction sets (it has been a long time), but I'm sure that they had different pipeline geometries. It is not possible for a compiler to generate code that is optimal for both. That is why code that is optimal for a 386 is not optimal for a PII, even though the instruction set is the same. Details matter. The compiler can't know them all.
As long as I'm rambling, this is the main reason I've gone anti-VLIW. If a merceed comes out with 4 actions per instruction, and a mckinley has 6 actions, how is the poor compiler going to optimize for both?
Let the compiler parse, hack, and optimize all it can, but there are somethings that cannot be known before run time, and we need to let the CPU handle them. I think that CISC helps this out.
Have I made my arguement any clearer this time?
- doug
PS: I cut my teeth back on the old M68000 family and it is still my favorite instruction set. I worked with PowerPC 403s for a while, which is where my coding RISC assembler background lies.
PS2: To be honest, as long as the CPU isn't little-endian, I'm not going to get worked up over it. This is all just quibling over details.
I thought that stupid arguement died out years ago. There are few "true" RISC systems still out there. The PowerPC surely isn't one.
The "breakthrough" of the RISC design wasn't coming up with simplier instructions, it was breaking the CPU into independant subsystems that could work in parallel. Doing an integer operation at the same time as doing a floating point one, while loading data from the bus/memory means 3 things are going on at once. A "simple" instruction set means that it is more obvious where the pieces are, but is fundamentally irrelevant.
When programming in assembly (the only time RISC/CISC is visible to a programmer), you want it to be as CSICy as possible, it makes your life easier. Think about
C = A + B
In an old assembler that is one instruction. Simple, easy to read (for assembly). In a load-and-store system that is
load A to r1 load B to r2 add r1 to r2 store r2 to C
4 vs 1. You tell me which one you want to hand code in.
Also, RISC pushes more of the work to the software, which is fundamentally slower than hardware. Lets do as much stuff as low as possible so our systems run faster. Adding layers sucks.
Imagine a future with CISC instructions with pipelined cores. How one gets translated to the other is meaningless to programmers although an interesting research topic for the hardware folks. Think of it as a library. You just care what the interface is (the opcodes), let the library designer (EEs) handle the details of getting that interface to work well. Maybe some of the ease of the monster CISC stuff needs to go away to help out the core (trade-offs are part of an engineer's life), but as a rule CISC is better for programmers.
Just lest RISC vs CISC be forgotten. We need bits and pieces of each one.
I forget how far I live from the CO, but it isn't that far. The problem is that my phone lines were installed in the 80s. Everything is multiplexed out the wazoo. All those A-D conversions mean that I cannot connect my POTS modem faster than 26k and xDSL is out of the question. If you will, the wiring is too advanced for xDSL. I'd love to have a vintage 50s pure copper line into the CO.
I think that this whole thing is a bit more complicated that you imagine. I wish that you were right, but that isn't the case.
Fantasy is a type of fiction. Star Wars is clearly fiction in that is is, to the best of our knowledge, untrue. Since it is not "fact", it must be "fiction". This is a kind of boolean either/or situation.
Star Wars may or may not be "Science Fiction", a particular type of fiction. It has been too many years since I studied Sci-Fi (what a literature course), so I don't remember the definition (yes, there is on). My professor (author John Kessel) would have agreed that SW wasn't up to "Science Fiction".
I personally use "Science Fantasy" to cover SW and other things where the line between Magic and Technology gets blurry. This is a cop out on my part, but I've gotten over it.
Perl likes to sling strings, so the copy-on-write functionality gets hit more often than you'd like.
I'm not sure about the difference between code space and data space, but I think that code space is marked "read-only", so copy-on-write never becomes an issue (there are no writes).
This one is a bit too much for me. While Bill might like to run Corel into the ground, I doubt if he would sacrifice his cash cow to do so. MS gets too much of its profits from Office.
The thing is that if Office were freely distributed (like MSIE, not FSF "free"), it would help Windows, at least in the short term. Since most people get PCs with Windows/98 on them, giving them Office encourages them to use it. If someone has to get a different package, they might just end up trying something that doesn't run under windows. This person might then switch to a non-MS OS and that is what would hurt MS. So giving away Office (or at least "Office light") helps encourage the use of Windows by joe sixpack.
But I think that Windows will die on its own anyway, so this would slow things down without stopping the big trend.
Hotheads are nothing new, nor ares personality conflicts. These two people seem to have strong feelings (understatement, eh?) and they erupt every once in a while. This is just normal human behavior. We've all seen it hundreds of times.
The thing I don't get is why so many people make a big deal about it. I bet board members at MS, IBM or wherever get in fights too. But since that is behind closed doors, no one knows about them. In our little world, we don't have as many doors to hide behind, so our spats are public. Does that change anything?
The only thing I can think of is that people look to Bruce, Eric, Linus, Richard and so on as our "leaders" and expect some sort of coup to happen after a fight. While I respect the "big names", I don't feel like I "follow" any of them. I don't have a leader. Our "movement" is lead from below. http://www.perl.org/news.html has a reference to Larry Wall saying that 'Perl culture mandates a "bottom-up" approach.' I think this is true of most (all?) of the open/free/whatever software packages.
Let us listen what these "names" have to say, think about thier ideas, and get on with our lives.
IBM has said that it didn't develop its own OS for PCs or buy out MS because of the ongoing anti-trust suit that they were in. They hoped that letting someone else in on the low margin OS (my copy of DOS 2.1 cost $33) would "prove" that they weren't a monopoly without hurting revenue. I think IBM thought it was in control of Microsoft by threatining to pull DOS from it's PCs. OS/2 debunked that one.
Note that I'm not saying IBM wouldn't let others do the dirty work, just that they want control. CMS was developed at Cambridge, but IBM funded it and grabed it when it wanted it.
I'm not sure that selling an OS is a money maker. That was there reason HP gave for dropping HP-UX. Selling the services that go with an OS, that can bring in the dollars. Which is why HP has brought back HP-UX.
They are just looking to share the pain of development while fighting for the same market. This is much like Sommerset was for the PowerPC.
But like several others have mentioned, don't expect everyone to play together well. It wouldn't be the first time a "grand unified unix" project fell through.
AIX has jfs and a logical volume manager that will need to be supported in the Montery thingie. I'm willing to be that all of them have a list of "value added" (ie proprietary) features that must be supported to get the existing customers to upgrade.
Note that I'm not saying that Linux can't do these things, just that it isn't compatible with existing systems. As I mentioned in another thread, I'd like to see "them" add some compatibility stuff to Linux as optional packages (something like 2.2.5.aix3) to bridge Linux and older applications.
That is the main reason for this latest strain of Unix.
Do you think IBM/SCO/whomever is going to look at one of its customers and say "switch to Linux, but all of your custom software will break"? Of course not. Will Linus allow the kernel to bend over backwards for compatibility with AIX/SCO/whatever? Again, that isn't going to happen. For the moment there is no bridge between Linux and existing customized *ix software.
The goal of these companies is to reduce development costs, without losing customers or what they view as "value added" features. I doubt if any of 'em make money on the OS. I bet they'd all jump to any less expensive platform (Linux, *BSD, DR-DOS, CP/M) if they thought it wouldn't alienate existing customers. And that means that existing applications have to keep on chugging.
The thing I'd like to see is for them to push these custom libraries to be more Linux like, and then put a few people and adding layers on top of Linux to build compatiblity. If you need some funky AIX program that plays games and doesn't stick to POSIX specs, just add jfs support and an AIX kernel module and off you go. I'm not saying that this would be trivial, or even do-able.
But I doubt if they would do this. While IBM has started to work with Linux, I think that it is more of a anyone but Microsoft approach. IBM is too much of a control freak to allow something as important as an OS to be developped by someone else.
It is a shame, but there is a good chance that you're right. This looks to be one of the worst cases of the US legal system run amok. Kevin Mitnik was (is?) an idiot, but this whole thing looks to have been blown out of proportion and he's become the biggest scapegoat of the computer age.
The thing that I hope happens is the Justice Deptartment gets this shoved down thier collective throat and it causes them to be more reasonable in the future. Call me an optimist, but I think that when this thing gets to court, most of the BS will be exposed as such and the government will come out looking pretty bad.
The cynical side of me thinks that the feds know this, which is why he's been locked up so long without a trial. This way he gets punished even if the judge lets him go, and it gives people a chance to forget the details.
In the end II guess this is a no-win situation, as it is an idiot vs. an impersonal machine.
- doug
PS: I use "idiot" as someone who does dumb things. I have no doubt as to Mitnik's IQ.
While I wouldn't be surprised if BillyG and the boys did something like that, what sort of supporting evidence is there? Articles like this seem to be so much hearsay, wishful thinking and hype. Does anyone have any more concrete references?
Slashdot Mirror
First of all, the language is less important than the motivation. Pick a project that will interest them, just to motivate them to learn. Sure, they want to learn now, but they haven't tried debugging yet. Finding flaws is the cross that we programers have to bear.
IIRC SmallTalk was designed to teach 6 year olds how to program. It doesn't have too many syntactic wrinkles and they'll be starting with OO (which is supposedly easier, not that I'd know).
Of course, another approach is to just "jump in with both feet" and show them exactly what you are doing. No contrived examples, and it should be a domain that you know fairly well. While they are young, don't assume that they're too stupid to learn.
When I moved from NC to France (Paris) back in '95 I got about the same salary, low-40s. But the US was coming out of a slump and being a native english speaker helps in France.
I got a small raise when I moved from France to the Alps (Grenoble), but that was because they needed a liason to the US ASAP. But the dollar was stronger, so I was making less than $40k. Don't exchange rates suck?
I moved back to North Carolina at the start of the year, and nearly doubled my previous salary.
Not only is the software industry booming in the US, France has can't-fire laws, so companies are less likely to want to hire. They just outsource everything, so there is less pressure for salaries to go up.
In defense of France, the cash is lower, but there are a lot more perks. 5+ weeks of vacation, cheeper medical bills (at least for the routine stuff), nicer day care system, etc, etc. Don't let cash alone regulate your life.
If anyone is interested in France, starting (fresh out) salaries in the Alps last year were about 150kf ($30k). A few years of experience and you'll be upto 180-200kf ($38-40k). There are too many folks who want to work in the Alps. If you are interested in Paris, add 50% or so to those numbers. Then remember the cost of living too. Paris is expensive.
Avoid SSIIs (service companies & contract shops) as they want low ball salaries. I guess that's true everywhere.
I'm not sure about "common" definitions, but for me the RISC idea is one-instruction per cycle. That isn't explicit in the name, but that is what was pushed as RISC in the early days. When RISC became a buzzword, everything is RISC. Most computers today have multiple piplelines, out-of-order execution, speculative branching and so on. This isn't what I consder true RISC. If my definition is showing my age, I'm sorry.
I am fully aware that newer IA32 CPUs (PII, K7, etc) have "RISC cores", and I think that this is the way to go (although I dislike the IA32 instruction set). RISC makes no software person's life easier, and CISC does. I don't care so much about the EEs doing the hardware, as I'm not one (yes, I'm callous).
You are right that "RISC is supposed to make the hardware solve the same problem in a smaller amount of time than a CISC design in the same process with the same constraints (cost, power..) and the same amount of development money." The gain in RISC though wasn't in the instruction set per-se, it was in letting the different parts of the CPU work in parallel. That can be done in CISC too, although some of the most complicated instructions may need to go away. C'est la vie.
Newer CPUs require that all instructions are the same length. This is required for RISC, but not for older CISC machines. Most modern CPUs (hybreds, the whole lot) have this restriction to simplify the fetcher's job. This is a fair tradeoff although some funky instructions go away, but it is worth it.
I like the observation that "Some say it's because pre-RISC cpus were designed for assembler programmers and RISC CPUs are designed for compilers." This is more that most programmers would go crazy coding big stuff (whole applications) in RISC. Compiler folks are already crazy, so it is no loss. Fortunatly, most of us code in C or something else, so this is a moot point.
As for your arguement "The flaw with this example is that you assume that we won't use C for some time", which is true in that case. Lets try a different example: think about a stack pointer. It is a common tactic to
move value => (--stackpointer)
There are three primitive instructions here: 1)change the stackpointer register, 2)get value from memory, and 3) store value in memory. It is quite possible that "value" will be used again in the near future, so saving it in a register is useless. Obviously as registers become more common, there is less motiviation to conserve them, so maybe this isn't important.
- doug
For starters, let me agree that fewer and fewer coders actually touch assembly as we let the compiler writers worry about such things. But I was following up a CISC vs RISC statement, so we're talking about that small minority. Most folks just use a higher level language and forget about the details (as well they should).
You are absolutely right that if a compiler can break down an instruction into smaller pieces, the hardware has less work to do. The is pushing some of the work from run time to compile time. In general, this is a good thing.
I just don't think that the savings are all that important, and there are things that cannot be known until run time. The compiler cannot do everything.
Most modern microprocessors (and I guess the bigger ones too) have fetchers that read in instructions, break them down, and feed the pipelines. All the complexity of CISC goes away at this point. Instead of one instruction being pushed into a pipeline, two or more instructions get pushed (hopefully into different pipelines). This here is the wonder of the superscalar concept.
The fetcher gets a bit more hairy, as does some of the speculative branch handling (more things to invalidate), but my goal wasn't to simplify the hardware. Anyway, the hardware already has some of this, so it isn't like we're adding anything new.
Conceptually, I prefer the idea of pushing as much of the info down as possible (CISC) so that the lower bits has a larger view of what is going on. Think of "peephole optimization" in a compiler: the larger the peephole, the better the optimization (within reason).
Compilers are handicapped that they often compile to the lowest common denominator. In the IA32 world, the instruction set hasn't changed too much in years, so many people forget that not all CPUs in the same family are identical. Think about the older PowerPCs: 601, 602, and 604 (I'm showing my age, eh?). The 601 was a hybred, so it had some odd opcodes. The compiler had options to generate for one of the CPU types, or target the lowest common denominator. Guess which one most applications used? Even if you stuck to the 603 and 604, life wasn't much better. I think that they had identical instruction sets (it has been a long time), but I'm sure that they had different pipeline geometries. It is not possible for a compiler to generate code that is optimal for both. That is why code that is optimal for a 386 is not optimal for a PII, even though the instruction set is the same. Details matter. The compiler can't know them all.
As long as I'm rambling, this is the main reason I've gone anti-VLIW. If a merceed comes out with 4 actions per instruction, and a mckinley has 6 actions, how is the poor compiler going to optimize for both?
Let the compiler parse, hack, and optimize all it can, but there are somethings that cannot be known before run time, and we need to let the CPU handle them. I think that CISC helps this out.
Have I made my arguement any clearer this time?
- doug
PS: I cut my teeth back on the old M68000 family and it is still my favorite instruction set. I worked with PowerPC 403s for a while, which is where my coding RISC assembler background lies.
PS2: To be honest, as long as the CPU isn't little-endian, I'm not going to get worked up over it. This is all just quibling over details.
I thought that stupid arguement died out years ago. There are few "true" RISC systems still out there. The PowerPC surely isn't one.
The "breakthrough" of the RISC design wasn't coming up with simplier instructions, it was breaking the CPU into independant subsystems that could work in parallel. Doing an integer operation at the same time as doing a floating point one, while loading data from the bus/memory means 3 things are going on at once. A "simple" instruction set means that it is more obvious where the pieces are, but is fundamentally irrelevant.
When programming in assembly (the only time RISC/CISC is visible to a programmer), you want it to be as CSICy as possible, it makes your life easier. Think about
C = A + B
In an old assembler that is one instruction. Simple, easy to read (for assembly). In a load-and-store system that is
load A to r1
load B to r2
add r1 to r2
store r2 to C
4 vs 1. You tell me which one you want to hand code in.
Also, RISC pushes more of the work to the software, which is fundamentally slower than hardware. Lets do as much stuff as low as possible so our systems run faster. Adding layers sucks.
Imagine a future with CISC instructions with pipelined cores. How one gets translated to the other is meaningless to programmers although an interesting research topic for the hardware folks. Think of it as a library. You just care what the interface is (the opcodes), let the library designer (EEs) handle the details of getting that interface to work well. Maybe some of the ease of the monster CISC stuff needs to go away to help out the core (trade-offs are part of an engineer's life), but as a rule CISC is better for programmers.
Just lest RISC vs CISC be forgotten. We need bits and pieces of each one.
It is more than just that.
I forget how far I live from the CO, but it isn't that far. The problem is that my phone lines were installed in the 80s. Everything is multiplexed out the wazoo. All those A-D conversions mean that I cannot connect my POTS modem faster than 26k and xDSL is out of the question. If you will, the wiring is too advanced for xDSL. I'd love to have a vintage 50s pure copper line into the CO.
I think that this whole thing is a bit more complicated that you imagine. I wish that you were right, but that isn't the case.
Fantasy is a type of fiction. Star Wars is clearly fiction in that is is, to the best of our knowledge, untrue. Since it is not "fact", it must be "fiction". This is a kind of boolean either/or situation.
Star Wars may or may not be "Science Fiction", a particular type of fiction. It has been too many years since I studied Sci-Fi (what a literature course), so I don't remember the definition (yes, there is on). My professor (author John Kessel) would have agreed that SW wasn't up to "Science Fiction".
I personally use "Science Fantasy" to cover SW and other things where the line between Magic and Technology gets blurry. This is a cop out on my part, but I've gotten over it.
- doug
Perl likes to sling strings, so the copy-on-write functionality gets hit more often than you'd like.
I'm not sure about the difference between code space and data space, but I think that code space is marked "read-only", so copy-on-write never becomes an issue (there are no writes).
- doug
How does this differ from SSH, SSL, IPsec and the other TCP crypto thingies I've heard of? Does any one have a URL that would help me out?
- doug
This one is a bit too much for me. While Bill might like to run Corel into the ground, I doubt if he would sacrifice his cash cow to do so. MS gets too much of its profits from Office.
The thing is that if Office were freely distributed (like MSIE, not FSF "free"), it would help Windows, at least in the short term. Since most people get PCs with Windows/98 on them, giving them Office encourages them to use it. If someone has to get a different package, they might just end up trying something that doesn't run under windows. This person might then switch to a non-MS OS and that is what would hurt MS. So giving away Office (or at least "Office light") helps encourage the use of Windows by joe sixpack.
But I think that Windows will die on its own anyway, so this would slow things down without stopping the big trend.
IMHO, of course.
- doug
Hotheads are nothing new, nor ares personality conflicts. These two people seem to have strong feelings (understatement, eh?) and they erupt every once in a while. This is just normal human behavior. We've all seen it hundreds of times.
The thing I don't get is why so many people make a big deal about it. I bet board members at MS, IBM or wherever get in fights too. But since that is behind closed doors, no one knows about them. In our little world, we don't have as many doors to hide behind, so our spats are public. Does that change anything?
The only thing I can think of is that people look to Bruce, Eric, Linus, Richard and so on as our "leaders" and expect some sort of coup to happen after a fight. While I respect the "big names", I don't feel like I "follow" any of them. I don't have a leader. Our "movement" is lead from below. http://www.perl.org/news.html has a reference to Larry Wall saying that 'Perl culture mandates a "bottom-up" approach.' I think this is true of most (all?) of the open/free/whatever software packages.
Let us listen what these "names" have to say, think about thier ideas, and get on with our lives.
- doug
IBM has said that it didn't develop its own OS for PCs or buy out MS because of the ongoing anti-trust suit that they were in. They hoped that letting someone else in on the low margin OS (my copy of DOS 2.1 cost $33) would "prove" that they weren't a monopoly without hurting revenue. I think IBM thought it was in control of Microsoft by threatining to pull DOS from it's PCs. OS/2 debunked that one.
Note that I'm not saying IBM wouldn't let others do the dirty work, just that they want control. CMS was developed at Cambridge, but IBM funded it and grabed it when it wanted it.
- doug
I'm not sure that selling an OS is a money maker. That was there reason HP gave for dropping HP-UX. Selling the services that go with an OS, that can bring in the dollars. Which is why HP has brought back HP-UX.
They are just looking to share the pain of development while fighting for the same market. This is much like Sommerset was for the PowerPC.
But like several others have mentioned, don't expect everyone to play together well. It wouldn't be the first time a "grand unified unix" project fell through.
- doug
AIX has jfs and a logical volume manager that will need to be supported in the Montery thingie. I'm willing to be that all of them have a list of "value added" (ie proprietary) features that must be supported to get the existing customers to upgrade.
Note that I'm not saying that Linux can't do these things, just that it isn't compatible with existing systems. As I mentioned in another thread, I'd like to see "them" add some compatibility stuff to Linux as optional packages (something like 2.2.5.aix3) to bridge Linux and older applications.
- doug
That is the main reason for this latest strain of Unix.
Do you think IBM/SCO/whomever is going to look at one of its customers and say "switch to Linux, but all of your custom software will break"? Of course not. Will Linus allow the kernel to bend over backwards for compatibility with AIX/SCO/whatever? Again, that isn't going to happen. For the moment there is no bridge between Linux and existing customized *ix software.
The goal of these companies is to reduce development costs, without losing customers or what they view as "value added" features. I doubt if any of 'em make money on the OS. I bet they'd all jump to any less expensive platform (Linux, *BSD, DR-DOS, CP/M) if they thought it wouldn't alienate existing customers. And that means that existing applications have to keep on chugging.
The thing I'd like to see is for them to push these custom libraries to be more Linux like, and then put a few people and adding layers on top of Linux to build compatiblity. If you need some funky AIX program that plays games and doesn't stick to POSIX specs, just add jfs support and an AIX kernel module and off you go. I'm not saying that this would be trivial, or even do-able.
But I doubt if they would do this. While IBM has started to work with Linux, I think that it is more of a anyone but Microsoft approach. IBM is too much of a control freak to allow something as important as an OS to be developped by someone else.
- doug
It is a shame, but there is a good chance that you're right. This looks to be one of the worst cases of the US legal system run amok. Kevin Mitnik was (is?) an idiot, but this whole thing looks to have been blown out of proportion and he's become the biggest scapegoat of the computer age.
The thing that I hope happens is the Justice Deptartment gets this shoved down thier collective throat and it causes them to be more reasonable in the future. Call me an optimist, but I think that when this thing gets to court, most of the BS will be exposed as such and the government will come out looking pretty bad.
The cynical side of me thinks that the feds know this, which is why he's been locked up so long without a trial. This way he gets punished even if the judge lets him go, and it gives people a chance to forget the details.
In the end II guess this is a no-win situation, as it is an idiot vs. an impersonal machine.
- doug
PS: I use "idiot" as someone who does dumb things. I have no doubt as to Mitnik's IQ.
While I wouldn't be surprised if BillyG and the boys did something like that, what sort of supporting evidence is there? Articles like this seem to be so much hearsay, wishful thinking and hype. Does anyone have any more concrete references?
Well, none that has XFree86 anyhow. Maybe one of the tiny linux distributions doesn't have X, but all the major ones do.