I think that until this happened, Intel was in a far better position to withdraw from the cross-licensing deal they have. Now that x86-64 is basically mandatory, Intel needs it as much as AMD needs SSE.
I think Apple would avoid AMD regardless because it would confuse customers. They've always done their best to make sure product lines don't overlap, even if it meant artificially restricting the performance of the lower end machines.
"15 Million Macs in one year? No way. In good quarters Apple have been selling a million, but why should they almost quadruple that suddenly, just because it's an intel CPU now?"
A good chunk of those machies are unsupported and I hadn't counted them in my estimates, but I think sales could reasonably double once Intel-base Macs are released.
"Not if the growing market is still 5% and the shrinking one 95%.
Otherwise everyone would support Firefox only because it's growing while IE's market share is shrinking."
There's a difference: there's a good chance both will be around for the forseeable future. Apple's PowerPC products are't going to be on the market after 2007, and attrition will take care of the existing ones.
Because people are putting off purchases now[1], and because the Intel chips have so many advantages[2] that have been hurting laptop sales for Apple[3], sales are going to surge next year.
I think we'll see 50% of Mac users owning an Intel-based machine before they stop shipping PowerPC machines in 2007. I think that's when the PowerPC software will start disappearing in earnest. In mid-2007 it's not going to be 95% PowerPC and declining slowly, it's going to be 50% declining quickly.
1 - I'm not saying it's right, I'm just saying they are.
2 - Current Pentium Ms have a 3x integer performance advantage over G4s, and laptops are shipping with 7+ hour batteries (eg IBM T40, that number unofficial from a review). The new Yonah core that Apple will be using will improve this further, and there will be a dual-core version.
3 - iMacs are outselling all Apple laptops put together. That is telling when the rest of the industry is primarily laptops.
I don't think that's the case, and even if it is it must have some capacity to have different code paths for different architechtures (otherwise Altivec or SSE specific optimizations would be impossible). The PowerPC one can pop up a window that says "PowerPC is not supported." and then exit.
"As you say: as soon as possible. Since 99% of any potential buyers of Mac OS X software (= user base) will be on PPC for years to come, if you want to sell a product you WILL HAVE TO support PPC for years to come."
It's not going to be 99% for very long. Sales will surge after the Intel-based machines are released.
"Otherwise you WONT FUCKING SELL ANY SOFTWARE in appreciable numbers.
What's so difficult to understand about that?"
I understand your argument, but you don't understand MBAs.
An MBA will always choose a market that is growing over one that is shrinking. They'll take the money if they aren't mutually exclusive, but they don't like to put money into shrinking markets even if they can make it back. The reality is that a PowerPC version of the software won't be free to maintain, and even if they can do it cheaply they'd rather put a little bit more money into new stuff than support the old stuff at all. Small to medium sized companies don't always have the resources to do both.
You'll see large companies like Adobe and Microsoft do both for longer, and you'll see the open-source and guy-in-a-basement shareware people do both for longer (as their QA is more a matter of users bitching than formalized testing), but the small to middle companies will face the strongest pressure, particularly in software that has lots of platform specific optimizations.
It's already started happening now, and it will be in full swing by the end of 2006. You'll also see people that don't make CPU-bound software shipping PowerPC only binaries for a long time, until they feel Intel-based Macs are prevenlant enough and then they'll switch all at once.
Management thinking is like quantum physics. It's consistent but it doesn't make intuitive sense.
"And everyone who will programme for Intel Mac OS X will have to make a PPC version, simply because for years to come 99.99999% of the user base are still on PPC."
Have you ever worked in commercial software development? Management will see two architechtures, one that will shrink until it no longer exists, the other that will grow until it's the whole market. They're going to want to cut off PowerPC on existing software as soon as possible, and convincing anyone to support PowerPC on new projects is going to be like pulling teeth.
Does this mean management is unwilling to spend a few extra dollars when they'll probably make it back? Yes. Is that stupid? Yes. Is it true? Yes. Companies want to develop software that will provide a growing source of revenue, not a shrinking one, even if the incremental cost is small.
"If you're programming in a sane way, making universal binaries is not much more than another checkbox to click on when compiling apps (plus a weeny bit of tweaking)."
Again, have you ever worked in commercial software development? QA is not free on an extra architechture.
"Last I heard those new M-based archs do have EM64T support."
The Yonah core to be released early next year will now will not support the 64-bit extensions, or so Intel claims. 64-bit extensions will have to wait.
"Bit still, from what I can gather OSX x86 will run in mixed 32-bit/64-bit mode, so chances are their initial lineup probably won't be all 64-bit. Pretty sad, really."
It's not all bad. Pentium Ms outperform G4s (by a factor of three on integer code, probably faster even under emulation) and have a better battery life, and that's the current generation. Yonah will improve performance and battery life. And they'll have a dual-core version for PowerBooks.
Too bad they don't have a machine for pros or enthusiasts that need two displays, lots of memory, or RAID instead of two processors. Not everyone is willing to pay >$1000 for a processor they're not going to use.
"Will Apple stay the dual-processor course when they move to Intel?"
I'd be shocked if they didn't. When you can have two cores on one die, you can have four cores on two die. They will probably wait until there is a dual-core version of a Pentium M derived Xeon before they switch the PowerMacs. That's probably why it'll take until 2007.
"Who would buy a Dell computer now, knowing much faster systems will be available in less than a year's time?"
Speed changes happen all the time, that's par for the course. Changes in the architechture happen very rarely and can be worth the wait depending on what you're doing.
"With the ease of x-code's fat binaries, there's very little incentive for a developer to write programs that will only run on intel macs, so why get all bent out of shape about buying a machine now?"
I wish people would stop saying that. QA for another architechture isn't free.
The single-CPU PowerMac cost about twice as much as a PC with similar capabilities. It was outrageously overpriced for what it could do. Most of the other machines are reasonable, but the premium of single-CPU PowerMacs really stood out.
The dual-CPU PowerMacs cost a reasonable amount for what they have, but being forced to buy a dual-processor machine when all that's needed is a PCI card or dual displays is a bad deal.
I realize Apple doesn't want the prices of their various product lines to overlap, but in this case I think it's a mistake. Low cost, single-CPU machines occupy a sweet spot in the market. Professionals and enthusiasts frequently need the capabilities of an upgradable machine but not the extra performance of a second CPU. These people are also some of the most likely to be willing to put up with a bit of extra effort to deal with a PC if it gives them what they need for that much less.
Someone looking at a PC instead of a PowerMac can pocket the savings, or add different hardware that would benefit them a lot more. For example, system a few gigs of memory or a RAID array will handle some workloads better than a machine with two processors. A PowerMac can include both upgrades, but only on top of the premium you're already paying. When a PC can be built with these features for less than the entry-level price of a PowerMac, it doesn't look like a very good deal.
Some people will prefer the Mac either way, and they'll probably respond with "It's still worth it!", but that point of view is not universal. The extra value of MacOS is not infinite, so a sufficiently large premium can make a machine unappealing.
"Maybe, what is missing here is some type declaration, where the types define keys and their values are on the key:value pairs. That will make objects that contain other objects possible and would still be fast to parse."
That would be recursive, requiring a recursive parser. I think a much simpler parser would be better, but it might ultimately be necessary to do more. Of course, if it's that complicated you should probably use a better language...
"Another point is that the terminal may know how to display the data if you declare its type, so the 'format' step would not be necessary."
The serialization library could detect if the output was a TTY, and output a slightly more human readable output.
That's a lot harder for some operations. It's fine if the output of the tool is columns but sometimes it isn't, or it's a more complicated format. It puts a lot of the parsing work on you. Shell tools that share a compatible protocol would make it a lot easier to write some sorts of scripts.
I'm happy for you that your computer works, but it doesn't refute my point.
2.6 kernels have a much higher probability of something going wrong. That'll cost you over time if you use them enough. You can't apply updates as much because they're forever breaking things, etc.
"We would need a hole new convention on how to serialize those objects (A faster XML?)."
I thought about it a little. XML is the obvious choice, but that might be overkill. The parser shouldn't need to be recursive like it would need to be with XML. Instead of lines, there could be objects that are nothing but key:value pairs, dictionaries basically.
"Also, it is not so clear if it would be an advantage or if it will reduce the usefullnes of the CLI, because every use must be though at programming time (like GUI)"
No, I don't agree.
As a trivial example, consider an "ls" equivilant. In this example, the first line describes the fields and their types. I'm leaving out a lot of stuff for brevity, but you'd want it to give you everything that stat returns.
$ list-dir. name:string,size:int,directory:bool,read:bool,w rit e:bool,execute:bool CVS,512,Y,Y,Y,Y Makefile,712 ,N,Y,Y,N main.c,10231,N,Y,Y,N a.out,12783,N,Y,Y, Y $ list-dir . | filter name -eq Makefile Makefile,712,N,Y,Y,N $ list-dir . | filter name -eq Makefile | format "%s: %s" name size Makefile: 712
Now say I have something else. As a contrived example, I have a file containing phone numbers, I'm not saying grep wouldn't be better for such a simple task, this is just an example of how something like this might work, to show that it's general purpose. I use Python regexes in this example because they can have named groups.
$ cat numbers.txt Alice: 111-1111 Bob: 222-2222 $ cat numbers.txt | parse "(?P<name>.*?): (?P<number>[0-9]{3}-[0-9]{4})" name:string,number :string Alice,111-1111 Bob,222-2222 $ cat numbers.txt | parse "(?P<name>.*?): (?P<number>[0-9]{3}-[0-9]{4})" | filter name -eq Bob | format "%s" number 222-2222 $ cat numbers.txt | parse "(?P<name>.*?): (?P<number>[0-9]{3}-[0-9]{4})" | filter name -eq Bob | format-args number -- dialer-program dialing...
Something like this would make much more powerful scripts possible. Languages like Python are very powerful, but they're not shell replacements. You want to pack the maximum punch into a the shell.
I don't think many of us care that the command names are a little hard to remember. I have just as much trouble remembering stuff from APIs with nice names like Java.
No, this highlights a weakness in UNIX shells: we have to parse things. It's slow and it's a huge pain. It seriously limits what we can do. grep, sed etc can be used to manipulate streams but nobody ever implements the complete grammar of the input they can get. They implement some subset that's good enough for the job at hand and tweak it when it screws up. It's worked well for decades, but that doesn't mean we can't do better.
Having a data structure passed along a pipe like MSH does is a huge advantage and very efficient, but I think most UNIX people can agree that it's not worth it to bring everything into the same process. What's an alternative? Serialize the data structure (in some human readable form to stay true to UNIX tradition) and pass that down the pipe, from one process to another. That would work with the pipes we have now and the shells we have now, we just need new tools and a serialization protocol.
" And all of that will require processing power. All of those objects have to be converted each and every time they get passed. Even the conversion to text will take cycles."
Are you kidding? Parsing text is one of the hardest things for a modern processor to do. Having fields available in a consistent internal representation allows you to do stuff based on them without having to parse anything, and you don't have to parse things. How many regexen do you write in a typical shell script? I'm not saying there are no disadvantages to Microsoft's way, but speed isn't one of them.
Also, you don't have to launch so many processes with MSH way. *nix shells can be prohibitively slow if you use an iteration strategy that results in lots of processes being launched, but sometimes it's hard to set things up as a pipe because you often have to do more complex parsing.
These things aren't so much of a disadvantage for larger programs that often end up in another language, but small one-time scripts will probably be easier.
I'm not going to use Windows, but if someone can come up with something better than that stupid Python shell replacement on UNIX I'll give it a shot.
Actually it seems to me that new tools for the current shells could serialize objects and pass them through the pipes we have.
Seems to be okay if they live on different chips, which is probably why the Promise card works. Your motherboard might have a separate SATA chip.
I don't remember which kernel versions are affected, but it's a relatively new thing. It's caused by libata, if I recall my debugging correctly. I gave up trying different versions long ago (which is why I've forgotten most of the specifics), I just use the Debian images and try to work around the bugs they have.
Re:One thing I'm a bit confused about...
on
Kernel 2.6.12 Released
·
· Score: 0, Flamebait
"That being said, the statement that distros don't roll their own kernels isn't true, anyway. Take Fedora, for example - if you read Dave Jones' blog, you'll notice that a lot of effort *is* going into stabilizing these and making them regression-free."
Oh they try. Valiantly I'm sure. But they fail. For example, Fedora Core 3 can't see my CD drive unless I put it on a Promise IDE card because of that libata business. I'm sure they'd be able to do better if they weren't starting out with such a disadvantage.
"Outside of that... well, yeah, I guess one could complain about the lack of proper regression testing, QA prior to releases, release schedules and all that. But the truth is that these things have not only hindered but actually *helped* a great deal when it comes to Linux development, so I don't see why they should be abolished. In the end, it's the developers that decide how things should work - and that's good, because it's the developers, not management (this includes everyone who's not involved with development), who know best."
Your pronouns imply you're a kernel developer. Is that the case? You may have a development model that results in features being added faster, but you are not producing kernels that I can risk using for anything important. Judging by the other posts here, I'm not alone. I agree that non-developers shouldn't be in charge of the project, but you should agree that users are free to use something else if what you're making don't meet our needs.
Kernel 2.6 doesn't meet my needs anywhere but my workstation system. It's worth it for the responsiveness, but my workstation is my problem. I can install something else over lunch if I have to. But I will get yelled at if the other machines break, and I don't want 2.6 anywhere near them.
Ultimately I hear a lot of justifications that involve things other than kernels that work robustly from one version from the next, but I don't care about those other things when my system isn't running at all. If you do, that's fine, but I think you should care a little when a Linux update becomes more likely to break stuff than a Windows update.
Unfortunately you can't update to a new release to fix the bugs you have, because every new version is so riddled with regressions that it's just as bad as the last one. Bugs are replaced, not fixed.
Slashdot Mirror
I think that until this happened, Intel was in a far better position to withdraw from the cross-licensing deal they have. Now that x86-64 is basically mandatory, Intel needs it as much as AMD needs SSE.
I think Apple would avoid AMD regardless because it would confuse customers. They've always done their best to make sure product lines don't overlap, even if it meant artificially restricting the performance of the lower end machines.
"15 Million Macs in one year? No way. In good quarters Apple have been selling a million, but why should they almost quadruple that suddenly, just because it's an intel CPU now?"
A good chunk of those machies are unsupported and I hadn't counted them in my estimates, but I think sales could reasonably double once Intel-base Macs are released.
"Not if the growing market is still 5% and the shrinking one 95%.
Otherwise everyone would support Firefox only because it's growing while IE's market share is shrinking."
There's a difference: there's a good chance both will be around for the forseeable future. Apple's PowerPC products are't going to be on the market after 2007, and attrition will take care of the existing ones.
Because people are putting off purchases now[1], and because the Intel chips have so many advantages[2] that have been hurting laptop sales for Apple[3], sales are going to surge next year.
I think we'll see 50% of Mac users owning an Intel-based machine before they stop shipping PowerPC machines in 2007. I think that's when the PowerPC software will start disappearing in earnest. In mid-2007 it's not going to be 95% PowerPC and declining slowly, it's going to be 50% declining quickly.
1 - I'm not saying it's right, I'm just saying they are.
2 - Current Pentium Ms have a 3x integer performance advantage over G4s, and laptops are shipping with 7+ hour batteries (eg IBM T40, that number unofficial from a review). The new Yonah core that Apple will be using will improve this further, and there will be a dual-core version.
3 - iMacs are outselling all Apple laptops put together. That is telling when the rest of the industry is primarily laptops.
I don't think that's the case, and even if it is it must have some capacity to have different code paths for different architechtures (otherwise Altivec or SSE specific optimizations would be impossible). The PowerPC one can pop up a window that says "PowerPC is not supported." and then exit.
"As you say: as soon as possible. Since 99% of any potential buyers of Mac OS X software (= user base) will be on PPC for years to come, if you want to sell a product you WILL HAVE TO support PPC for years to come."
It's not going to be 99% for very long. Sales will surge after the Intel-based machines are released.
"Otherwise you WONT FUCKING SELL ANY SOFTWARE in appreciable numbers.
What's so difficult to understand about that?"
I understand your argument, but you don't understand MBAs.
An MBA will always choose a market that is growing over one that is shrinking. They'll take the money if they aren't mutually exclusive, but they don't like to put money into shrinking markets even if they can make it back. The reality is that a PowerPC version of the software won't be free to maintain, and even if they can do it cheaply they'd rather put a little bit more money into new stuff than support the old stuff at all. Small to medium sized companies don't always have the resources to do both.
You'll see large companies like Adobe and Microsoft do both for longer, and you'll see the open-source and guy-in-a-basement shareware people do both for longer (as their QA is more a matter of users bitching than formalized testing), but the small to middle companies will face the strongest pressure, particularly in software that has lots of platform specific optimizations.
It's already started happening now, and it will be in full swing by the end of 2006. You'll also see people that don't make CPU-bound software shipping PowerPC only binaries for a long time, until they feel Intel-based Macs are prevenlant enough and then they'll switch all at once.
Management thinking is like quantum physics. It's consistent but it doesn't make intuitive sense.
"And everyone who will programme for Intel Mac OS X will have to make a PPC version, simply because for years to come 99.99999% of the user base are still on PPC."
Have you ever worked in commercial software development? Management will see two architechtures, one that will shrink until it no longer exists, the other that will grow until it's the whole market. They're going to want to cut off PowerPC on existing software as soon as possible, and convincing anyone to support PowerPC on new projects is going to be like pulling teeth.
Does this mean management is unwilling to spend a few extra dollars when they'll probably make it back? Yes. Is that stupid? Yes. Is it true? Yes. Companies want to develop software that will provide a growing source of revenue, not a shrinking one, even if the incremental cost is small.
"If you're programming in a sane way, making universal binaries is not much more than another checkbox to click on when compiling apps (plus a weeny bit of tweaking)."
Again, have you ever worked in commercial software development? QA is not free on an extra architechture.
"Last I heard those new M-based archs do have EM64T support."
The Yonah core to be released early next year will now will not support the 64-bit extensions, or so Intel claims. 64-bit extensions will have to wait.
"Bit still, from what I can gather OSX x86 will run in mixed 32-bit/64-bit mode, so chances are their initial lineup probably won't be all 64-bit. Pretty sad, really."
It's not all bad. Pentium Ms outperform G4s (by a factor of three on integer code, probably faster even under emulation) and have a better battery life, and that's the current generation. Yonah will improve performance and battery life. And they'll have a dual-core version for PowerBooks.
Too bad they don't have a machine for pros or enthusiasts that need two displays, lots of memory, or RAID instead of two processors. Not everyone is willing to pay >$1000 for a processor they're not going to use.
"Will Apple stay the dual-processor course when they move to Intel?"
I'd be shocked if they didn't. When you can have two cores on one die, you can have four cores on two die. They will probably wait until there is a dual-core version of a Pentium M derived Xeon before they switch the PowerMacs. That's probably why it'll take until 2007.
"Who would buy a Dell computer now, knowing much faster systems will be available in less than a year's time?"
Speed changes happen all the time, that's par for the course. Changes in the architechture happen very rarely and can be worth the wait depending on what you're doing.
"With the ease of x-code's fat binaries, there's very little incentive for a developer to write programs that will only run on intel macs, so why get all bent out of shape about buying a machine now?"
I wish people would stop saying that. QA for another architechture isn't free.
The single-CPU PowerMac cost about twice as much as a PC with similar capabilities. It was outrageously overpriced for what it could do. Most of the other machines are reasonable, but the premium of single-CPU PowerMacs really stood out.
The dual-CPU PowerMacs cost a reasonable amount for what they have, but being forced to buy a dual-processor machine when all that's needed is a PCI card or dual displays is a bad deal.
I realize Apple doesn't want the prices of their various product lines to overlap, but in this case I think it's a mistake. Low cost, single-CPU machines occupy a sweet spot in the market. Professionals and enthusiasts frequently need the capabilities of an upgradable machine but not the extra performance of a second CPU. These people are also some of the most likely to be willing to put up with a bit of extra effort to deal with a PC if it gives them what they need for that much less.
Someone looking at a PC instead of a PowerMac can pocket the savings, or add different hardware that would benefit them a lot more. For example, system a few gigs of memory or a RAID array will handle some workloads better than a machine with two processors. A PowerMac can include both upgrades, but only on top of the premium you're already paying. When a PC can be built with these features for less than the entry-level price of a PowerMac, it doesn't look like a very good deal.
Some people will prefer the Mac either way, and they'll probably respond with "It's still worth it!", but that point of view is not universal. The extra value of MacOS is not infinite, so a sufficiently large premium can make a machine unappealing.
Again, I'm happy for you that you haven't had problems but that experience doesn't generalize.
"Maybe, what is missing here is some type declaration, where the types define keys and their values are on the key:value pairs. That will make objects that contain other objects possible and would still be fast to parse."
That would be recursive, requiring a recursive parser. I think a much simpler parser would be better, but it might ultimately be necessary to do more. Of course, if it's that complicated you should probably use a better language...
"Another point is that the terminal may know how to display the data if you declare its type, so the 'format' step would not be necessary."
The serialization library could detect if the output was a TTY, and output a slightly more human readable output.
"Note that there was no 1GHz P4 chip nor was there a 1GHz Athlon 64."
:)
With Cool'n'Quiet newer Athlons can underclock themselves to 1 ghz. Mine does this.
"Somthing like this??"
Pretty much what I was thinking, year. I don't know if you'd want to call it -monad, but that's the general idea.
That's a lot harder for some operations. It's fine if the output of the tool is columns but sometimes it isn't, or it's a more complicated format. It puts a lot of the parsing work on you. Shell tools that share a compatible protocol would make it a lot easier to write some sorts of scripts.
Yes, but shell tools don't do it and aren't aware of it, for the most part. You end up having to munge text with sed or similar to pull stuff out.
I'm happy for you that your computer works, but it doesn't refute my point.
2.6 kernels have a much higher probability of something going wrong. That'll cost you over time if you use them enough. You can't apply updates as much because they're forever breaking things, etc.
"We would need a hole new convention on how to serialize those objects (A faster XML?)."
.w rit e:bool,execute:bool2 ,N,Y,Y,N, Y
r :string
I thought about it a little. XML is the obvious choice, but that might be overkill. The parser shouldn't need to be recursive like it would need to be with XML. Instead of lines, there could be objects that are nothing but key:value pairs, dictionaries basically.
"Also, it is not so clear if it would be an advantage or if it will reduce the usefullnes of the CLI, because every use must be though at programming time (like GUI)"
No, I don't agree.
As a trivial example, consider an "ls" equivilant. In this example, the first line describes the fields and their types. I'm leaving out a lot of stuff for brevity, but you'd want it to give you everything that stat returns.
$ list-dir
name:string,size:int,directory:bool,read:bool,
CVS,512,Y,Y,Y,Y
Makefile,71
main.c,10231,N,Y,Y,N
a.out,12783,N,Y,Y
$ list-dir . | filter name -eq Makefile
Makefile,712,N,Y,Y,N
$ list-dir . | filter name -eq Makefile | format "%s: %s" name size
Makefile: 712
Now say I have something else. As a contrived example, I have a file containing phone numbers, I'm not saying grep wouldn't be better for such a simple task, this is just an example of how something like this might work, to show that it's general purpose. I use Python regexes in this example because they can have named groups.
$ cat numbers.txt
Alice: 111-1111
Bob: 222-2222
$ cat numbers.txt | parse "(?P<name>.*?): (?P<number>[0-9]{3}-[0-9]{4})"
name:string,numbe
Alice,111-1111
Bob,222-2222
$ cat numbers.txt | parse "(?P<name>.*?): (?P<number>[0-9]{3}-[0-9]{4})" | filter name -eq Bob | format "%s" number
222-2222
$ cat numbers.txt | parse "(?P<name>.*?): (?P<number>[0-9]{3}-[0-9]{4})" | filter name -eq Bob | format-args number -- dialer-program
dialing...
Something like this would make much more powerful scripts possible. Languages like Python are very powerful, but they're not shell replacements. You want to pack the maximum punch into a the shell.
I don't think many of us care that the command names are a little hard to remember. I have just as much trouble remembering stuff from APIs with nice names like Java.
No, this highlights a weakness in UNIX shells: we have to parse things. It's slow and it's a huge pain. It seriously limits what we can do. grep, sed etc can be used to manipulate streams but nobody ever implements the complete grammar of the input they can get. They implement some subset that's good enough for the job at hand and tweak it when it screws up. It's worked well for decades, but that doesn't mean we can't do better.
Having a data structure passed along a pipe like MSH does is a huge advantage and very efficient, but I think most UNIX people can agree that it's not worth it to bring everything into the same process. What's an alternative? Serialize the data structure (in some human readable form to stay true to UNIX tradition) and pass that down the pipe, from one process to another. That would work with the pipes we have now and the shells we have now, we just need new tools and a serialization protocol.
" And all of that will require processing power. All of those objects have to be converted each and every time they get passed. Even the conversion to text will take cycles."
Are you kidding? Parsing text is one of the hardest things for a modern processor to do. Having fields available in a consistent internal representation allows you to do stuff based on them without having to parse anything, and you don't have to parse things. How many regexen do you write in a typical shell script? I'm not saying there are no disadvantages to Microsoft's way, but speed isn't one of them.
Also, you don't have to launch so many processes with MSH way. *nix shells can be prohibitively slow if you use an iteration strategy that results in lots of processes being launched, but sometimes it's hard to set things up as a pipe because you often have to do more complex parsing.
These things aren't so much of a disadvantage for larger programs that often end up in another language, but small one-time scripts will probably be easier.
I'm not going to use Windows, but if someone can come up with something better than that stupid Python shell replacement on UNIX I'll give it a shot.
Actually it seems to me that new tools for the current shells could serialize objects and pass them through the pipes we have.
Seems to be okay if they live on different chips, which is probably why the Promise card works. Your motherboard might have a separate SATA chip.
I don't remember which kernel versions are affected, but it's a relatively new thing. It's caused by libata, if I recall my debugging correctly. I gave up trying different versions long ago (which is why I've forgotten most of the specifics), I just use the Debian images and try to work around the bugs they have.
"That being said, the statement that distros don't roll their own kernels isn't true, anyway. Take Fedora, for example - if you read Dave Jones' blog, you'll notice that a lot of effort *is* going into stabilizing these and making them regression-free."
Oh they try. Valiantly I'm sure. But they fail. For example, Fedora Core 3 can't see my CD drive unless I put it on a Promise IDE card because of that libata business. I'm sure they'd be able to do better if they weren't starting out with such a disadvantage.
"Outside of that... well, yeah, I guess one could complain about the lack of proper regression testing, QA prior to releases, release schedules and all that. But the truth is that these things have not only hindered but actually *helped* a great deal when it comes to Linux development, so I don't see why they should be abolished. In the end, it's the developers that decide how things should work - and that's good, because it's the developers, not management (this includes everyone who's not involved with development), who know best."
Your pronouns imply you're a kernel developer. Is that the case? You may have a development model that results in features being added faster, but you are not producing kernels that I can risk using for anything important. Judging by the other posts here, I'm not alone. I agree that non-developers shouldn't be in charge of the project, but you should agree that users are free to use something else if what you're making don't meet our needs.
Kernel 2.6 doesn't meet my needs anywhere but my workstation system. It's worth it for the responsiveness, but my workstation is my problem. I can install something else over lunch if I have to. But I will get yelled at if the other machines break, and I don't want 2.6 anywhere near them.
Ultimately I hear a lot of justifications that involve things other than kernels that work robustly from one version from the next, but I don't care about those other things when my system isn't running at all. If you do, that's fine, but I think you should care a little when a Linux update becomes more likely to break stuff than a Windows update.
"With 2.6, bugs are being ironed out MUCH faster"
Unfortunately you can't update to a new release to fix the bugs you have, because every new version is so riddled with regressions that it's just as bad as the last one. Bugs are replaced, not fixed.