"Each app runs as a virtual Mac, with the OS acting to stitch together the virtualizations."
ACK! He says, mentally running through the point of contacts with the hardware, events, file system, networking, windowing, interapplication communication, scripting, clipboard. Yeah, you could do it, and in fact, they did do it with Rhapsody's Blue Box "Classic" mode, but you'd practically have to write an entire OS to put beneath it... which, from a certain perspective, is what they did.
As to OS X'isms, and speaking as someone who did Apple/Lisa/Mac development in 77/83/84, I'm pretty happy with the current version. Finder stills needs work, and I remain less than thrilled that O/C is the language of choice, but overall, they've done a pretty good job, and extended the system in ways where Vista is still struggling to catch up.
"Apple's development organization became convinced that to truly take the machine forward, they would require a totally new OS."
That's true. But a good portion of that reasoning lay in the fact that to get to preemptive you needed to rewrite the kernel, event manager, memory manager, file manager, good portions of quickdraw and the graphics engine, device drivers, etc., to make them reentrant. So, by the time you've done that you've rewritten practically the entire OS, and then the real question becomes: do we want to do all of that work, only to fundamentally end up back where we started? And can we even do that without breaking half the applications out there that depend on some obscure bit of functionality or behavior?
"The car you drive is a series of incremental improvement..."
I don't think you want to go down that road, because if you do, we can start talking about the decades of incremental improvements that have gone ito Unix, BSD and Mach. (grin)
"...because Apple and the Free Software community are not monopolies!"
So? I seem to recall several people regarding Apple and the iTMS as such. And Apple is the only place from you can buy a pod or a system with OS X. Besides, there's no law against simply being a monopoly.
"Firefox and OpenOffice do not have hooks into the Linux kernel"
Again, so? Show me where IE and MS Office have "hooks" directly into the NT kernel.
"To the common user it became part of the OS. They assumed they could use XP to encourage MSN membership."
I suspect that most Linux distros ship with FireFox as their main web browser, and probably use their existing user base to "promote" Thunderbird and Lightning and OpenOffice too. Apple uses their base to "promote".mac and iTunes.
I suspect that even under Windows a networking protocol isn't tightly coupled to a graphics or file subsystem. And while under Linux you can make the case that all APIs are "public", there are still those that are considered to be internal to the system.
That study, to my mind, asked the wrong question. What I want to know is, of the music downloaded and frequently listened to, what percentage was eventually purchased?
Saying a high percentage of people who download music ended up buying of them in five in a year is one thing. But if during that year they downloaded a couple of hundred songs to try out, and of those listen to three or four dozen frequently, and ONLY bought five... well, that's not a great percentage.
"Incorrect. It was designed to allow 3-bit color, actually - the quickdraw headers defined 8 colors, not two."
For all practical purposes it was B&W unless you were printing, and even then you had to jump through hoops. To get color onscreen we needed the nearly complete rewrite that was Color Quickdraw on the Mac II. And which nitpicking ignores the rather more serious "single-threaded, single-tasking, use fixed-size memory spaces, and totally without any form of internal or user-based security" issues.
"The overhead of swapping out a hundred low-level globals... but it's just not a factor these days."
Right. Because when you're switching application contexts a thousand times a second you really want to waste time moving hundreds of discontinuous memory locations. Heck, these days just swapping out the stack is a performance hit that has systems designers gnashing their teeth.
"Handles allowed programmers to write programs that were nearly 100% efficient in their use of memory".
And we still had an entire cottage industry devoted to memory managers and debuggers that tried to track down the bugs that system encouraged. And still ignores the fact that just one of those bugs could crash not just that application but the entire system. And still ignores those wonderful fixed-size partitions.
Face the facts. If "rewriting" a few parts of the system were that easy they would have down it. The system design was perfect for a 128K Mac, and horrendous as you attempted to scale it. System globals were scattered everywhere and the non-protected patitioned memory scheme was attrocious.
Worse, practically no system call of any consequence could be done in a preemptive environment. Attempting to do so caused all sorts of bottlenecks and deadlocks, and the existing SystemTask-based swapping system allowed a single resource-hogging app to bring the system to its knees.
Like I said, you need to take off those rose-colored glasses. True, the original MacOS was a great acheivement. So was the Model-T. Today, I refuse to drive either one.
"... those brains, skills and talent are plentiful too"
Ah, the egalitarian viewpoint. Of course, plenty of people have them, in various combinations and proportions. But do they use those gifts? Do they do the work, or do they sit at their desk and daydream about how nice it would be if things were different. Do they bet their livelyhoods on their dreams, or do they sigh and then go to work and pull down a paycheck each day? Yes, such may be plentiful. But are those gifts used?
"If not Edison, then Tesla"
Precisely. Of the millions of people alive at the time, one, or two, or three had the insights and abilities and determination needed to make it happen.
"Well, lets just say that the world was far, far more enriched by the efforts of a single solitary man writing a book..."
Again, you just proved my point. "A single solitary man." And without that single, solitary man, that magnificent story would not exist.
Other "skilled, talented" people have written about such things. Some, you may argue, have even done it better. Even so, the vast majority of them have fallen by the wayside and been forgotten. And untold millions have thought about doing it better. And done nothing.
And if you think that there are plenty of "skilled, talented" people, then I suggest you spend a week or so reading unsolicited manuscripts at a major magazine or publisher. It's so bad that some publishers view it as a waste of time, return them unopened, and only accept manuscripts from agents.
True creativity and insight and skill and talent are exceedingly rare gifts. Even rarer is finding that combination in a single individual. Even fewer take those skills and put them to work.
"But they threw out the baby with the bathwater when they ditched MacOS."
As long as you're waxing rhapsodic about that OS "written from the ground up in the early 80s to be graphical", you might also remember that it was also written from the ground up to be B&W, single-threaded, single-tasking, use fixed-size memory spaces, and totally without any form of internal or user-based security.
Any of those things that were added on later were major hacks to the system. Some, like the non-preemptive MultiFinder (switcher) were ingenious hacks, but hacks nontheless. Or are you saying a modern OS should swap out hundreds of shared low-level global variables on every context switch?
Or that, since you mentioned HLOCK, why a modern OS should have a handle-based non-protected fixed-patition-sized memory system, itself probably responsible for half the memory allocation/corruption bugs and crashes in any given Mac application. Or why a program needs me to allocate more memory to it when there's a half-gig free?
Or perhaps you can explain just why the system resource and process-slicing allocation kernal of a modern OS needs to be "graphical" from the ground up? Or conversely, why graphics, networking, file management, and other subsystems should not be layered on top of a rock-solid base?
I mean, if you really take the time to actually think about it, you might find that the "good old days" are in fact nothing but a fond, hazy memory... and far removed from the truth.
As has been reported before, each widget includes whatever shared files are needed to make it run and the size of those files is reported along with that of the base widget. But since they're shared, each additional widget typically only uses a small amount of additional memory. Most well designed widgets also sleep when not being used (offscreen) so they're not hogging the processor either.
So is the Dashboard a "massive resource hog"? I think not...
Huh. As if in the real world the enemy doesn't try to sneak up behind you, or send scouts and soldiers into areas you've just vacated. I think if you ask the guys in Iraq they'd all agree that an area once cleared should stay cleared. Would make things much easier.
Precisely. That's why authors and publishers and producers will give you a strained smile and attempt to slide away when you run up to them announcing your latest idea for a book or movie. They know that ideas are plentiful, worth a dime a dozen, and that they're probably overpriced even then.
Hey! I have an idea. Let's create the world's best web browser. Cool. And now where are we? Well... no where. Now, let's talk about people who did just that, and the dozens upon dozens of man-years it took to write FireFox and get it to the point where it is now.
Hey! I have an idea. Let's write a book about wizards and elves and hobbits. And now that we're done with the idea, why don't we talk about JRRT, who spent the better part of his life actually creating that story and that world and those characters.
Hey! I have an idea. Let's make it into a movie! But how many people had that idea, and did nothing about it? Now let's talk about Peter Jackson, and the, what... nine years it took to actually make that film trilogy.
The fact is that IP law is NOT and never has been about protecting ideas. It is, however, about protecting a specific implementation of those ideas, and about protecting the people who did so. It's about protecting and encouraging that time and effort and skill and talent and investment.
In the case of the FireFox team, they knew that their investment in time and effort was being made in a product that was going to be given away to the world, and they made that choice. New Line made the investment in PJ and LOTR in the hope that people would like the film, and that they had the potential to be rewarded if that were the case.
They also knew it was a possibility that the public could hate it, and that they could lose their shirts. They rolled the dice. And won. But would New Line have invested in a relatively unknown director and production knowing there was no way whatsoever they would get that investment back? Would you?
You talk about value increasing upon propagation, but would the world have been richer or poorer without that film at all?
That's why all this talk about "ideas" is nothing more than a straw man, and little more than an attempt to trivialize the situation. Actually write that book or software, or produce that movie, do the work to implement some idea, and then--and only then--will we have something to talk about.
Yes, ideas are plentiful. But the skill and talent and time and resources needed to successfully implement them... are not. And that, if it has value to you, is what you're really paying for...
Rubbish. All of the examples in the article simply illustrate a wider choice of options that are available to the property owner.
To fall back on the often misued automobile example. I can design a car and sell the plans. Or I can design it and give the plans away. Or I can give them away under a license that says you can use them, but never charge for them. In fact, I can build the damn car and try to sell it. Or build it and give it to whomever I wish.
So you might think that, in your spare time, writing software and giving it to the world is a good thing. I may, contrarily, write software and try to sell it, needing to feed the kids and pay the rent. Or you can sell yours and I can give mine away. In any case, the market will decide if our creations have value, and are worth what we ask.
Wow. Being able to instantly slap a label on someone and reduce them down to that label, and only that label, why, it must make your thinking process [sic] highly efficient. And, as you say, really explains a lot...
I thnk it better maps modern OS cluster and memory pages sizes to the drive, improves throughput, allows for higher capacity drives, and, not so incidentally, zaps 75% of the space needed for sector metadata (id, sync, ecc, etc.).
Not only that, but the tense "to be" implies that they have yet to rerwrite 60% of the code.
Frankly, I don't believe it. I might believe that by the time it ships 60% of the code will have been rewritten, but I don't believe they've been sitting on their hands doing nothing for the past several years.
"There are other times when you're doing computationally intensive tasks such as: compiling, ripping, packing files...."
In which case offloading effects to the GPU should be no problem.
"... watching video. I don't want the GUI to compound the problem and fight for system resources when I'm just opening a window..."
And in which case, you're no longer focusing your attention solely on the video, are you?
Bottom line is that, in most cases, such effects are visual cues as to what's going on, are off-loaded to the GPU anyway, should be even less of an issue as dual/quad-core systems become the norm, and, as stated, can be turned off if you don't want them.
It's possible. Then again, that 70% would consist almost entirely of all of the personal home page "sites" located at Verio and all the other $5/mo hosting services.
So, percentage of distinct, individual sites? Maybe. Percentage of internet web pages as a whole? No way.
I second this one. I've never had a problem with speed, and simply holding the book in front of my iSight camera beats buying a dedicated bar-code reader just for that function.
"...is trying to avoid glaring at the enormous holes and more subtle flaws that pepper them."
Which only goes to show the fallacy of people thinking they can pick up a new language in a few hours, days, or even weeks. Without knowing the language, syntax, common assumptions, definitions, and design patterns, the standard functions, and the underlying framework that supports it, your understanding of what a given piece of code (contract) is going to do when executed is going to be, shall we say... less than perfect.
Slashdot Mirror
ACK! He says, mentally running through the point of contacts with the hardware, events, file system, networking, windowing, interapplication communication, scripting, clipboard. Yeah, you could do it, and in fact, they did do it with Rhapsody's Blue Box "Classic" mode, but you'd practically have to write an entire OS to put beneath it... which, from a certain perspective, is what they did.
As to OS X'isms, and speaking as someone who did Apple/Lisa/Mac development in 77/83/84, I'm pretty happy with the current version. Finder stills needs work, and I remain less than thrilled that O/C is the language of choice, but overall, they've done a pretty good job, and extended the system in ways where Vista is still struggling to catch up.
That's true. But a good portion of that reasoning lay in the fact that to get to preemptive you needed to rewrite the kernel, event manager, memory manager, file manager, good portions of quickdraw and the graphics engine, device drivers, etc., to make them reentrant. So, by the time you've done that you've rewritten practically the entire OS, and then the real question becomes: do we want to do all of that work, only to fundamentally end up back where we started? And can we even do that without breaking half the applications out there that depend on some obscure bit of functionality or behavior?
"The car you drive is a series of incremental improvement..."
I don't think you want to go down that road, because if you do, we can start talking about the decades of incremental improvements that have gone ito Unix, BSD and Mach. (grin)
So? I seem to recall several people regarding Apple and the iTMS as such. And Apple is the only place from you can buy a pod or a system with OS X. Besides, there's no law against simply being a monopoly.
"Firefox and OpenOffice do not have hooks into the Linux kernel"
Again, so? Show me where IE and MS Office have "hooks" directly into the NT kernel.
I suspect that most Linux distros ship with FireFox as their main web browser, and probably use their existing user base to "promote" Thunderbird and Lightning and OpenOffice too. Apple uses their base to "promote" .mac and iTunes.
I thought stealing content wasn't theft? Boy, now I'm confused...
I suspect that even under Windows a networking protocol isn't tightly coupled to a graphics or file subsystem. And while under Linux you can make the case that all APIs are "public", there are still those that are considered to be internal to the system.
Saying a high percentage of people who download music ended up buying of them in five in a year is one thing. But if during that year they downloaded a couple of hundred songs to try out, and of those listen to three or four dozen frequently, and ONLY bought five... well, that's not a great percentage.
For all practical purposes it was B&W unless you were printing, and even then you had to jump through hoops. To get color onscreen we needed the nearly complete rewrite that was Color Quickdraw on the Mac II. And which nitpicking ignores the rather more serious "single-threaded, single-tasking, use fixed-size memory spaces, and totally without any form of internal or user-based security" issues.
"The overhead of swapping out a hundred low-level globals ... but it's just not a factor these days."
Right. Because when you're switching application contexts a thousand times a second you really want to waste time moving hundreds of discontinuous memory locations. Heck, these days just swapping out the stack is a performance hit that has systems designers gnashing their teeth.
"Handles allowed programmers to write programs that were nearly 100% efficient in their use of memory".
And we still had an entire cottage industry devoted to memory managers and debuggers that tried to track down the bugs that system encouraged. And still ignores the fact that just one of those bugs could crash not just that application but the entire system. And still ignores those wonderful fixed-size partitions.
Face the facts. If "rewriting" a few parts of the system were that easy they would have down it. The system design was perfect for a 128K Mac, and horrendous as you attempted to scale it. System globals were scattered everywhere and the non-protected patitioned memory scheme was attrocious.
Worse, practically no system call of any consequence could be done in a preemptive environment. Attempting to do so caused all sorts of bottlenecks and deadlocks, and the existing SystemTask-based swapping system allowed a single resource-hogging app to bring the system to its knees.
Like I said, you need to take off those rose-colored glasses. True, the original MacOS was a great acheivement. So was the Model-T. Today, I refuse to drive either one.
So which is it? To me, massive redistribution of the latest hit single would also seem to have an immediate impact on sales.
Yeah, it's a good thing that thousands of people aren't adding code, features, applications, and systems to Linux. Oh, wait...
Ah, the egalitarian viewpoint. Of course, plenty of people have them, in various combinations and proportions. But do they use those gifts? Do they do the work, or do they sit at their desk and daydream about how nice it would be if things were different. Do they bet their livelyhoods on their dreams, or do they sigh and then go to work and pull down a paycheck each day? Yes, such may be plentiful. But are those gifts used?
"If not Edison, then Tesla"
Precisely. Of the millions of people alive at the time, one, or two, or three had the insights and abilities and determination needed to make it happen.
"Well, lets just say that the world was far, far more enriched by the efforts of a single solitary man writing a book..."
Again, you just proved my point. "A single solitary man." And without that single, solitary man, that magnificent story would not exist.
Other "skilled, talented" people have written about such things. Some, you may argue, have even done it better. Even so, the vast majority of them have fallen by the wayside and been forgotten. And untold millions have thought about doing it better. And done nothing.
And if you think that there are plenty of "skilled, talented" people, then I suggest you spend a week or so reading unsolicited manuscripts at a major magazine or publisher. It's so bad that some publishers view it as a waste of time, return them unopened, and only accept manuscripts from agents.
True creativity and insight and skill and talent are exceedingly rare gifts. Even rarer is finding that combination in a single individual. Even fewer take those skills and put them to work.
As long as you're waxing rhapsodic about that OS "written from the ground up in the early 80s to be graphical", you might also remember that it was also written from the ground up to be B&W, single-threaded, single-tasking, use fixed-size memory spaces, and totally without any form of internal or user-based security.
Any of those things that were added on later were major hacks to the system. Some, like the non-preemptive MultiFinder (switcher) were ingenious hacks, but hacks nontheless. Or are you saying a modern OS should swap out hundreds of shared low-level global variables on every context switch?
Or that, since you mentioned HLOCK, why a modern OS should have a handle-based non-protected fixed-patition-sized memory system, itself probably responsible for half the memory allocation/corruption bugs and crashes in any given Mac application. Or why a program needs me to allocate more memory to it when there's a half-gig free?
Or perhaps you can explain just why the system resource and process-slicing allocation kernal of a modern OS needs to be "graphical" from the ground up? Or conversely, why graphics, networking, file management, and other subsystems should not be layered on top of a rock-solid base?
I mean, if you really take the time to actually think about it, you might find that the "good old days" are in fact nothing but a fond, hazy memory... and far removed from the truth.
So is the Dashboard a "massive resource hog"? I think not...
Huh. As if in the real world the enemy doesn't try to sneak up behind you, or send scouts and soldiers into areas you've just vacated. I think if you ask the guys in Iraq they'd all agree that an area once cleared should stay cleared. Would make things much easier.
Precisely. That's why authors and publishers and producers will give you a strained smile and attempt to slide away when you run up to them announcing your latest idea for a book or movie. They know that ideas are plentiful, worth a dime a dozen, and that they're probably overpriced even then.
Hey! I have an idea. Let's create the world's best web browser. Cool. And now where are we? Well... no where. Now, let's talk about people who did just that, and the dozens upon dozens of man-years it took to write FireFox and get it to the point where it is now.
Hey! I have an idea. Let's write a book about wizards and elves and hobbits. And now that we're done with the idea, why don't we talk about JRRT, who spent the better part of his life actually creating that story and that world and those characters.
Hey! I have an idea. Let's make it into a movie! But how many people had that idea, and did nothing about it? Now let's talk about Peter Jackson, and the, what... nine years it took to actually make that film trilogy.
The fact is that IP law is NOT and never has been about protecting ideas. It is, however, about protecting a specific implementation of those ideas, and about protecting the people who did so. It's about protecting and encouraging that time and effort and skill and talent and investment.
In the case of the FireFox team, they knew that their investment in time and effort was being made in a product that was going to be given away to the world, and they made that choice. New Line made the investment in PJ and LOTR in the hope that people would like the film, and that they had the potential to be rewarded if that were the case.
They also knew it was a possibility that the public could hate it, and that they could lose their shirts. They rolled the dice. And won. But would New Line have invested in a relatively unknown director and production knowing there was no way whatsoever they would get that investment back? Would you?
You talk about value increasing upon propagation, but would the world have been richer or poorer without that film at all?
That's why all this talk about "ideas" is nothing more than a straw man, and little more than an attempt to trivialize the situation. Actually write that book or software, or produce that movie, do the work to implement some idea, and then--and only then--will we have something to talk about.
Yes, ideas are plentiful. But the skill and talent and time and resources needed to successfully implement them... are not. And that, if it has value to you, is what you're really paying for...
To fall back on the often misued automobile example. I can design a car and sell the plans. Or I can design it and give the plans away. Or I can give them away under a license that says you can use them, but never charge for them. In fact, I can build the damn car and try to sell it. Or build it and give it to whomever I wish.
So you might think that, in your spare time, writing software and giving it to the world is a good thing. I may, contrarily, write software and try to sell it, needing to feed the kids and pay the rent. Or you can sell yours and I can give mine away. In any case, the market will decide if our creations have value, and are worth what we ask.
Your choice. My choice.
Wow. Being able to instantly slap a label on someone and reduce them down to that label, and only that label, why, it must make your thinking process [sic] highly efficient. And, as you say, really explains a lot...
I thnk it better maps modern OS cluster and memory pages sizes to the drive, improves throughput, allows for higher capacity drives, and, not so incidentally, zaps 75% of the space needed for sector metadata (id, sync, ecc, etc.).
Frankly, I don't believe it. I might believe that by the time it ships 60% of the code will have been rewritten, but I don't believe they've been sitting on their hands doing nothing for the past several years.
In which case offloading effects to the GPU should be no problem.
"... watching video. I don't want the GUI to compound the problem and fight for system resources when I'm just opening a window..."
And in which case, you're no longer focusing your attention solely on the video, are you?
Bottom line is that, in most cases, such effects are visual cues as to what's going on, are off-loaded to the GPU anyway, should be even less of an issue as dual/quad-core systems become the norm, and, as stated, can be turned off if you don't want them.
What's the problem again?
I suggest you ask your friends and co-workers if this is true, or if you just think it is...
So, percentage of distinct, individual sites? Maybe. Percentage of internet web pages as a whole? No way.
Nah, they just print more when they need it. They're covered...
I second this one. I've never had a problem with speed, and simply holding the book in front of my iSight camera beats buying a dedicated bar-code reader just for that function.
Which only goes to show the fallacy of people thinking they can pick up a new language in a few hours, days, or even weeks. Without knowing the language, syntax, common assumptions, definitions, and design patterns, the standard functions, and the underlying framework that supports it, your understanding of what a given piece of code (contract) is going to do when executed is going to be, shall we say... less than perfect.