I think the problem here is that Macintoshes do not have sound cards... at all... it all goes through the CPU. Kind of a dumb idea, I admit.
Lack of a dedicated sound card is apparently not the problem, since the same Macs running a different mp3 player on a different OS handle it just fine.
Sorry, iTunes is not compelling or any kind of best product to hit anything. There are basically three features that really matter for mp3 players:
Quality of playback
Quality of UI
Speed
I'm ignoring features like iPod integration because that's really a seperate tool that Apple decided to put in the same application as their mp3 player. I'm also ignoring visualization because I think most people don't need it.
Quality of playback was made irrelevant after the first couple years of mp3 technology - everything is at the same level of quality now: "good enough"
Now, the last critical feature was made rather irrelevant too, through the last few years as computers got stupid fast. I'm talking about playing mp3s using 5% CPU time or less on even a ~300MHz system. Apple has managed to resurrect this hobgoblin with iTunes (on OSX) by making their mp3 player use a significant chunk of CPU time on any reasonably powered Mac - even when not playing mp3-encoded audio! (I'm not talking about dual CPU machines here - that really ought to be rediculous overkill to play mp3s and use a web browser at the same time)
iTunes GUI really gets me. It blows. I like to have a little control/display window and a little playlist (4 songs with name/artist/album/time) in the corner of my screen at all times. That's a playlist - not a playlist browser, or a list of online radio stations, or some other crap that doesn't apply to my current task. iTunes makes this impossible. Apple decided to kill the skinability of SoundJam, which was sacrificed to make iTunes, in favor of a consistent aqua user experience - which would be great, except it's bloated and useless.
Does anyone know if these benchmarks test memory throughput at all? I have no idea what the Photoshop "MP" action file test is, or why it's there twice, so I'm mainly curious about that. I can't imagine that MP3 encoding or rendering in Bryce aren't completely CPU-bound.
Rarity has nothing to do with value. Indeed, diamonds are only about as rare as quartz. The reason why diamonds are so expensive is because DeBeers has a monopoly over them.
I've heard this argument before, and I'm just not convinced. DeBeers may (does) have a monopoly on the retail sale of diamonds in most of the world. It seems to me if they are able to have a monopoly on the natural supply of diamonds from the Earth, that implies diamonds must be pretty rare.
Suppose you wanted, for some reason, to have a monopoly on the natural supply of quartz. What percentage of the land surface of the Earth would you have to own / control? 10%? 5%? 1%? We know quartz is not rare, and - correct me if I'm wrong about the diamonds - is available in much larger unbroken pieces than diamonds are with great frequency. DeBeers is a huge empire, but I seriously doubt they control even close to 1% of the land surface of the planet. If diamonds are truly not rare, I should be able to find diamonds own my own, given the proper tools, on the other 99% of the planet.
Onto the XML question, and getting to my area of pet hate: The XML Silver Bullet.com. The author's bias towards XML is understandable, but he needs to realise, as do the millions of developers who let the marketting machine think for them, that XML is a poor implementation of a decent idea.
Of course XML is a silver bullet! JARs and properties files are just the beginning. What we really need is for the.class files to be nice, readable, XML documents. This will pave the way for.java code to be written in a proper XML format. There is no reason that these things need to be written in an ugly properiety format.
The only way this will work is if it is compatable with older versions. Would anyone upgrade to Borland Builder 6 if they were told they couldn't compile there previous programs.
You are completely misunderstanding the point of the article. Your comment is not insightful (nor is it informative).
The author is calling for a new language. This new language is a lot like Java - so much so, in fact, that it should be called Java. But it would be incompatible with Java as we know it for reasons he describes and justifies in the article. This has 3 implications, none of which are relevant to the need for "Java3" to be compatible with traditional Java:
New Java compilers need to support compiling Java as well as Java3.
New Java VMs need to support running Java as well as Java3 bytecode.
Development on oldstyle Java VMs, compilers, and eventually programs, should eventually stop in favor of Java3.
This is not true in practice. The Hybrid Civic's electric motor generates 13.4 horsepower @ 4000 RPM. The 1.3 L VTEC engine generates 85 @ 5700 RPM. If you were getting maximum output from both sources at once, you'd have 98 hp. This is significantly less of the 117 output by the gasoline-only Civic (with a 1.7 L VTEC-e) in my comparison. Honda doesn't even claim 98 hp, however, rather they claim 93 net hp. Perhaps the horsepower doesn't add linearly, or there's other loss.
In any case, you're wrong - this vehicle does not come close to exceeding the power of the predecessor (although non-Hybrid Civics don't seem to be going anywhere).
This is cool and all, but consider the 2003 Civic Hybrid against my car, the 2002 Civic HX:
The Hybrid gets a few more features (ABS, cd player, power windows) and a whopping 13/7 more MPG of fuel efficiency.
My car gets most of the same features (including automatic (CVT) trans and AC), 20-25 more HP, for about $5000 less.
Losing 25 horsepower while gaining about 150 lbs, on a car that wasn't particularly muscular to start out with, with the price difference in the wrong direction, isn't especially "viable". At current gas prices, $5000 = 650000 miles before you break even going with the hybrid. No.
It is true that closed-source projects can make one sort of deadline and stick to it. That's the "we'll ship by" sort of deadline. That's not the kind of deadline that knowledgeable users generally need.
The sort of deadline that open-source projects can generally meet is the "we'll get a nightly build up every night" and the "we won't call it version 1.0 until we're ready" sorts. These will do just fine for knowledgeable users. No closed-source company can meet this kind of commitment.
Indeed, but there are very serious problems with development processes that set these kinds of deadlines.
Clearly, the "we'll ship by" deadline can lead to shipping products that were not ready to ship. But if project managers and developers are intelligent about it, it can also lead to debugging and other project finalizations being done when they need to be done.
"We'll get a nightly build up every night" can become a completely worthless type of deadline very quickly. Nightly builds are worthless and should not count as any kind of achievement most of the time. No user needs a new release every night, especially at the cost of uncertainty of quality. Post builds when it's useful to users to do so. Developers shouldn't need a build posted every night to continue the development process.
The "we won't call it 1.0 until it's ready" anti-deadline is obviously a rule that everyone should follow. It's tautological. Unfortunately, I think a lot of the time, especially in open source projects, this rule gets turned into "we won't call it 1.0 until we get bored of adding new features to it; and we won't debug it after that because that isn't as interesting to do." Worse yet, it turns in to "we won't bother releasing a version we'll call 1.0 any time soon because stableizing the project to an acceptable level isn't something anyone on the team is interested in."
Even microsoft has figured out a solution to the problem of making users wait for an official release. It's called releasing betas to the public. It's still up to the users if they feel the betas are good enough to use on a daily basis. Still, for most users, it is unacceptable to have to try out more than one release of a product to find out if it's up to their standards. A whole lot of users want that 1.0 release so they can try it will the expectation "if this release isn't good enough, the product isn't good enough, and I should go try something else."
Almost all of my mp3s come from CDs. While there exists a [currently Microsoft-owned] standard for making 20-bit encoded CDs, it's safe to assume that all my mp3s are from a 16-bit audio source. Furthermore my sound hardware only supports 16-bit output. Please explain how in the voyage from 16-bit uncompressed digital audio, to 16-bit hardware outputting to speakers, stopping at lossy mp3 in the middle, using a higher bit resolution in the decoding process could possibly make a difference in quality, and a noticable one at that. It seems to me the only thing you could possibly accomplish by doing this is achieving higher fidelty with respect to the inaccuracies introduced by mp3 encoding.
One of my friends counters arguments about software being too sloppy with the point that there is practically no other field where a product is designed to be used on such a varying degree of ways and expected to still be robust. For instance, let's use a car as an analogy to your complaints
That's okay, software more than makes up for this bit by being about the only field where you can be so certain about the environment it's used in. Cars are subject to various terrain conditions than the manufacturer never could have guessed (this could be half the user's fault), and environmental conditions which are rare and possibly very difficult to simulate during the development process (this is not). To prepare a car to theoretically resist any kind of failure you need a really good physics model and lots of really good test cases (lots = billions). Recompiling and testing 1000 times does not even begin to compare to building a car from a new design 1000 times, and testing. And I suspect 1000 tests on a piece of software would probably find/solve many more of the bugs in it.
Computer softare has all kinds of luxuries here. For one, all input to a piece of software is digital. I hope you understand how much easier this makes bounds/value checking. Software gets to come with hardware and software requirements which it gets to enforce: Oh, you aren't running at least Win98 on at least a PentiumII? I won't run then. Cars come with a manual that says "put 89 octane gas in me. Don't drive me on roads which are unpaved, save the pointy nails littered all over them. Don't drive around on antarctica cuz it's cold there." But if you defy any of these rules, you'll suceed at least part way, and then you can complain to the manufacturer, who will tell you to piss off. It would be really cool to see a car that actually tested the octane of the gas you put in it, and complains immediately if it's incorrect, but I don't see anyone writing an article that auto makers owe us this feature.
We're not talking about physical damage here. If you throw your hard drive at a lamp post, and then complain to your software vendor that the software doesn't work, you've got issues. But yes, software that corrupts your hard drive (???) because a CD is scratched is totally negligent.
It's writing for the benchmark rather than writing for the user.
Completely irrelevant. Quake 3 may be a benchmark but it's a benchmark which users use on a daily basis - because it's a game first and a benchmark second. Your argument is equivilant to stating that Seagate engineers for the benchmark instead of the user when they make hard drives with higher throughput. Seagate optimizing for Microsoft Disk Performance BusinessBenchmark 2001 would be cheating, optimizing for latency and throughput are not (nor would optimizing for opening a large file in photoshop...but I don't see that happening in a disk drive).
Where ATI did screw up is in their shoddy engineering. The developers should be ashamed of themselves. If there's a 15% (!) performance gain to be had using the same hardware between the "default" behavior of the drivers and some optimized behavior, they should really find a better way than looking at the name of the freaking program being run. Maybe that means having intelligent drivers that benchmark themselves during the first few minutes of gameplay, seeing which set of code produces the best results, and using that afterwards; but I'm skeptical of saying this couldn't be done in a more generic way.
Make all applications keep a list of types of files that they can open, as well as a unique identifier associated with things they "want" to open.
Make all files keep a type code and a seperate code associated with what application it "wants" to be opened by, a creator code if you will.
Don't pollute this information in the namespace of the filename, where it does not belong and can be changed for the wrong reasons (there are plenty of valid reasons to give a filename a suffix, none of which have anything to do with this file metadata).
Don't even allow this data to be stored in a centralized registry where it could be molested by programs automatically without a user's intent.
For both the applicaton's lists and the file's codes, the operating system can read and manipulate these codes, because it is stored in a standard, easily located, structure.
Files are automatically opened by the program that matches their "creator" code, but can be opened by anything that matches their type code.
Applications can open any files that match their type codes.
Files, which are always created by applications, are given type codes to match their content, and creator codes to match the application.
There could be 1st party solutions to map files without useful metadata by user-specified preferences to native metadata by outside standards which are weaker (MIME types, file extensions).
There could be 3rd party solutions to forcably remap files to applications other than the one which they want to be opened by, even if the wanted one is available. I'm talking about both on a per-file basis and a universal setting independent of files which may not even exist yet.
Hydrogen would not burn "all at once" because hydrogen, like other fuels, does not burn without oxygen. Furthermore, because hydrogen has much less of a tendency to spread out (it's lighter, and boyant in air) than jet fuel it will take a while before the hydrogen is all exposed to oxygen (assuming you keep it in some container with a low surface-to-volume ratio, like a fuel tank). That said, it would still probably be much more safe than a jet fuel fire, simply because of the stickiness factor.
BTW if you think hydrogen didn't play a role (along with the lining and everything else that the burning hydrogen was exposed to) in the Hindenburg fire you're out of your mind.
There's a big difference between putting a $15-$40 multi-button mouse on a desktop mac to replace the crap Apple sells you (just as I would do on an PC because the standard MS intellimouse sucks too), and doing the same on an iBook (or more importantly, TiBook) where it may be *really* inconvenient at times to have to replace the trackpad & button with a whole new periferal. The latter was CT's point.
My situation is IIS4 on NT4, although there are many boxes at my workplace running Win2k/IIS5. I cannot upgrade to win2k, as I work in a support position where a lot of my job involves reproducing and debugging client problems. Guess what they're running. At the moment I'm working on an IIS asp application (ugh, obviously not my choice). Seriously, a change of platforms is not an option.
Incidently, Windows update will do NT4, but it does not yet support IIS patches. When it does it will be a huge improvement, hopefully.
Win2k is an improvement but it's still slow as hell to run windows updates, and you still have to reboot after every e v e r y s i n g l e f u c k i n g p i e c e. Blah.
There's no question if ISPs have the responsibility to shut down worm`ed users. In my opinion, no, it's not their job.
The question is are ISPs entitled to shut down users just because they get infected? If they're being a good netizen by doing so (and they are), then yes, they should, because it benefits the community (their other customers, whom they have a responsibility to serve, mainly, but the entire internet essentially). Not because the worm uses up too much bandwidth; bandwidth is plentiful, but because proliferating the worm sucks eggs.
I'd also like to note that this is not just a matter of "users should be responsible for their own systems." In the past, I would have absolutely agreed with this: users have the responsibility to make sure computers under their control are patched and safe to the best of their ability, and if a patch is out, it's their fault if they don't have it. But in the past few weeks I've been [unfortunately] using IIS frequently. I saw the worm hit my workplace on Wednesday and it really hurt. I also saw why so many are vulnerable to it: Microsoft makes keeping a server up to date a hellish process. Specifically, I refer to the facts that install CDs are only available in old, deprecated versions; it's often difficult to tell what version you're running, let alone what patch level; the numbering scheme for updates/patches/"service packs" is illogical and version numbers are often duplicated; and most importantly, that for some retarded reason applying patches in the wrong order can un-do fixes you've already applied. Microsoft has got to share some of the blame this time; maybe not as much as the perpetrators, or maybe even the users, but they fucked up.
Flipping through pages is crap! The scrollbar (and a good interface to it) is a far superior browsing method, and it never sticks together: it is many times more granular and thus keeps place much better. Same goes for being able to resize a window. Regular expressions also provide far superior searching capacity than the "look at stuff until you find it" method. Copying and pasting is good stuff, too.
I can't dog-ear it, or use my bookmark collection.
Actually, unlike paper, digital text documents have an "infinite" capacity for any bookmark you want.
Screens hurt my eyes, paper works fine.
Get a better screen. A quality LCD or a trinitron/diamondtron CRT at >= 85Hz is be fine (although what I really want is a pair of HUD-style glasses). Also, you can read it in the dark, which I find far more pleasant. I also like being able to change the font of whatever I'm reading, instead of having a publisher pick one for me.
eBooks run out of power, books don't.
Books require light (usually electric) during non-daylight hours.
I own a book, not a license to it.
Of course you don't. You are not at all entitled to reproduce and resell copyrighted material without the author's permission.
eBook technology is clearly not there yet, but digital distribution of works which would be traditionally distributed on paper is a good thing.
I disagree. The one thing Apple didn't do going 68k->PPC was fragment their market. Sure, the first generation of PowerMacs ran old 68k software slower than the last 68k Macs, but that was more than made up for by the fact that it was relatively easy to port apps to PPC native code, and when you did, they ran much, much faster. [Incidently, Apple never introduced "faster" Quadras after the first PowerMacs - the fastest Quadra was the 840 @ 40MHz, which came out several months before the first PowerMacs. The only post-PPC 68k machines were the 630s and the PB190 @ 33MHz. Yes, the 630s were a big mistake for Apple. I blame Scully.] Even Quadras weren't dead ends at that point, other than being slow (as all new computers will eventually be); consider that the first MacOS that wouldn't run on any 68k machine was 8.5 in 1998 - 4.5 years after PPCs first debuted.
Apple was also very successful with the transition because they had a great emulator (in software! that's important), which was perfected in about a year, at which point PPC Macs were outperforming the fastest 68k macs in emulation. There were *no* incompatibilities due to the emulator.
Apple's biggest mistake was that after transitioning to PPC, they relied too heavily on their emulator. They sat around with their old OS software which did not perform as well as it could have been. 8.5 made a huge difference, but even 9.1 still has legacy 68k code sitting around in various parts.
Where Palm is in trouble is that, while Strong ARMs are fast, I don't know that they're fast enough to emulate old-series Palms. This might be important. Apple had the luxury of knowing that PPCs would eventually be fast enough to make up for any performance lost to emulation. Does Palm have this? Either way, it should be easy to avoid the mistake of relying on an emulator too heavily. However, Palm might be able to just say "okay, use a new Palm, use all new software too."
In conclusion, Palm: figure out if you need to support old software on new Palms: if you're technically capable of doing so, make an emulator; if you make an emulator make it work perfectly, but don't rely on it for too long; don't second-guess your product strategy and go backwards with old-generation products; and deliver your customers the features they care about, not the ones your competitors think are important.
Slashdot Mirror
I think the problem here is that Macintoshes do not have sound cards... at all... it all goes through the CPU. Kind of a dumb idea, I admit.
Lack of a dedicated sound card is apparently not the problem, since the same Macs running a different mp3 player on a different OS handle it just fine.
Sorry, iTunes is not compelling or any kind of best product to hit anything. There are basically three features that really matter for mp3 players:
I'm ignoring features like iPod integration because that's really a seperate tool that Apple decided to put in the same application as their mp3 player. I'm also ignoring visualization because I think most people don't need it.
Quality of playback was made irrelevant after the first couple years of mp3 technology - everything is at the same level of quality now: "good enough"
Now, the last critical feature was made rather irrelevant too, through the last few years as computers got stupid fast. I'm talking about playing mp3s using 5% CPU time or less on even a ~300MHz system. Apple has managed to resurrect this hobgoblin with iTunes (on OSX) by making their mp3 player use a significant chunk of CPU time on any reasonably powered Mac - even when not playing mp3-encoded audio! (I'm not talking about dual CPU machines here - that really ought to be rediculous overkill to play mp3s and use a web browser at the same time)
iTunes GUI really gets me. It blows. I like to have a little control/display window and a little playlist (4 songs with name/artist/album/time) in the corner of my screen at all times. That's a playlist - not a playlist browser, or a list of online radio stations, or some other crap that doesn't apply to my current task. iTunes makes this impossible. Apple decided to kill the skinability of SoundJam, which was sacrificed to make iTunes, in favor of a consistent aqua user experience - which would be great, except it's bloated and useless.
Does anyone know if these benchmarks test memory throughput at all? I have no idea what the Photoshop "MP" action file test is, or why it's there twice, so I'm mainly curious about that. I can't imagine that MP3 encoding or rendering in Bryce aren't completely CPU-bound.
Rarity has nothing to do with value. Indeed, diamonds are only about as rare as quartz. The reason why diamonds are so expensive is because DeBeers has a monopoly over them.
I've heard this argument before, and I'm just not convinced. DeBeers may (does) have a monopoly on the retail sale of diamonds in most of the world. It seems to me if they are able to have a monopoly on the natural supply of diamonds from the Earth, that implies diamonds must be pretty rare.
Suppose you wanted, for some reason, to have a monopoly on the natural supply of quartz. What percentage of the land surface of the Earth would you have to own / control? 10%? 5%? 1%? We know quartz is not rare, and - correct me if I'm wrong about the diamonds - is available in much larger unbroken pieces than diamonds are with great frequency. DeBeers is a huge empire, but I seriously doubt they control even close to 1% of the land surface of the planet. If diamonds are truly not rare, I should be able to find diamonds own my own, given the proper tools, on the other 99% of the planet.
Onto the XML question, and getting to my area of pet hate: The XML Silver Bullet.com. The author's bias towards XML is understandable, but he needs to realise, as do the millions of developers who let the marketting machine think for them, that XML is a poor implementation of a decent idea.
Of course XML is a silver bullet! JARs and properties files are just the beginning. What we really need is for the .class files to be nice, readable, XML documents. This will pave the way for .java code to be written in a proper XML format. There is no reason that these things need to be written in an ugly properiety format.
My apologizes if my sarcasm is lost.
The only way this will work is if it is compatable with older versions. Would anyone upgrade to Borland Builder 6 if they were told they couldn't compile there previous programs.
You are completely misunderstanding the point of the article. Your comment is not insightful (nor is it informative).
The author is calling for a new language. This new language is a lot like Java - so much so, in fact, that it should be called Java. But it would be incompatible with Java as we know it for reasons he describes and justifies in the article. This has 3 implications, none of which are relevant to the need for "Java3" to be compatible with traditional Java:
Grudgingly, I upgraded to 6.0.8 (ugh, I just hate the inefficiency of MultiFinder!)
Feel free to turn it off, then. Or bet yet, use MiniFinder. It's not like you had to go to something only 11 years old like System 7.0.
Don't forget the hybrid has a CVT too, which allows peak torque or horsepower to be applied over a much wider range of road speeds.
As I said, the Civic HX has a CVT as well. No advantage here. The hybrid continues to fall short of the performance of the HX.
This is not true in practice. The Hybrid Civic's electric motor generates 13.4 horsepower @ 4000 RPM. The 1.3 L VTEC engine generates 85 @ 5700 RPM. If you were getting maximum output from both sources at once, you'd have 98 hp. This is significantly less of the 117 output by the gasoline-only Civic (with a 1.7 L VTEC-e) in my comparison. Honda doesn't even claim 98 hp, however, rather they claim 93 net hp. Perhaps the horsepower doesn't add linearly, or there's other loss.
In any case, you're wrong - this vehicle does not come close to exceeding the power of the predecessor (although non-Hybrid Civics don't seem to be going anywhere).
This is cool and all, but consider the 2003 Civic Hybrid against my car, the 2002 Civic HX:
The Hybrid gets a few more features (ABS, cd player, power windows) and a whopping 13/7 more MPG of fuel efficiency.
My car gets most of the same features (including automatic (CVT) trans and AC), 20-25 more HP, for about $5000 less.
Losing 25 horsepower while gaining about 150 lbs, on a car that wasn't particularly muscular to start out with, with the price difference in the wrong direction, isn't especially "viable". At current gas prices, $5000 = 650000 miles before you break even going with the hybrid. No.
It is true that closed-source projects can make one sort of deadline and stick to it. That's the "we'll ship by" sort of deadline. That's not the kind of deadline that knowledgeable users generally need.
The sort of deadline that open-source projects can generally meet is the "we'll get a nightly build up every night" and the "we won't call it version 1.0 until we're ready" sorts. These will do just fine for knowledgeable users. No closed-source company can meet this kind of commitment.
Indeed, but there are very serious problems with development processes that set these kinds of deadlines.
Clearly, the "we'll ship by" deadline can lead to shipping products that were not ready to ship. But if project managers and developers are intelligent about it, it can also lead to debugging and other project finalizations being done when they need to be done.
"We'll get a nightly build up every night" can become a completely worthless type of deadline very quickly. Nightly builds are worthless and should not count as any kind of achievement most of the time. No user needs a new release every night, especially at the cost of uncertainty of quality. Post builds when it's useful to users to do so. Developers shouldn't need a build posted every night to continue the development process.
The "we won't call it 1.0 until it's ready" anti-deadline is obviously a rule that everyone should follow. It's tautological. Unfortunately, I think a lot of the time, especially in open source projects, this rule gets turned into "we won't call it 1.0 until we get bored of adding new features to it; and we won't debug it after that because that isn't as interesting to do." Worse yet, it turns in to "we won't bother releasing a version we'll call 1.0 any time soon because stableizing the project to an acceptable level isn't something anyone on the team is interested in."
Even microsoft has figured out a solution to the problem of making users wait for an official release. It's called releasing betas to the public. It's still up to the users if they feel the betas are good enough to use on a daily basis. Still, for most users, it is unacceptable to have to try out more than one release of a product to find out if it's up to their standards. A whole lot of users want that 1.0 release so they can try it will the expectation "if this release isn't good enough, the product isn't good enough, and I should go try something else."
Almost all of my mp3s come from CDs. While there exists a [currently Microsoft-owned] standard for making 20-bit encoded CDs, it's safe to assume that all my mp3s are from a 16-bit audio source. Furthermore my sound hardware only supports 16-bit output. Please explain how in the voyage from 16-bit uncompressed digital audio, to 16-bit hardware outputting to speakers, stopping at lossy mp3 in the middle, using a higher bit resolution in the decoding process could possibly make a difference in quality, and a noticable one at that. It seems to me the only thing you could possibly accomplish by doing this is achieving higher fidelty with respect to the inaccuracies introduced by mp3 encoding.
One of my friends counters arguments about software being too sloppy with the point that there is practically no other field where a product is designed to be used on such a varying degree of ways and expected to still be robust. For instance, let's use a car as an analogy to your complaints
That's okay, software more than makes up for this bit by being about the only field where you can be so certain about the environment it's used in. Cars are subject to various terrain conditions than the manufacturer never could have guessed (this could be half the user's fault), and environmental conditions which are rare and possibly very difficult to simulate during the development process (this is not). To prepare a car to theoretically resist any kind of failure you need a really good physics model and lots of really good test cases (lots = billions). Recompiling and testing 1000 times does not even begin to compare to building a car from a new design 1000 times, and testing. And I suspect 1000 tests on a piece of software would probably find/solve many more of the bugs in it.
Computer softare has all kinds of luxuries here. For one, all input to a piece of software is digital. I hope you understand how much easier this makes bounds/value checking. Software gets to come with hardware and software requirements which it gets to enforce: Oh, you aren't running at least Win98 on at least a PentiumII? I won't run then. Cars come with a manual that says "put 89 octane gas in me. Don't drive me on roads which are unpaved, save the pointy nails littered all over them. Don't drive around on antarctica cuz it's cold there." But if you defy any of these rules, you'll suceed at least part way, and then you can complain to the manufacturer, who will tell you to piss off. It would be really cool to see a car that actually tested the octane of the gas you put in it, and complains immediately if it's incorrect, but I don't see anyone writing an article that auto makers owe us this feature.
We're not talking about physical damage here. If you throw your hard drive at a lamp post, and then complain to your software vendor that the software doesn't work, you've got issues. But yes, software that corrupts your hard drive (???) because a CD is scratched is totally negligent.
It's writing for the benchmark rather than writing for the user.
Completely irrelevant. Quake 3 may be a benchmark but it's a benchmark which users use on a daily basis - because it's a game first and a benchmark second. Your argument is equivilant to stating that Seagate engineers for the benchmark instead of the user when they make hard drives with higher throughput. Seagate optimizing for Microsoft Disk Performance BusinessBenchmark 2001 would be cheating, optimizing for latency and throughput are not (nor would optimizing for opening a large file in photoshop...but I don't see that happening in a disk drive).
Where ATI did screw up is in their shoddy engineering. The developers should be ashamed of themselves. If there's a 15% (!) performance gain to be had using the same hardware between the "default" behavior of the drivers and some optimized behavior, they should really find a better way than looking at the name of the freaking program being run. Maybe that means having intelligent drivers that benchmark themselves during the first few minutes of gameplay, seeing which set of code produces the best results, and using that afterwards; but I'm skeptical of saying this couldn't be done in a more generic way.
When did you first hear of the classic usenet group, alt.ensign.wesley.crusher.die.die.die, and what was your reaction?
Really? That's interesting. I didn't know.
For those that didn't catch it the first time, I was describing the MacOS model.
Hydrogen would not burn "all at once" because hydrogen, like other fuels, does not burn without oxygen. Furthermore, because hydrogen has much less of a tendency to spread out (it's lighter, and boyant in air) than jet fuel it will take a while before the hydrogen is all exposed to oxygen (assuming you keep it in some container with a low surface-to-volume ratio, like a fuel tank). That said, it would still probably be much more safe than a jet fuel fire, simply because of the stickiness factor.
BTW if you think hydrogen didn't play a role (along with the lining and everything else that the burning hydrogen was exposed to) in the Hindenburg fire you're out of your mind.
There's a big difference between putting a $15-$40 multi-button mouse on a desktop mac to replace the crap Apple sells you (just as I would do on an PC because the standard MS intellimouse sucks too), and doing the same on an iBook (or more importantly, TiBook) where it may be *really* inconvenient at times to have to replace the trackpad & button with a whole new periferal. The latter was CT's point.
My situation is IIS4 on NT4, although there are many boxes at my workplace running Win2k/IIS5. I cannot upgrade to win2k, as I work in a support position where a lot of my job involves reproducing and debugging client problems. Guess what they're running. At the moment I'm working on an IIS asp application (ugh, obviously not my choice). Seriously, a change of platforms is not an option.
Incidently, Windows update will do NT4, but it does not yet support IIS patches. When it does it will be a huge improvement, hopefully.
Win2k is an improvement but it's still slow as hell to run windows updates, and you still have to reboot after every e v e r y s i n g l e f u c k i n g p i e c e. Blah.
There's no question if ISPs have the responsibility to shut down worm`ed users. In my opinion, no, it's not their job.
The question is are ISPs entitled to shut down users just because they get infected? If they're being a good netizen by doing so (and they are), then yes, they should, because it benefits the community (their other customers, whom they have a responsibility to serve, mainly, but the entire internet essentially). Not because the worm uses up too much bandwidth; bandwidth is plentiful, but because proliferating the worm sucks eggs.
I'd also like to note that this is not just a matter of "users should be responsible for their own systems." In the past, I would have absolutely agreed with this: users have the responsibility to make sure computers under their control are patched and safe to the best of their ability, and if a patch is out, it's their fault if they don't have it. But in the past few weeks I've been [unfortunately] using IIS frequently. I saw the worm hit my workplace on Wednesday and it really hurt. I also saw why so many are vulnerable to it: Microsoft makes keeping a server up to date a hellish process. Specifically, I refer to the facts that install CDs are only available in old, deprecated versions; it's often difficult to tell what version you're running, let alone what patch level; the numbering scheme for updates/patches/"service packs" is illogical and version numbers are often duplicated; and most importantly, that for some retarded reason applying patches in the wrong order can un-do fixes you've already applied. Microsoft has got to share some of the blame this time; maybe not as much as the perpetrators, or maybe even the users, but they fucked up.
I can't flip through it.
Flipping through pages is crap! The scrollbar (and a good interface to it) is a far superior browsing method, and it never sticks together: it is many times more granular and thus keeps place much better. Same goes for being able to resize a window. Regular expressions also provide far superior searching capacity than the "look at stuff until you find it" method. Copying and pasting is good stuff, too.
I can't dog-ear it, or use my bookmark collection.
Actually, unlike paper, digital text documents have an "infinite" capacity for any bookmark you want.
Screens hurt my eyes, paper works fine.
Get a better screen. A quality LCD or a trinitron/diamondtron CRT at >= 85Hz is be fine (although what I really want is a pair of HUD-style glasses). Also, you can read it in the dark, which I find far more pleasant. I also like being able to change the font of whatever I'm reading, instead of having a publisher pick one for me.
eBooks run out of power, books don't.
Books require light (usually electric) during non-daylight hours.
I own a book, not a license to it.
Of course you don't. You are not at all entitled to reproduce and resell copyrighted material without the author's permission.
eBook technology is clearly not there yet, but digital distribution of works which would be traditionally distributed on paper is a good thing.
500,000 Natalie Portmans, all naked and petrified?
I disagree. The one thing Apple didn't do going 68k->PPC was fragment their market. Sure, the first generation of PowerMacs ran old 68k software slower than the last 68k Macs, but that was more than made up for by the fact that it was relatively easy to port apps to PPC native code, and when you did, they ran much, much faster. [Incidently, Apple never introduced "faster" Quadras after the first PowerMacs - the fastest Quadra was the 840 @ 40MHz, which came out several months before the first PowerMacs. The only post-PPC 68k machines were the 630s and the PB190 @ 33MHz. Yes, the 630s were a big mistake for Apple. I blame Scully.] Even Quadras weren't dead ends at that point, other than being slow (as all new computers will eventually be); consider that the first MacOS that wouldn't run on any 68k machine was 8.5 in 1998 - 4.5 years after PPCs first debuted.
Apple was also very successful with the transition because they had a great emulator (in software! that's important), which was perfected in about a year, at which point PPC Macs were outperforming the fastest 68k macs in emulation. There were *no* incompatibilities due to the emulator.
Apple's biggest mistake was that after transitioning to PPC, they relied too heavily on their emulator. They sat around with their old OS software which did not perform as well as it could have been. 8.5 made a huge difference, but even 9.1 still has legacy 68k code sitting around in various parts.
Where Palm is in trouble is that, while Strong ARMs are fast, I don't know that they're fast enough to emulate old-series Palms. This might be important. Apple had the luxury of knowing that PPCs would eventually be fast enough to make up for any performance lost to emulation. Does Palm have this? Either way, it should be easy to avoid the mistake of relying on an emulator too heavily. However, Palm might be able to just say "okay, use a new Palm, use all new software too."
In conclusion, Palm: figure out if you need to support old software on new Palms: if you're technically capable of doing so, make an emulator; if you make an emulator make it work perfectly, but don't rely on it for too long; don't second-guess your product strategy and go backwards with old-generation products; and deliver your customers the features they care about, not the ones your competitors think are important.