to tell you the truth installation is the same between linux adn windows whatever.
To tell you the truth, no it isn't. You have to find out all kinds of obscure hardware settings to install Linux. You don't need them on Windows or the Mac. This is a well-known fact and I'm not sure why you are disputing it here.
trying to install NT as a dual boot with 98 is just as a pain in the ass as linux is.
Yes, this obscure configuration of a Windows system is nearly as much of a pain to set up as a basic Linux installation. So? That's like saying it's just as hard to replace the engine on a Ford as the headlights on a Chevy. It's no basis for saying Ford and Chevrolet are the same.
Linux installers have been on par with those for WinDOS since at least Redhat 5.0.
Not even close. You still have to enter all sorts of obscure hardware information in Linux. Not so in current versions of Windows, and never so in any version of Mac OS.
For an example of a real-world application that has suffered from MySQL's deficiencies, take a look at Bugzilla. It seemed great at first, but then it started to bog down badly last fall on a few tens of thousands of bug reports.
As the anonymous coward pointed out, comparing MySQL, which is not a real database, to SQL Server does not enhance your credibility. It's a good example of the inferior performance of open source projects. Once you get into large data sets and multiple users, it breaks down right away due to the lack of row-level locking. It's only good for toy projects.
cc:Mail is an interesting case. It did suck, both on the server and for the user, but for a few years it ruled the roost even though there was superior free software. One downside of commercial software is that it suffers (or benefits) from network effects that cause time-to-market considerations to dominate over quality considerations. But note that although it took awhile, the market did select cc:Mail out of the gene pool.
My statements were about general trends. I certainly did not mean to imply that in every single case, commercial software beat free software. I could come up with my own examples to the contrary; Lutris Enhydra is better than most commercial application servers, for example. However, I think it would be sticking one's head in the sand to ignore the fact that generally speaking, commercial software is superior to its free counterparts in terms of:
All good points. Add to that the fact that free software or open source software is usually inferior to its commercial counterparts in three critical areas: usability, performance, and reliability. Each of these three issues is a major factor in TCO, total cost of ownership.
"Free" software is usually more expensive than commercial software. The reason is easy to understand. The commercial software development model applies financial resources to address problems on the developer side, offloading problems from the user onto the developer. By spending money and time on the development side, both are reduced on the user side. The user is assumed to be primarily interested in the results of using software, rather than in the software itself.
Both the free software and open source models invert this, offloading costs from the developer to the user. The user is assumed to be a software hacker with plenty of free time to spend tinkering, and a desire to spend time that way. In other words, the user is assumed to be a software hobbyist. In the under 1% of cases in which this assumption about the hobbyist user is true, then free or open source software conveys value, but in the other 99%+, commercial software is superior.
Netscape users are STILL 15%-20% of the market, maybe more.
Try 7%, and falling 1% every two months.
Mozilla share is well under 1%.
Tim
Re:Hate GIMP on Linux, why would I like it on MacO
on
GIMP And OS X
·
· Score: 2
Seriously, GIMP on Linux in intolerable.
Free software is generally inferior to commercial software is performance. Performance tuning tools on Linux are very weak; they're rarely even used. Commercial software vendors don't have this luxury, since performance is an important factor in the market.
I don't want to get into another TCO analysis, but look at the cost of using GCC versus the cost of using CodeWarrior, CodeWarrior compiles several times as fast as GCC, but it costs a few hundred dollars. Having a programmer sitting on his or her flabby white ass waiting for the compiler is enormously expensive, so this is one of those places where performance is directly convertible into productivity numbers. The commercial software turns out to be tens of thousands of dollars less expensive per programmer per year. Ditto the glacial GIMP versus the reasonably tuned Photoshop.
And this is only one of the deltas. Add in the cost of missing features like support for printing (CMYK) and color calibration (an incredibly expensive thing to do by hand, due to wasted person-hours and print proof costs), as well as the inherent productivity loss in an inferior UI, and you wind up with a major economic equation in favor of Photoshop over GIMP.
Free software is more expensive than commercial software. Time is money.
It would cost me a lot less to just buy something that already does the job well.
Yes, this is another point that's often missed by the free software yahoos. Free software isn't free when it inflates total cost of ownership. Bad user interface has a direct downward effect on productivity that makes bad free software far more expensive than good commercial software. Almost all free software is noticeably inferior to its commercial counterparts.
It's easy to compute this sort of thing given a few simple assumptions. The GIMP's user interface is significantly inferior to that of Photoshop, as many people here have noted. Let's say that this means a 25% productivity loss, that the average heavy graphics user uses their main graphic tool 16 hours a week, and that the time of a graphics professional is about $40 an hour compensation and $20 overhead.
That means that on a week by week basis, using the GIMP costs $240 in lost productivity. That means it will take less than three weeks for Photoshop to pay for itself at $600. Over the course of a working year, your "free" solution has cost you $11,400.
Don't like the numbers? Tweak them all you like, but a reasonable lower bound for the basic productivity loss is 10% (while a more realistic figure is above 50% -- most free SW UI is really bad). Any reasonable numbers plugged into the formula still leave thousands of dollars in lost productivity per year from using the inferior free tool.
Tim
Re:GIMP has it's work cut out for it...
on
GIMP And OS X
·
· Score: 1
Show that to a MacOS user, and they'll laugh in your face.
No kidding. It's amazing that people still don't get it. It's 2001 for frick's sake.
Listen up, people. The command line has been obsolete for seventeen years now. You are out of touch with modern understanding. Your clinging to absurd and discredited design approaches is tantamount to creationism. If you want to continue to marginalize yourselves and make yourselves irrelevant to computing for the people, you're free to do that, but don't be surprised that your subculture is spiraling down the toilet bowl and that everyone else in the world is using this century's paradigm.
And if you want access to low-level Mac system features, there's a way to do that. It's called an API. It's what real software engineers use. Command lines are for tinkerers, not for engineers.
Why hasn't it happened? I think one of the big reasons is user friendliness.
Obviously, and it's pretty discouraging to see so little discussion of that major factor in this thread. Linux software has never caught up to what Macintosh people got used to in 1984 and Windows people got used to in 1995. The internal discourse within the Linux community is appallingly clueless when it comes to all the advances that have happened in the field over the last two decades. This is a culture that can't produce software that pleases today's mass-market computer users, and not because something is wrong with the users -- it's because the users' critical standards have evolved and Linux programmers hold those standards in contempt.
Is it possible that the vast majority of people developing Linux are programmers, and very few are writers, artists, designers (user interface people)? Since it's built by programmers, it suits them just fine, but others struggle with Linux because little emphasis is placed on usability. Programmers are accountable only to other programmers.
The normal case in discussing users within the open source discourse community is to be insulting to anyone who is not a programmer. Unfortunately that shuts out 99+% of the market.
User interface people are accustomed to getting paid for their work, and seem unlikely (to me) to work on the UI and documentation for Linux for free.
Yes, professional quality user interface design work is both resource-intensive (read: expensive) and rare in terms of the amount of talent and skill available in the professional community. If you have the expertise, it's a seller's market for you. For years now this shortage has allowed compensation for talented user interface people to compare favorably with the contracting fees of senior software engineers. No one could develop an entire modern widget set or modern application with adequate user testing, iterative design, and field observation under open source conditions. Airplane tickets, mirror labs, and designer person-months don't just grow on trees. Eazel is reported to have spent $15 million to produce a file browser.
Perhaps one of the larger companies, Redhat for example, could hire some usability people that could contribute. For example, when the Macintosh was created, there was a significant amount of time/money spent on design and usability. Will that ever happen for Linux?
Only if open source becomes desirable for investors again, and that seems unlikely to happen. The original rationales behind the open source movement never made good economic sense. Having had the opportunity to spend investor capital, open source companies have mostly squandered it. Getting funding for one now would be next to impossible.
Except that sometimes you want to pass a pointer around, and not the data to which the pointer points... even if it's already a reference deep.
Maybe I'm missing something, but I don't see how those goals are in conflict. I'm not saying get rid of pointers; I'm just saying there's no reason to have separate operators for a field of a pointer, a field of a reference, and a field of a pointer to a pointer. The dot operator could easily do all of those.
Or better yet, get rid of the distinction between -> and . since in practice the compiler can always determine when a . needs to be changed to a -> or deeper dereference. The distinction between the operators is just an error trap.
What people miss about free software is that when you buy free software, you get _additional_ value - you get freedom to do what you want with it, which makes it more, not less, valuable.
In practice, though, this value requires significant additional expenditure to realize. An open source project requires intense commitment to get involved with technically, if it's of a large size and if the changes you want to make are anything but trivial and cosmetic.
I've looked at getting involved in various large open source projects which interest me -- Mozilla, the Linux kernel, Eazel, gcc, etc. -- and in every case I found that it was by no means possible to go in, make a quick change, and get out. In every case, I found that I would have to adopt those projects as my lifestyle for at least two months, and sometimes more, before I was reasonably functional in the code bases. It's less like "changing a program" and more like "joining a religion." It's harder to get started in open source projects than commercial ones because the documentation is terrible and the coding styles are a Frankenstein patchwork.
A two-month startup time for a software architect means a five-figure investment just to get started on an open source project, before actually adding anything significant. That's not the simplest value proposition in the world. In fact, it's a value that you can guarantee most customers will never have the resources to realize, which is to say, the median value is zero.
Now, looking more broadly at the value proposition, note that there are significant negative values in most open source software compared to commercial counterparts:
inadequate testing
incomprehensible documentation
no user testing
1970's-era interface design standards
difficult installation
lack of technical support
And it appears that for the median customer, the value proposition is significantly negative.
Tim
Re:Didn't Steve Jobs Speak at MacWorld about....
on
Another Look At OS X
·
· Score: 1
The Ars Technica Review confirms problems with video playback performance under Mac OS X.
QuickTime performance remains problematic on the G3. I was unable to play even a single copy of the large (588x440) version of the Ruby iMac television advertisement at the full framerate on the G3/400, even on a totally idle system. This movie plays just fine in Mac OS 9 on the same machine. The dual G4/450 does much better, happily playing two copies of this movie simultaneously at full speed on a lightly loaded system. Obviously, the G4's AltiVec unit helps QuickTime playback a great deal, but I'm still puzzled by the poor G3 performance, especially the disparity between playback in OS X versus Mac OS 9. This has been a problem throughout Mac OS X's development, and it's a shame to see that it's made it into the 10.0 release. Is Apple simply giving up on the G3 in favor of G4 optimizations?
In other words, it can't play DVDs yet because it's not fast enough.
I hope this is helpful information for people who didn't see how it could be possible for real-time high-bandwidth operations to play slower on a system with advanced multitasking. Primitive multitasking can get in the way less.
Tim
Re:Didn't Steve Jobs Speak at MacWorld about....
on
Another Look At OS X
·
· Score: 1
It's just that *Apple's* applications that perform those tasks aren't ready. Of course, that doesn't mean a third-party can't write software to do just that.
Re:Didn't Steve Jobs Speak at MacWorld about....
on
Another Look At OS X
·
· Score: 1
Today Roxio is reporting that it has been unable to port Toast to Mac OS X.
"We've 'carbonized' Toast as much as we can," said Victor Nemechek, product manager for Toast, the popular CD burning software from Roxio. "You can get your CDs all ready to burn, but the final step--you can't do that." Carbonizing refers to taking existing code and moving it over to Mac OS X.
Apple shipped Mac OS X without full support for CD-rewritable, DVD and DVD-recordable drives. Besides its own troubles, developers say, Apple also failed to deliver adequate tools for third-party software programs.
"The I/O kit that Apple shipped in the release version of OS X is not quite complete," Nemechek said, referring to a computer's input/output system. This means companies developing software for CD-RW, DVD and tape drives are at a standstill in their development efforts, he added.
Apple is expected to add CD-RW functionality to Mac OS X later this month, but Nemechek said that would likely not immediately solve the problem for Roxio or other developers working with I/O-dependent hardware.
"There are some exciting things about OS X, but problems like this just validate my belief that there is no compelling reason for most people to go out and get OS X right now," Deal said.
Apple declined to comment on the I/O kit.
I consider these comments a validation of my original observation that the DVD and CD-RW features did not simply slip, but were due to deeper architectural problems in Mac OS X, which could not be outsourced due to their close coupling with the system.
Tim
Re:Didn't Steve Jobs Speak at MacWorld about....
on
Another Look At OS X
·
· Score: 1
I continue to be amazed by the number of people who've apparently never successfully outsourced a driver, an installer, a utility program, a codec, or some other leaf-node software. It's been pointed out about a half dozen times in this thread already that there are many kinds of software that can be outsourced without slipping the schedule, based on the strength of coupling to the core project, but it appears this aspect of Brooks's Law is over a lot of heads. Sad, really.
Tim
Re:Didn't Steve Jobs Speak at MacWorld about....
on
Another Look At OS X
·
· Score: 1
Was there a particular reason you thought Toast was compatible with Mac OS X? I looked at the Roxio web site and didn't find anything about Mac OS X support.
Thanks, Tim
Re:Didn't Steve Jobs Speak at MacWorld about....
on
Another Look At OS X
·
· Score: 1
Contractors can write utilities that don't need to be tightly coupled to the main project. This is normal and I've seen it work many times in my professional life.
Again, I'm getting the feeling that there is an emotional reaction here to the idea that UNIX scheduling could ever be less than perfect. If it's a religious issue, I'm not interested in pursuing it on that basis.
Tim
Re:Didn't Steve Jobs Speak at MacWorld about....
on
Another Look At OS X
·
· Score: 1
Apple can pay for as many hands as it wants, especially for features that are critical to its marketing campaign. That's why I can't see a leaf-node feature like DVD playback as being a problem unless there's a broader issue. Any decent contracting house could do that in a month or two for a few hundred grand at most, if it were feasible to do it at all.
People have been churning out CD writer apps for many years and there's no apparent reason that one couldn't have been contracted out here as well, unless there's some reason the work has to be tightly coupled to the main system.
I'm not insinuating anything, and your response seems rather defensive. I'm saying it doesn't make sense to me -- as a former Apple technical lead -- that these particular critical features should have slipped. I have speculated on one possible reason, but I'm by no means committed to that possibility as the one and only truth. If all you can see is an insult to a beloved kernel, that's your interpretation, not mine.
Porting cdrecord would be a good test of the possibility that problems in Mac OS X scheduling are involved in the slip.
Tim
Re:Didn't Steve Jobs Speak at MacWorld about....
on
Another Look At OS X
·
· Score: 1
DVD playback and CD burning are so integral to Apple's current marketing that their lack suggests a deeper problem -- that is, there may be some technical reason that these things can't be done on the current release of Mac OS X. If it were just a matter of driver support, it could have been solved by throwing contractors at the problem. It may be something more architectural, something that was realized too late and that would have ripple effects throughout the system.
For instance, if the scheduling heuristics were incapable of avoiding the occasional long pause -- which would not be surprising on a non-real-time time-sliced OS -- that would blow away both of those features, which depend on the rock-steady delivery of large amounts of data over extended periods of time. You could do this on Mac OS because there wasn't really a scheduler to get in the way. Adding a real kernel makes it a harder problem to solve.
Will RMS be fined 1$ every time any of the GNU utilities crash, or Linus everytime Linux crashes?
You might consider reading the article before you respond to it:
The third kind is creative software. It is dreamed up by people who fancy themselves artists, to push the boundaries of the human experience. "Let's say you wanted to create software so that kids can make music by wiggling their nose," Lanier says. The program may be buggy as a July barbecue. But if it is sufficiently intriguing, people will put up with defects because the new experience is thrilling.... "There'd be different legal categories of software. If you want to rush it to market, and have first-mover advantage and see what happens, fine. You could label it creative software. But much of your code will be open to the public."
In The Design of Everyday Things, Don Norman applies a psychological model of "learned helplessness" to the phenomenon of people blaming themselves for design mistakes. He says that there are so many bad designs in everyday life that we've been beaten down by them, and begun to blame ourselves for the failings of designers.
It's a pretty compelling argument, and it may help explain why people don't reject badly designed technology. As a designer I constantly run into people who insist that any problem they experience is their own fault and who get that deer-in-the-headlights look if you explain that the system could have been designed so that the error didn't happen.
Slashdot Mirror
To tell you the truth, no it isn't. You have to find out all kinds of obscure hardware settings to install Linux. You don't need them on Windows or the Mac. This is a well-known fact and I'm not sure why you are disputing it here.
trying to install NT as a dual boot with 98 is just as a pain in the ass as linux is.
Yes, this obscure configuration of a Windows system is nearly as much of a pain to set up as a basic Linux installation. So? That's like saying it's just as hard to replace the engine on a Ford as the headlights on a Chevy. It's no basis for saying Ford and Chevrolet are the same.
Tim
Not even close. You still have to enter all sorts of obscure hardware information in Linux. Not so in current versions of Windows, and never so in any version of Mac OS.
Tim
No, row level locking isn't coming to a stable release until MySQL 4. Here are some relevant URLs:
Slashdot | MySQL 3.23 Declared Stable -- search for "lock"
10/30/00: NuSphere to Contribute Row-Level Locking to MySQL Database
01/30/01: NuSphere Contributes Significant Code Enhancement to MySQL(TM)
For an example of a real-world application that has suffered from MySQL's deficiencies, take a look at Bugzilla. It seemed great at first, but then it started to bog down badly last fall on a few tens of thousands of bug reports.
Tim
cc:Mail is an interesting case. It did suck, both on the server and for the user, but for a few years it ruled the roost even though there was superior free software. One downside of commercial software is that it suffers (or benefits) from network effects that cause time-to-market considerations to dominate over quality considerations. But note that although it took awhile, the market did select cc:Mail out of the gene pool.
My statements were about general trends. I certainly did not mean to imply that in every single case, commercial software beat free software. I could come up with my own examples to the contrary; Lutris Enhydra is better than most commercial application servers, for example. However, I think it would be sticking one's head in the sand to ignore the fact that generally speaking, commercial software is superior to its free counterparts in terms of:
Tim
"Free" software is usually more expensive than commercial software. The reason is easy to understand. The commercial software development model applies financial resources to address problems on the developer side, offloading problems from the user onto the developer. By spending money and time on the development side, both are reduced on the user side. The user is assumed to be primarily interested in the results of using software, rather than in the software itself.
Both the free software and open source models invert this, offloading costs from the developer to the user. The user is assumed to be a software hacker with plenty of free time to spend tinkering, and a desire to spend time that way. In other words, the user is assumed to be a software hobbyist. In the under 1% of cases in which this assumption about the hobbyist user is true, then free or open source software conveys value, but in the other 99%+, commercial software is superior.
Tim
Try 7%, and falling 1% every two months.
Mozilla share is well under 1%.
Tim
Free software is generally inferior to commercial software is performance. Performance tuning tools on Linux are very weak; they're rarely even used. Commercial software vendors don't have this luxury, since performance is an important factor in the market.
I don't want to get into another TCO analysis, but look at the cost of using GCC versus the cost of using CodeWarrior, CodeWarrior compiles several times as fast as GCC, but it costs a few hundred dollars. Having a programmer sitting on his or her flabby white ass waiting for the compiler is enormously expensive, so this is one of those places where performance is directly convertible into productivity numbers. The commercial software turns out to be tens of thousands of dollars less expensive per programmer per year. Ditto the glacial GIMP versus the reasonably tuned Photoshop.
And this is only one of the deltas. Add in the cost of missing features like support for printing (CMYK) and color calibration (an incredibly expensive thing to do by hand, due to wasted person-hours and print proof costs), as well as the inherent productivity loss in an inferior UI, and you wind up with a major economic equation in favor of Photoshop over GIMP.
Free software is more expensive than commercial software. Time is money.
Tim
Yes, this is another point that's often missed by the free software yahoos. Free software isn't free when it inflates total cost of ownership. Bad user interface has a direct downward effect on productivity that makes bad free software far more expensive than good commercial software. Almost all free software is noticeably inferior to its commercial counterparts.
It's easy to compute this sort of thing given a few simple assumptions. The GIMP's user interface is significantly inferior to that of Photoshop, as many people here have noted. Let's say that this means a 25% productivity loss, that the average heavy graphics user uses their main graphic tool 16 hours a week, and that the time of a graphics professional is about $40 an hour compensation and $20 overhead.
That means that on a week by week basis, using the GIMP costs $240 in lost productivity. That means it will take less than three weeks for Photoshop to pay for itself at $600. Over the course of a working year, your "free" solution has cost you $11,400.
Don't like the numbers? Tweak them all you like, but a reasonable lower bound for the basic productivity loss is 10% (while a more realistic figure is above 50% -- most free SW UI is really bad). Any reasonable numbers plugged into the formula still leave thousands of dollars in lost productivity per year from using the inferior free tool.
Tim
No kidding. It's amazing that people still don't get it. It's 2001 for frick's sake.
Listen up, people. The command line has been obsolete for seventeen years now. You are out of touch with modern understanding. Your clinging to absurd and discredited design approaches is tantamount to creationism. If you want to continue to marginalize yourselves and make yourselves irrelevant to computing for the people, you're free to do that, but don't be surprised that your subculture is spiraling down the toilet bowl and that everyone else in the world is using this century's paradigm.
And if you want access to low-level Mac system features, there's a way to do that. It's called an API. It's what real software engineers use. Command lines are for tinkerers, not for engineers.
Get a clue!
Tim
Obviously, and it's pretty discouraging to see so little discussion of that major factor in this thread. Linux software has never caught up to what Macintosh people got used to in 1984 and Windows people got used to in 1995. The internal discourse within the Linux community is appallingly clueless when it comes to all the advances that have happened in the field over the last two decades. This is a culture that can't produce software that pleases today's mass-market computer users, and not because something is wrong with the users -- it's because the users' critical standards have evolved and Linux programmers hold those standards in contempt.
Is it possible that the vast majority of people developing Linux are programmers, and very few are writers, artists, designers (user interface people)? Since it's built by programmers, it suits them just fine, but others struggle with Linux because little emphasis is placed on usability. Programmers are accountable only to other programmers.
The normal case in discussing users within the open source discourse community is to be insulting to anyone who is not a programmer. Unfortunately that shuts out 99+% of the market.
User interface people are accustomed to getting paid for their work, and seem unlikely (to me) to work on the UI and documentation for Linux for free.
Yes, professional quality user interface design work is both resource-intensive (read: expensive) and rare in terms of the amount of talent and skill available in the professional community. If you have the expertise, it's a seller's market for you. For years now this shortage has allowed compensation for talented user interface people to compare favorably with the contracting fees of senior software engineers. No one could develop an entire modern widget set or modern application with adequate user testing, iterative design, and field observation under open source conditions. Airplane tickets, mirror labs, and designer person-months don't just grow on trees. Eazel is reported to have spent $15 million to produce a file browser.
Perhaps one of the larger companies, Redhat for example, could hire some usability people that could contribute. For example, when the Macintosh was created, there was a significant amount of time/money spent on design and usability. Will that ever happen for Linux?
Only if open source becomes desirable for investors again, and that seems unlikely to happen. The original rationales behind the open source movement never made good economic sense. Having had the opportunity to spend investor capital, open source companies have mostly squandered it. Getting funding for one now would be next to impossible.
Tim
A command line is doing it right? Welcome to 1983!
Tim
Maybe I'm missing something, but I don't see how those goals are in conflict. I'm not saying get rid of pointers; I'm just saying there's no reason to have separate operators for a field of a pointer, a field of a reference, and a field of a pointer to a pointer. The dot operator could easily do all of those.
Tim
Tim
In practice, though, this value requires significant additional expenditure to realize. An open source project requires intense commitment to get involved with technically, if it's of a large size and if the changes you want to make are anything but trivial and cosmetic.
I've looked at getting involved in various large open source projects which interest me -- Mozilla, the Linux kernel, Eazel, gcc, etc. -- and in every case I found that it was by no means possible to go in, make a quick change, and get out. In every case, I found that I would have to adopt those projects as my lifestyle for at least two months, and sometimes more, before I was reasonably functional in the code bases. It's less like "changing a program" and more like "joining a religion." It's harder to get started in open source projects than commercial ones because the documentation is terrible and the coding styles are a Frankenstein patchwork.
A two-month startup time for a software architect means a five-figure investment just to get started on an open source project, before actually adding anything significant. That's not the simplest value proposition in the world. In fact, it's a value that you can guarantee most customers will never have the resources to realize, which is to say, the median value is zero.
Now, looking more broadly at the value proposition, note that there are significant negative values in most open source software compared to commercial counterparts:
And it appears that for the median customer, the value proposition is significantly negative.
Tim
QuickTime performance remains problematic on the G3. I was unable to play even a single copy of the large (588x440) version of the Ruby iMac television advertisement at the full framerate on the G3/400, even on a totally idle system. This movie plays just fine in Mac OS 9 on the same machine. The dual G4/450 does much better, happily playing two copies of this movie simultaneously at full speed on a lightly loaded system. Obviously, the G4's AltiVec unit helps QuickTime playback a great deal, but I'm still puzzled by the poor G3 performance, especially the disparity between playback in OS X versus Mac OS 9. This has been a problem throughout Mac OS X's development, and it's a shame to see that it's made it into the 10.0 release. Is Apple simply giving up on the G3 in favor of G4 optimizations?
In other words, it can't play DVDs yet because it's not fast enough.
I hope this is helpful information for people who didn't see how it could be possible for real-time high-bandwidth operations to play slower on a system with advanced multitasking. Primitive multitasking can get in the way less.
Tim
Actually, it is just that. Please see http://news.cnet.com/news/0-1006-200-5423455.html? tag=mn_hd. Roxio cannot port Toast at the current level of the system.
Tim
"We've 'carbonized' Toast as much as we can," said Victor Nemechek, product manager for Toast, the popular CD burning software from Roxio. "You can get your CDs all ready to burn, but the final step--you can't do that." Carbonizing refers to taking existing code and moving it over to Mac OS X.
Apple shipped Mac OS X without full support for CD-rewritable, DVD and DVD-recordable drives. Besides its own troubles, developers say, Apple also failed to deliver adequate tools for third-party software programs.
"The I/O kit that Apple shipped in the release version of OS X is not quite complete," Nemechek said, referring to a computer's input/output system. This means companies developing software for CD-RW, DVD and tape drives are at a standstill in their development efforts, he added.
Apple is expected to add CD-RW functionality to Mac OS X later this month, but Nemechek said that would likely not immediately solve the problem for Roxio or other developers working with I/O-dependent hardware.
"There are some exciting things about OS X, but problems like this just validate my belief that there is no compelling reason for most people to go out and get OS X right now," Deal said.
Apple declined to comment on the I/O kit.
I consider these comments a validation of my original observation that the DVD and CD-RW features did not simply slip, but were due to deeper architectural problems in Mac OS X, which could not be outsourced due to their close coupling with the system.
Tim
Tim
Thanks,
Tim
Again, I'm getting the feeling that there is an emotional reaction here to the idea that UNIX scheduling could ever be less than perfect. If it's a religious issue, I'm not interested in pursuing it on that basis.
Tim
People have been churning out CD writer apps for many years and there's no apparent reason that one couldn't have been contracted out here as well, unless there's some reason the work has to be tightly coupled to the main system.
I'm not insinuating anything, and your response seems rather defensive. I'm saying it doesn't make sense to me -- as a former Apple technical lead -- that these particular critical features should have slipped. I have speculated on one possible reason, but I'm by no means committed to that possibility as the one and only truth. If all you can see is an insult to a beloved kernel, that's your interpretation, not mine.
Porting cdrecord would be a good test of the possibility that problems in Mac OS X scheduling are involved in the slip.
Tim
For instance, if the scheduling heuristics were incapable of avoiding the occasional long pause -- which would not be surprising on a non-real-time time-sliced OS -- that would blow away both of those features, which depend on the rock-steady delivery of large amounts of data over extended periods of time. You could do this on Mac OS because there wasn't really a scheduler to get in the way. Adding a real kernel makes it a harder problem to solve.
Tim
Tim
You might consider reading the article before you respond to it:
The third kind is creative software. It is dreamed up by people who fancy themselves artists, to push the boundaries of the human experience. "Let's say you wanted to create software so that kids can make music by wiggling their nose," Lanier says. The program may be buggy as a July barbecue. But if it is sufficiently intriguing, people will put up with defects because the new experience is thrilling.... "There'd be different legal categories of software. If you want to rush it to market, and have first-mover advantage and see what happens, fine. You could label it creative software. But much of your code will be open to the public."
Tim
It's a pretty compelling argument, and it may help explain why people don't reject badly designed technology. As a designer I constantly run into people who insist that any problem they experience is their own fault and who get that deer-in-the-headlights look if you explain that the system could have been designed so that the error didn't happen.
Tim