I understand that people want to be able to boot their Macs into Linux without having to reinstall the internal drive. I might use this myself, just to play with Linux on my Mac Mini.
What I'm talking about is the idea of using this capability as a kind of "portable Linux". There are so few situations where one might find a free and unused Mac (since a Mac is almost always going to be actually in use: "People like to use the Macintosh"), but there's Windows-infested PCs everywhere... for a "portable Linux" a LiveCD and temp files on the iPod is much more practical.
IDGI either, what's the point of having a Mac-only Linux on ones iPod instead of a boot-anywhere LiveCD so you can boot an otherwise worthless (and much more widely available) Windows box and just use your iPod/Flashdrive as storage?
If they sell 20 times as many songs, they're getting 40c instead of 34c.
But, you say, they won't sell 40 times as many songs...
They may, they may not. Maybe 5c is a bad number, maybe 10c or 25c would work better, I don't know. But they're running the servers anyway and the bandwidth and share of the server that each download requires is so much less than a penny that it's irrelevant. The only thing that matters is how much money they get from each customer and how many customers they have.
So that's the trick. Would they get (say) 10 times as many customers and sell each of them three or four times as many songs per week (or whatever ratio you like)... if the answer is yes, then it's a win for Apple.
You conveniently excluded the three competitively priced models [...]
If you want an MP3 player that takes AAA batteries, you can get them a lot cheaper than Sony's. Rechargable batteries and the circuitry to support them are still expensive enough that leaving them out can easily make for a 30-50% difference in the final price in this price range. It's a whole different market segment, just like portable FM radios (currently running $0.99 on up) are, and it starts at around $40 for 128M units around here. There's a few 512M units cheaper than Sony's, but it's not unreasonable.
But... Apple isn't in that market segment yet. Sony is having a whack at its high end.
The fact that the battery is necessary doesn't mean this isn't worth looking at. Same argument could be made about the shuffle's lack of a display.
I didn't say it wasn't worth looking at, I said it wasn't competition for the iPod Shuffle. It's competing with the high end flash players, not the low end where the Shuffle sits. And that's a tough market, jammed as it is between the iPod Mini and the real low end that the Shuffle's going after.
That's the competition for the shuffle: the under-$100 flash players like the Magic Star.
You haven't heard of the Magic Star flash MP3 player? I bought one about 3 years ago, for my daughter. It's basically the iPod Shuffle with less memory and no shuffle feature. When Jobs came on and started talking about the price and size of flash players, I wanted to crawl through the Internet and shove it down his throat. "This is what you want to make, Steve!", I'd cry, as they dragged me offstage.
Well, damn me if he didn't go ahead and do it. And at a competitive price, too. Now let's see if Sony will catch on as well...
The fact that there's a physics API (NovodeX) that games are already using made me immediately think of the cell processor. This is exactly the kind of thing vector CPUs were originally developed for, back in the Mainframe/Supercomputer days.
When people started talking about the cell processor and the fact that it was PPC based... and tying it in to Apple... the only think I could think of for Apple to really do with it would be to use it for speeding up Quartz and OpenGL. But how about a Powermac with a cell-based coprocessor doing NovodeX acceleration. The Mac could be the gamer PC all of a sudden.
Sounds like real-world auctioneers are feeling the pinch from ebay, and are looking for protection for their declining business model. That's the only reason I can think of for requiring online "auctions" (which are more like resale or consignment stores) to be run by people who have gone through an apprenticeship as auction callers.
They requiring online sellers, whose business is very different from real-world auctions, to learn how to "call" auctions and go through an apprenticeship in that highly specialised skill. How does that make any BUSINESS (your emphasis) sense at all?
How does requiring an online seller to have the skills and experience of an in-person real-world auctioneer... skills that have nothing to do with the automated on-line auction process (which is more like operating a pawn-shop or acting as an appriaser)... do anything to prevent fraud? Explain that, will you please?
why haven't various design decisions of Plan9 become popular?
Because the areas where Plan 9 differs from traditional UNIX tend to be things that are more "all or nothing". You really can't add them to another system without major surgery. Where they could be added, for example making more rather than less system state visible through files (as in/proc) they tend to have been.
Yep. It appears to use the same "security zones" security model that the current "browser-centric" design does... that is, it uses a discretionary access control model where the rights an object has (the "zone" an object is in) is determined by heuristics at the time it's accessed rather than being an inherent and irrevocable (without intevention by an object with greater rights) attribute of the object.
Visual Studio contain schemas for different browser platforms
That's terrifying. That means you can't even use a different browser to avoid it.
No, the NIS is broken above and beyond the call of duty and doesn't work right with Solaris clients or servers, either.
I'm sorry, but I can't see why I should care about the dregs of Sun's attempt to dictate standards to the Internet rather than use DNS like everyone else. When I said that NIS was broken, that's exactly what I meant. Complaining that Tru64 doesn't ship with a "modern NIS" is like complaining that Linux doesn't come with support for Xenix 286 multiplexed files.
Funny, I'm using LPD filters on Tru64 right now. Hint: LPD does not and never has filtered remote printers. This is not a shortcoming of Tru64, it's a design feature of LPD to make early diskless client implementations easier, long before OSF or UI were rumors of rumors.
your code is not portable to other compilers such as gcc or even the various Sun compilers, or sometimes to compilers on slightly different releases of Tru64
I've had code fail to port between versions of GCC, or between the same version (allegedly) of GCC on Red Hat and Debian. The fix is to find where your code is poking at the edges of the envelope and make it more conservative and more portable.
And what I've had to leave in my code to support Sun compilers would turn your hair grey.
The inability of a vendor to publish up-to-date versions of core tools, like sendmail [...]
Up-to-date version of sendmail? What have you been smoking? What's your next fantasy, a stable and secure version of Windows?
Other vendors do keep theirs up to date
Pity. If they didn't try, more people would switch to more reliable, secure, and robust mailers. Which is what they should do.
Tru64 is moribund.
Why yes, Tru64 is moribund. but this is not due to any inherent failing in Tru64, it's a business decision that HP and compaq made years ago... on Carly's watch... and that's all it is.
it makes the point that the IE rendering mode could hurt Firefox
More than Firefox. The Microsoft HTML control (the IE rendering engine) is inherently insecure by design. It's not possible to use it in a way that doesn't open up cross-zone attacks because "security zones" are such a deep part of its design. The IE rendering mode has the potential of hurting anyone who uses it but think they're somehow safer because they're not using IE.
The NIS is broken, the printing services don't follow the documentation nor anyone else's standards, the built-in compiler doesn't handle recent open source code because it's not compliant with any other standards, the NFS is poor, and the sendmail is so old and non-standard it should be called Neanderthal sendmail, having forked off into a species that died sometime in the paleolithic.
All of this seems to come down to "it's not Linux", except for that comment about NFS. Tru64's NFS isn't the best, but it's certainly better than any Linux NFS I've used. And that's about the only criticism that's actually referring to something deep in the system rather than a superficial bit of userland code that you'd probably be replacing anyway whether you're using Linux or Tru64.
I mean... sendmail. Who the hell uses the stock distributed sendmail? On anything, Linux or not?
NIS is broken, no matter who implements it.
The printing services are perfectly bog standard BSD printing. There are basically two printing systems on commercial UNIX... BSD, and System V. If you don't like either, then install the open-source printing system of your choice.
Personally, I like the BSD system. It's archaic, yes, but it's simple and doesn't tend to fail in obscure ways that require extended debugging sessions to track down which unnecessary shell script broke... which is my primary experience of the System V "let's take a generalised batch queue system and stick a poorly implemented ad-hoc print queue manager on it".
The shipped compiler isn't gcc. This is no doubt annoying to someone who thinks "portable code" is something that runs on Red Hat 7.1 *and* Debian... which seems to be the standard an appalling percentage of the open source community.
You'd have the same problems with *any* compiler that wasn't GCC, so this is a dead issue.
It's a pretty good compiler, much better than most, and produces better code than GCC. If you have a problem with Tru64's cc I'd hate to see you try and make any headway with the one on HPUX.
It sounds like you started out wanting to do things the Linux way, regardless, so no matter how good Tru64 was it'd be doomed in your eyes.
My opinion is that Avalon, or more specifically, XAML, will mark the death of ASP. The reason is that Avalon is a client-side technology, but the browser is an important part of the distribution model. XAML is so rich that a browser-contained XAML application will look no different to a process-based Avalon application, and coupled with Web Services or Indigo (as the mechanism to access remote code), an XAML application will make an ASP.NET application look paltry and antiquated.
Microsoft's track record with browser-based applications is one security disaster after another. Their existing browser-centric security model is fragile that I can't see a way to fix it without changing the API and breaking every application that uses it.
If Microsoft's web applications come to depend on that model, they'll never be able to extricate themselves from that mess.
Unfortunately, with the so-called "open source but not really" software that Tru64 was built on, there was no point to that. The most stable, supportable, maintainable use for Alpha hardware these days is running Linux on it.
Well, you know, I've done that. And I'm running Tru64. And I have to say that if you think that you can't have tried it. Ever.
You can still use the middle mouse click to bring up the autoscroller like you mention.
That's the problem. I find the mousewheel makes the middle "button" too finicky to hit. Which is why I want a nice USB 3-button optical mouse. Which is a rant for another time.
I would describe Plan9 as one possible next step in the design of UNIX, rather than something other than UNIX. The fundamental design and API of Plan 9 is virtually indistinguishable from that of traditional UNIX.
The components of the UNIX operating system that follow the original UNIX design are incredibly robust and adaptable. There's a lot of things that are traditionally associated with UNIX that are less so... things like X11, System V IPC, or Berkeley sockets... but it's possible to build a successful UNIX-based OS for which these kinds of components are provided just as compatibility hooks. Apple's demonstrated that.
Plan 9's failure has nothing to do with it not being "like UNIX". Its failure has three legs:
First: availability. Plan 9 was simply not readily available outside Bell Labs until they had more or less abandoned it. If they'd put some marketing muscle behind a release (the Microsoft path) or open-sourced it early (the BSD/Linux path) it might have had a chance if the other problems were solved. What problems? Well, let's go on...
Second: Plan 9 was built around a networked environment containing a variety of specialised computers: display servers, file servers, computation servers. This was great for a research lab, but until very recently this approach created a major hurdle to overcome before you could get started. I was discussing it with Dennis Ritchie at Usenix a few years back... and he didn't see (at that time, of course) a good reason to set up a Plan 9 network for a home user.
Third: Plan 9's window system is utilitarian in the extreme, and heavily optimised for the Bell Labs environment. It would have taken a lot of work to turn 8.5 into something that could compete even with even the early Macintosh and Windows environments for user-friendliness. They did do some interesting UI work later on, but none of it got back to Plan 9 from Inferno that I'm aware of...
UNIX incompatibility was not a major problem compared to these stumbling blocks.
Slashdot Mirror
You're missing the point.
I understand that people want to be able to boot their Macs into Linux without having to reinstall the internal drive. I might use this myself, just to play with Linux on my Mac Mini.
What I'm talking about is the idea of using this capability as a kind of "portable Linux". There are so few situations where one might find a free and unused Mac (since a Mac is almost always going to be actually in use: "People like to use the Macintosh"), but there's Windows-infested PCs everywhere... for a "portable Linux" a LiveCD and temp files on the iPod is much more practical.
IDGI either, what's the point of having a Mac-only Linux on ones iPod instead of a boot-anywhere LiveCD so you can boot an otherwise worthless (and much more widely available) Windows box and just use your iPod/Flashdrive as storage?
All of this... for $0.02 per song?!?
Depends on how many songs they sell, doesn't it?
If they sell 20 times as many songs, they're getting 40c instead of 34c.
But, you say, they won't sell 40 times as many songs...
They may, they may not. Maybe 5c is a bad number, maybe 10c or 25c would work better, I don't know. But they're running the servers anyway and the bandwidth and share of the server that each download requires is so much less than a penny that it's irrelevant. The only thing that matters is how much money they get from each customer and how many customers they have.
So that's the trick. Would they get (say) 10 times as many customers and sell each of them three or four times as many songs per week (or whatever ratio you like)... if the answer is yes, then it's a win for Apple.
*snork* :)
Anyone running Linux on an iBook installed Tux in the apple logo yet?
If it's not running Mac OS it's not a Mac.
You conveniently excluded the three competitively priced models [...]
If you want an MP3 player that takes AAA batteries, you can get them a lot cheaper than Sony's. Rechargable batteries and the circuitry to support them are still expensive enough that leaving them out can easily make for a 30-50% difference in the final price in this price range. It's a whole different market segment, just like portable FM radios (currently running $0.99 on up) are, and it starts at around $40 for 128M units around here. There's a few 512M units cheaper than Sony's, but it's not unreasonable.
But... Apple isn't in that market segment yet. Sony is having a whack at its high end.
The fact that the battery is necessary doesn't mean this isn't worth looking at. Same argument could be made about the shuffle's lack of a display.
I didn't say it wasn't worth looking at, I said it wasn't competition for the iPod Shuffle. It's competing with the high end flash players, not the low end where the Shuffle sits. And that's a tough market, jammed as it is between the iPod Mini and the real low end that the Shuffle's going after.
That's the competition for the shuffle: the under-$100 flash players like the Magic Star.
You haven't heard of the Magic Star flash MP3 player? I bought one about 3 years ago, for my daughter. It's basically the iPod Shuffle with less memory and no shuffle feature. When Jobs came on and started talking about the price and size of flash players, I wanted to crawl through the Internet and shove it down his throat. "This is what you want to make, Steve!", I'd cry, as they dragged me offstage.
Well, damn me if he didn't go ahead and do it. And at a competitive price, too. Now let's see if Sony will catch on as well...
The fact that there's a physics API (NovodeX) that games are already using made me immediately think of the cell processor. This is exactly the kind of thing vector CPUs were originally developed for, back in the Mainframe/Supercomputer days.
When people started talking about the cell processor and the fact that it was PPC based... and tying it in to Apple... the only think I could think of for Apple to really do with it would be to use it for speeding up Quartz and OpenGL. But how about a Powermac with a cell-based coprocessor doing NovodeX acceleration. The Mac could be the gamer PC all of a sudden.
If you want an MP3 player that runs off an AAA battery, you can get it a lot cheaper than $150.
Been there, done that, got the iPod Shuffle.
iPod Shuffle 512M -- $99
NW-E405 512M -- $130
NW-E505 512M+FM -- $150
iPod Shuffle 1G -- $150
NW-E407 1G -- $180
NW-E507 1G+FM - $200
iPod Mini 4G -- $200
Sounds like real-world auctioneers are feeling the pinch from ebay, and are looking for protection for their declining business model. That's the only reason I can think of for requiring online "auctions" (which are more like resale or consignment stores) to be run by people who have gone through an apprenticeship as auction callers.
They requiring online sellers, whose business is very different from real-world auctions, to learn how to "call" auctions and go through an apprenticeship in that highly specialised skill. How does that make any BUSINESS (your emphasis) sense at all?
How does requiring an online seller to have the skills and experience of an in-person real-world auctioneer ... skills that have nothing to do with the automated on-line auction process (which is more like operating a pawn-shop or acting as an appriaser) ... do anything to prevent fraud? Explain that, will you please?
why haven't various design decisions of Plan9 become popular?
/proc) they tend to have been.
Because the areas where Plan 9 differs from traditional UNIX tend to be things that are more "all or nothing". You really can't add them to another system without major surgery. Where they could be added, for example making more rather than less system state visible through files (as in
Even if they use XAML as a replacement for ASP.NET, it will completely render to industry standards on the front end, just like ASP.NET.
:)
Perhaps you should address the original article's comments and explain why the original article is incorrect then.
Uhm, ever heard of .NET?
Yep. It appears to use the same "security zones" security model that the current "browser-centric" design does... that is, it uses a discretionary access control model where the rights an object has (the "zone" an object is in) is determined by heuristics at the time it's accessed rather than being an inherent and irrevocable (without intevention by an object with greater rights) attribute of the object.
Visual Studio contain schemas for different browser platforms
That's terrifying. That means you can't even use a different browser to avoid it.
No, the NIS is broken above and beyond the call of duty and doesn't work right with Solaris clients or servers, either.
I'm sorry, but I can't see why I should care about the dregs of Sun's attempt to dictate standards to the Internet rather than use DNS like everyone else. When I said that NIS was broken, that's exactly what I meant. Complaining that Tru64 doesn't ship with a "modern NIS" is like complaining that Linux doesn't come with support for Xenix 286 multiplexed files.
Funny, I'm using LPD filters on Tru64 right now. Hint: LPD does not and never has filtered remote printers. This is not a shortcoming of Tru64, it's a design feature of LPD to make early diskless client implementations easier, long before OSF or UI were rumors of rumors.
your code is not portable to other compilers such as gcc or even the various Sun compilers, or sometimes to compilers on slightly different releases of Tru64
I've had code fail to port between versions of GCC, or between the same version (allegedly) of GCC on Red Hat and Debian. The fix is to find where your code is poking at the edges of the envelope and make it more conservative and more portable.
And what I've had to leave in my code to support Sun compilers would turn your hair grey.
The inability of a vendor to publish up-to-date versions of core tools, like sendmail [...]
Up-to-date version of sendmail? What have you been smoking? What's your next fantasy, a stable and secure version of Windows?
Other vendors do keep theirs up to date
Pity. If they didn't try, more people would switch to more reliable, secure, and robust mailers. Which is what they should do.
Tru64 is moribund.
Why yes, Tru64 is moribund. but this is not due to any inherent failing in Tru64, it's a business decision that HP and compaq made years ago... on Carly's watch... and that's all it is.
it makes the point that the IE rendering mode could hurt Firefox
More than Firefox. The Microsoft HTML control (the IE rendering engine) is inherently insecure by design. It's not possible to use it in a way that doesn't open up cross-zone attacks because "security zones" are such a deep part of its design. The IE rendering mode has the potential of hurting anyone who uses it but think they're somehow safer because they're not using IE.
The NIS is broken, the printing services don't follow the documentation nor anyone else's standards, the built-in compiler doesn't handle recent open source code because it's not compliant with any other standards, the NFS is poor, and the sendmail is so old and non-standard it should be called Neanderthal sendmail, having forked off into a species that died sometime in the paleolithic.
All of this seems to come down to "it's not Linux", except for that comment about NFS. Tru64's NFS isn't the best, but it's certainly better than any Linux NFS I've used. And that's about the only criticism that's actually referring to something deep in the system rather than a superficial bit of userland code that you'd probably be replacing anyway whether you're using Linux or Tru64.
I mean... sendmail. Who the hell uses the stock distributed sendmail? On anything, Linux or not?
NIS is broken, no matter who implements it.
The printing services are perfectly bog standard BSD printing. There are basically two printing systems on commercial UNIX... BSD, and System V. If you don't like either, then install the open-source printing system of your choice.
Personally, I like the BSD system. It's archaic, yes, but it's simple and doesn't tend to fail in obscure ways that require extended debugging sessions to track down which unnecessary shell script broke... which is my primary experience of the System V "let's take a generalised batch queue system and stick a poorly implemented ad-hoc print queue manager on it".
The shipped compiler isn't gcc. This is no doubt annoying to someone who thinks "portable code" is something that runs on Red Hat 7.1 *and* Debian... which seems to be the standard an appalling percentage of the open source community.
You'd have the same problems with *any* compiler that wasn't GCC, so this is a dead issue.
It's a pretty good compiler, much better than most, and produces better code than GCC. If you have a problem with Tru64's cc I'd hate to see you try and make any headway with the one on HPUX.
It sounds like you started out wanting to do things the Linux way, regardless, so no matter how good Tru64 was it'd be doomed in your eyes.
My opinion is that Avalon, or more specifically, XAML, will mark the death of ASP. The reason is that Avalon is a client-side technology, but the browser is an important part of the distribution model. XAML is so rich that a browser-contained XAML application will look no different to a process-based Avalon application, and coupled with Web Services or Indigo (as the mechanism to access remote code), an XAML application will make an ASP.NET application look paltry and antiquated.
Microsoft's track record with browser-based applications is one security disaster after another. Their existing browser-centric security model is fragile that I can't see a way to fix it without changing the API and breaking every application that uses it.
If Microsoft's web applications come to depend on that model, they'll never be able to extricate themselves from that mess.
Unfortunately, with the so-called "open source but not really" software that Tru64 was built on, there was no point to that. The most stable, supportable, maintainable use for Alpha hardware these days is running Linux on it.
Well, you know, I've done that. And I'm running Tru64. And I have to say that if you think that you can't have tried it. Ever.
Oddly, you just proved my point.
:)
Only if you believe in nanotech.
you still have several thousand engineers working on something.
But it doesn't require an "HP labs" to do it, which was my point.
You can still use the middle mouse click to bring up the autoscroller like you mention.
That's the problem. I find the mousewheel makes the middle "button" too finicky to hit. Which is why I want a nice USB 3-button optical mouse. Which is a rant for another time.
Sounded great until you got to this bit...
Systems like Plan9 [...]
I would describe Plan9 as one possible next step in the design of UNIX, rather than something other than UNIX. The fundamental design and API of Plan 9 is virtually indistinguishable from that of traditional UNIX.
The components of the UNIX operating system that follow the original UNIX design are incredibly robust and adaptable. There's a lot of things that are traditionally associated with UNIX that are less so... things like X11, System V IPC, or Berkeley sockets... but it's possible to build a successful UNIX-based OS for which these kinds of components are provided just as compatibility hooks. Apple's demonstrated that.
Plan 9's failure has nothing to do with it not being "like UNIX". Its failure has three legs:
First: availability. Plan 9 was simply not readily available outside Bell Labs until they had more or less abandoned it. If they'd put some marketing muscle behind a release (the Microsoft path) or open-sourced it early (the BSD/Linux path) it might have had a chance if the other problems were solved. What problems? Well, let's go on...
Second: Plan 9 was built around a networked environment containing a variety of specialised computers: display servers, file servers, computation servers. This was great for a research lab, but until very recently this approach created a major hurdle to overcome before you could get started. I was discussing it with Dennis Ritchie at Usenix a few years back... and he didn't see (at that time, of course) a good reason to set up a Plan 9 network for a home user.
Third: Plan 9's window system is utilitarian in the extreme, and heavily optimised for the Bell Labs environment. It would have taken a lot of work to turn 8.5 into something that could compete even with even the early Macintosh and Windows environments for user-friendliness. They did do some interesting UI work later on, but none of it got back to Plan 9 from Inferno that I'm aware of...
UNIX incompatibility was not a major problem compared to these stumbling blocks.
I guess "catastrophe theory" was too scary, so they had to come up with a more politically correct way of describing that kind of transition...