I'm a big fan of Tolkien's works; I've even read and enjoyed large portions of the History of Middle Earth volumes, including his fascinating Lost Tales, early drafts of stories that later became parts of the Silmarillion, and some of the long poems. But I have found that some of them, such as The Silmarillion itself, and now The Children of Hurin, really benefit a lot from an audio presentation rather than just reading. I tried to get into The Silmarillion several times, but the text never really engaged me; my eyes would start to just slide down the page without absorbing anything. That is, until I listened to Martin Shaw's unabridged reading. It really comes to life; it is no longer like reading the phone book in Elvish. The same thing applies to The Children of Hurin. There is a great unabridged reading by Christopher Lee.
These readings don't make good background sound while working; they need your concentration. I'm a notorious multi-tasker and sometimes I think I've lost the ability to focus on one thing at a time, unless it is code. But they would be great for a long commute or to listen to on your iPod at the gym.
Well, I'm a 185-pound elite cyclist. But I'm cleverly disguised as an overweight middle-aged software engineer! Unless you are actually seven feet tall or more, your BMI says you're just fat. Are you sure you didn't misspell "obese couch potato who tries to convince himself that he's a jock because he goes to the gym once a week?"
The _point_ is, I think, that the laptop is now so light, and requires so few accessories, that it is a no-brainer for a business traveler to decide whether to take it along or not. He or she will just do it automatically. Because that businessperson is more likely to have the computer available to type up a note or answer a message at any given point during a work day, it just became considerably more valuable.
It doesn't hurt that it looks pretty damned sexy as well. Unfortunately Apple's sexiest toys start to look scratched-up and fugly after only a year or two, but that seems intentional so they can sell you the next expensive pretty thing.
I would bet that this is not a real use case in the demographic they've studied. In other words, people who really do strip down the weight of what they are carrying don't actually swap out the battery. Doing so requires you to carry an extra battery, and it is additionally painful to carry a second battery if you don't actually carry an external charger as well, since you have to swap batteries in your laptop while it is plugged in (perhaps in the middle of the night while you're asleep in your hotel room) to charge the second battery. So people don't do it. Instead, most people use it for a few hours on the battery, and plug it in back in as soon as they can. Personally, I've used quite a few different laptops over the last 15 years or so and carrying backup batteries rarely seemed worth the effort. If the MBA battery actually gives you five hours of real use, I think that will be remarkably effective for most users. That's well over a work day of on-and-off use typing, editing, whatever which tends to be a very on-and-off activity for a laptop.
I'd agree that the Air doesn't meet all use cases, but the more I consider what they left out, the more I think that they actually got the product very nicely targeted at the product's target demographic. If it seems like it would not match the way you use a laptop, perhaps that's a good indication that you aren't in the target demographic?
I'm sorry, but I just don't understand. You think it is _intuitive_ that if you drag an object (a folder) into a window representing a folder, and it has the same name as a folder that already exists, the two should be magically _merged_?
OK, now you've got an instant version control problem. Was the destination folder (the one you merged into) the canonical one? Was the source folder the canonical one?
With merging, you didn't lose anything, but now you have two folders, the original and the merged, that don't match. How does that help anyone keep their files organized?
Replacing isn't the default behavior -- that's why it asks you if you really want to do it.
You wrote "from the user's perspective you aren't really moving the directory, the intent is to move the files." Why do you think that? You've got to understand that most people -- including most computer users -- don't actually understand hierarchies, and never will. The icon == the directory. And that is what they are moving. Just as a physical file folder (the original metaphor, originally somewhat strained) is not the papers inside.
I guess you young-uns are too young to remember the days when cell phone clocks were about as accurate as PC clocks and you had to set them yourself when the battery went dead.
>Turns out these guys weren't reading the reply. How do I know? Well I followed the same 'booby trap' method. In a couple of e-mails >I inserted the words "if you read this sentence, e-mail be back and I'll buy you a case of beer"...
It was probably their spam filters...
Several times I've recently had situations where a friend has written me increasingly agitated followup e-mail messages: "did you ever write me back?" and "Why haven't you written me back?" only to find that my detailed replies had gotten stuck in his spam filtering...
Ditto this. I've done development of MacOS X kernel extensions for PCI hardware. It is very rare to see a crash that wasn't the fault of my own kext. We did, though, have boxes arrive with bad RAM that caused kernel crashes. These inevitably turned out to be due to bad DIMMs installed by MacConnection or MacMall or whoever offered a free memory upgrade with purchase. I know Apple charges faintly ridiculous amounts for their memory so I can completely understand going with another vendor for RAM, but I'd encourage people to go with Crucial RAM and not unknown RAM from one of the big resellers.
You are correct, sir or madam... I mis-remembered the drive situation. It makes complete sense that I would have removed the somewhat useless floppy drive and put in the spacer.
It depends on what you mean by "fire." My name (my real name) is Paul R. Potts, and I hereby certify, affirm, swear, testify, and whatever else that, when working at the Health Media Research Lab at the University of Michigan's Comprehensive Cancer Center in Ann Arbor, Michigan, I did take posession of a brand new PowerBook 5300. This unit had swappable drive bays. I don't remember exactly what I was doing, but I think I had just removed the CD drive and was powering the unit on, and it gave out a cooking sound and a puff of bad-smelling burning-insulation smoke, and yea, verily, it worked no more.
I fetched my supervisor, and he called the appropriate people, and told me that Apple wanted to examine it, since it was the first report of its kind. We got a replacement.
I'd be willing to testify under oath to this effect, to sign an affadavit, etc. "Proof" would be difficult; this would have been around ten years ago; there was no video taken of the incident. I could probably get my boss to recall it.
Is this the "flaming battery" problem? I dunno... there was no flame. It may have been a different problem. That particular model did seem to be cursed. If this happened to other users, which it very well may have, it probably got conflated with the fire incident seen in the lab.
The 5300 was the only PowerBook I ever used (and I've used all of them) that started smoking within 10 minutes of opening the box. It had swappable drive bays; I tried to put in the CD-ROM drive, a "bzzt!" was heard and a curl of black smoke came pouring out, and it was defunct. Not impressive.
My favorite model was actually the PowerBook Duo 250. Grayscale screen, exceptionally small and light, and long battery life. I used this as my primary development machine for years, doing a lot of Newton development work on it. I think there is still a possible market for an ultra-light dockable portable with no built-in drives. At the time, having a crips grayscale screen was a big cost savings over the color 270.
I have made it something of a crusade to try out as many languages as possible and not pre-judge their usefulness and capabilities. I have recently been using Ruby very successfully for some small scripting projects. I've found in the process that, although there are some things about it that drive me crazy, for this kind of task (file filters, modeling some data structures with a test script built using RubyUnit, etc.) I like it far more than Perl or Python. As far as I'm concerned, it is the logical successor to Perl. This doesn't mean I think there is no room for improvement in scripting languages, but just that Ruby's advantages already make it so I never want to look at a Perl script again.
What I like about it:
- Being able to leave off unused parentheses and chain together method calls like a_string.chomp.each... allows putting together complex file filters really, really quickly! - Nice use of iterators in just about every place it makes sense - Flexible post-statement "if" and "unless" - Faster than one might expect for a fully interpreted language - Reasonably good display of syntax errors (better than some) - Far more consistent syntax than Perl, but makes easy a lot of the same things that Perl makes easy - Excellent regexp support - Extensive library - (Most of the time) "it just works" -- an awful lot of my code ran perfectly on the first try, even though I was a Ruby Nuby. - "More than one way to do it" - "Everything is an object" - Duck typing - Support for continuations
What I dislike about it:
- Gratuitous spelling of "elsif" (When switching languages a lot, it is really frustrating to have to constantly remember whether I need to use "else if," "elsif," or "elif" - Syntax doesn't seem to lend itself well to a formal grammar; too much context-sensitivity in parsing - The last time I looked at the source it was hideous pre-ANSI C implemented with horrifying preprocessor abuses; this may be fixed now. - The closure syntax is awkward and seems limiting to writing in a truly functional style - I want to be able to pass functions around like any other object, make functions that receive multiple functions as parameters, etc., without extensive additional syntax. (Caveat: I am still learning Ruby's peculiarities, so some of this may be doable, and my difficulties may stem from surface syntax issues and the confusion over the ways it is different it is from, say, Scheme, Dylan, NewtonScript, Self, etc.) - Conventions for spelling variable scopes such as globals are enforced rather than just conventions - Not quite multi-paradigm enough for my taste (why can't I work with plain functions, for example, instead of everything's-a-method?) - Support for methods on singletons didn't do what I expected (but maybe I misunderstood) - No compilation to machine code or C - Duck typing doesn't seem consistently applied in the libraries
Anyway... I am a big defender of the principle that one should know many programming languages and use the one best suited to a particular task. I also not truly an experienced Ruby programmer yet, but so far my experience has been pleasant enough that it makes me want to use it wherever it is appropriate.
There is one problem that I see looming. I'm a long term Mac user and have done a lot of development on the platform for 68K MacOS = 7, PowerPC MacOS through 9, and MacOS X, everything from drivers to GUI applications, HyperCard, C, C++, AppleScript...
Over the course of 20 years with the platform I have a lot of old code, little apps, archives, tools, and old software. I've got programs ranging from a version of Quicken from a few years back that I never bothered to upgrade, to a lot of documents that require old applications: Claris Draw, Canvas, Word 5 and earlier, Nisus, archived files that need DDExpand to open, or Compact Pro, or really old versions of Stuffit. Even old desk accessories. Think C projects. Apple Dylan stuff. Ready, Set, Go! files. Archives from a half-dozen different e-mail programs. Old applications like a Turing Machine simulator. Really old stuff.
And, a lot of it, stuff that never became PowerPC-native, much less for the Intel ISA.
Over the years as I've had time, I've tried to get ancient files into either plain text or something more compatible with modern applications, but there is a lot of my old writing, drawing, and programming material I haven't gotten around to yet.
While very CPU-specific tools have always broken, Apple up until this transition has had a remarkable record of backward compatibility. Unfortunately it sounds like they are going to drop support for Classic altogether. It is easy to understand why; it would need a lot of hacking to handle all the endian transforms.
I'm all-too-aware now that the clock is ticking on this stuff. It makes me wish I had not even bothered to maintain all this stuff in digital form over the years, but just printed out a few hundred pounds of paper instead. Unfortunately, as they say, you can't grep a tree. I'll probably have to buy at least one more PowerPC-based Mac. But I find it appalling that the compatibility story for my old PC files, including DOS applications, is now better than Apple's compatibility story.
As far as financial impact to me: almost none. But the discontinuity in my whole history on the platform -- almost the whole salvageable history of anything I've ever done on computers, given that writing and programming I did for the TRS-80, Apple II, and C64 is irrevocably gone -- is disturbing, and really is making me think harder about the problems associated with digital data in general.
No, memory prices haven't always gone _down_. Sometimes they've gone _up_.
One of my college roommates and computer science classmates paid something like $5,000 for 4MB of RAM for his Macintosh II in around the 1988 timeframe. There was a memory price "bubble" at the time, but he needed it to run MPW (the Macintosh Programmer's Workshop) for his independent study project, so unfortunately had to suck it up. There was certainly a lot of swearing involved, though. Especially when prices went back down a few months later.
You are correct in that using the original 128K Mac was painful. _Constant_ floppy disk-swapping. Occasionally, the floppy-swapping would go into effectively an infinite loop, and the user would get so frustrated that he or she would just cycle the power.
Fortunately, the 512K "Fat Mac" came out very shortly thereafter. There was an upgrade path.
These machines were quite expensive, but the Lisa Apple's "useful machine?" To whom? Give me a break. I started using computers with the TRS-80, the Commodore PET, and the Apple II. I've even used an Apple III, but I've never even seen a Lisa. It's an obscure bit of computer history now. What is a $10,000 computer in today's dollars?
Before the LaserWriter, there was the ImageWriter, the dot-matrix printer. One of Apple's innovations was to make the aspect ratio of the printer exactly the same as the aspect ratio of the screen. You could literally hold up your printout to the screen and line up the dots. That was remarkable at the time - WYSIWYG before the LaserWriter, which was not truly WYSIWYG, given the use of separate screen and printer fonts.
The Mac "a toy?" By today's standards, perhaps. But it worked great. Many, many college papers and even books were produced with MacWrite or Microsoft Word or FullWrite on Fat Macs. And, very shortly, magazines.
Apple's real success, though, was in constantly revving their line while doing a fantastic job maintaining backward compatibility. I had a Macintosh SE, with a built-in hard drive. It is still being used by one of my friends to do real work. Where are the PCs that came out in 1987?
The 68000 did not have an MMU, so I'm not certain what you mean about "a bug in the 68000 which made page fault processing unsafe" or what you mean when you say that "Motorola was years late with the MMU." The 68020, with an MMU, was used by the Mac II in 1987, 3 years after the release of the Mac, although Apple's OS did not take advantage of it. At the time that the Mac was released, the Intel equivalent was the 80286, with its segmented architecture, limited address space, and weird memory workarounds.
With no MMU and OS support, a "page fault" is an address error. I think you're saying that the 68000 could not be turned into a decent UNIX workstation. That may be true. I don't know much about UNIX boxes from the period, but I do know that the 68020 and later Motorola CPUs powered a lot of UNIX boxes.
"No multitasking?" Not really correct. There was multi-tasking with the introduction of MultiFinder and later systems. There actually several forms of multi-tasking in the original Macintosh OS with cooperative multi-tasking with desk accessories. As the OS was improved, network and disk activity and print spooling became background tasks. The Mac always gets slammed for not having preemptive multi-tasking and protected memory early on, but it is important to keep in mind just what they were competing with at the time and just what was possible, and what provided a good user experience, at that price point. Remember that Windows 3.0 did not come out until 1990, and it did not really do preemptive multi-tasking between applications either.
I'm with your dad. Starbucks' coffees taste like burnt ass.
It isn't the roast: I've had great light roasts and great dark roasts. It isn't that they use espresso roasts. I make espresso; I like to drink good espresso straight. I frequently drink my brewed coffee with nothing added, if it is good. I love to try exotic coffees. Some of them have really fine flavors, complex and delicious, like wines.
I'm not sure what Starbucks does to their beans, or where they get their beans, but their blends comes out sour- and bitter-tasting. Somehow they've made the world think that gourmet coffee is supposed to taste this way. It isn't.
I've also gotten gift sets of Starbucks coffees: four different blends, once. They were all rancid. Roasted coffee stored at room temperature starts to taste bad after a while. Coffee just can't be shipped around and stored for months or years or it won't taste good.
To compare, get something like Lavazza espresso or Dalmyr Prodomo. These are both pre-ground and should be available at a decent gourmet grocery. Make them yourself and compare. A true coffee Nazi would probably sneer at buying these pre-ground and pre-packaged coffees, and they may not be as good as the best you can get by buying fresh-roasted and grinding them at home, but I've found these to be very reliable. Keep them in the freezer in an airtight container and they will taste decent for longer.
Consider also only buying Fair Trade coffees. That system isn't perfect, but it helps to prevent some of the more greivous of the economic injustice suffered by coffee growers.
There were worse and stranger problems than this. I had a straight Compaq I bought from Sears, running Compaq's Windows 98. I bought it to run one particular program for beta-testing purposes (Functional Objects' Functional Developer (Dylan) IDE).
Most of the time, it just merrily ran the screen saver. Until I noticed that I'd be sitting in my apartment reading, or dozing in bed, and at approximately the same time every night, it would reboot... going through the whole disk check, did-not-shut-down-properly, etc.
In other words, my brand-new out-of-the-box Compaq running Windows 98 wouldn't stay up longer than 24 hours in a row. Astounding.
I never did determine exactly who to blame: Microsoft's 98 distribution or Compaq's customizations or even the motherboard hardware. I just installed Linux. That was the last time I have owned a machine running Windows...
My brand new office G5 1.6 GHz has a dead CD drive. Omigod. This represents a MAJOR manufacturing problem. Obviously the G5 system is a misbegotten train wreck of bad design and broken, untested hacks. You should never buy one.
Or not. But how would you know? Actually it is very fast and has a really slick design. So a CD-writer failed. It happens. The only things I've been able to find to gripe about are there are some little cables dangling too near the upper PCI card slot and that the case metal is soft and easily scratched (when the instructions tell you to lay it on a soft towel, believe them. I've got some nice little gashes in the aluminum case material where some grit on our carpeted floor scraped it).
But maybe that's FUD too. Everything I'm telling you could be a lie... even this.
My point is that the macfixit.com story is interesting, and perhaps contains a lot of important and valid warnings, but it is not really a detailed bug report. It contains a lot of highly detailed ANECDOTAL cases about people who did this, and (then unknown things) and then additional things happened. They may be valuable, or they may not be, because you haven't run a controlled test on the machine in question.
To be really compelling even as anecdotal evidence, we'd need to be fairly certain that no other changes were made to the system which might result in the problems mentioned. To be really compelling as a bug report, I'd want to see the lines of code in question and an explanation of how code X running on system Y with network chip Z or framework version Q interact, in detail, to produce a problem.
In practice I did see one problem arise from the 10.2.8 update which I mistakenly installed (a friend of mine had jumped the gun and was urging me to update to fix the security issues, even though I am usually deliberately lazy by a week or two about installing updates for this very reason). I'll mention it later.
I think it is also worth noticing that at least a few of the issues are issues of compatibility with third-party programs. For example, "if you use TransparentDock to modify Dock behavior and/or appearance." Apple of course can't guarantee that arbirary system components that have been modified by third-party utilities will never change out from under these utilities.
Then there are problems like the MODU incompatibility. That sounds like a standard kind of problem with a third-party driver that works right on one version of the system and breaks on the next. Whether it is Apple's bug, or MOTUs, or just the assumption that an API will work a certain undocumented way... it doesn't matter that much. This kind of incompatibility over the life cycle of OS releases is common. Kernel drivers by definition have to do things that, if they go slightly wrong, can crash the system. (I write them for a living).
In this case it might have been avoided if Apple had separated out the security patches from the more generalized system patches. That is probably the real lesson to be learned here: "don't do monolithic updates." Of course, then we get bent out of shape because there are too many small updates.
Some of the problems, such as overwriting a flash plug-in, must be examples of weak installer scripts that don't adequately check version information. That's a very common problem. Does anyone remember DLLs getting overwritten with earlier version on Windows sytems? If you haven't seen this problem before, you haven't administered very many Windows systems.
By the way, the problem I noticed was listed in the MacFixit article under "File mapping issues." This is some degree of corroboration. Files of type.dmg.bin (disk image files packaged for download) are now showing up with an icon for Toast Titanium instead of the icon for Disk Copy.
The workaround is to use "open with." I'll also check out the sugestion to use Cocktail and see if that works. Is it a pain in the ass? Yes. Do I regret installing the upgrade before it was pulled?
We're not unaffected... I've gotten a thousand copies over the last few days, and they are still coming, sometimes in bursts of two or three a minute, and my mail server has turned to sludge under the load of not just my account but no doubt hundreds of others getting crapped on. It would be nice if we were truly unaffected. Yes, my G4 box can't run the worm, but it has still managed to make it miserable trying to get my work done, since I supervise local and overseas contractors and we do all our communication by e-mail.
I agree it is a good thing. Doing development and testing on a number of hosts I have had to bounce back and forth between machines running Solaris, Linux, and MacOS X, and on these various machines (a dozen) I never used each account often enough to customize it. I was always banging my head against the desk over such basics as how to set an environment variable. I had finally pretty much gotten used to bash before hitting MacOS X. Yes, I know I could still use bash, but again I'm working on a half-dozen machines... how much time do I really want to spend customizing them?
And it's also true that people can write quite elaborate programs as shell scripts... but just because something CAN be done doesn't mean it should be done. Talk about non-orthoganal, idiosyncratic, hard-to-remember language constructs. I mean, someone could probably write an operating system in Cobol, but why would that be a good idea? Ruby is a good choice, and Perl is widely available. Umm... did I mention that it is widely available?
I'm a MacOS X user who would prefer to use the GNU versions of certain basic tools (cp, ls, ps, tar, tail, wc, find, cat, perhaps shells, whatever). Not for any particular political/free/proprietary/open/GPL agenda, but because I'm more familiar with the GNU versions, and (to me) they seem have better man pages, better support for flags, and more consistent usage directives. What's the best way to get them? Build individually from source? Replace bundles of them in one go?
p.s.: actually, the page cited above now says "APSL version 2.0 qualifies a free software license. Apple's lawyers worked with the FSF to produce a license that would qualify. The problems described in this page are still potential issues for other possible licenses, but they do not apply to version 2.0 of the APSL."
Personally I want to know how long it will take to recompile Gwydion Dylan (http://gwydiondylan.org) and various other projects including several drivers and a large body of drivers and cross-platform C++ code built using ProjectBuilder. I'm quite certain it will be faster than either a desktop G4/867 dual processor or my first-version Powerbook G4/400, but how much faster? This test is of far more relevance to me than raw integer performance, and includes a lot of disk I/O and significant memory use.
As a developer writing IOKit drivers for MacOS X, I have to respectfully disagree with calling the Embedded C++ framework a "masterpiece of design." I'll grant it this: it works. But it doesn't support expedient coding, porting, or good modern C++ practice.
The limited dialect of C++ has been a major hassle, and the embedded C++ standard seems to be completely arbitrary. There are a lot of consequences for the C++ developer trying to write good code in the kernel. This is all allegedly done for the sake of a lower footprint and efficiency, but I just plain don't believe this arguments. I will believe that supporting these C++ features, especially as GCC has gone through revisions, would cause binary ABI compability thrashing... but that's a problem to be solved by the kernel developers. Solving it by turning C++ back (mostly) into C is not helpful.
Here's what "EC++" means to me:
- no exceptions: means that you can't have non-trivial constructors. So you're expected to use macros to generate a default constructor for your class, which initializes the base class reference count and what-not.
- no non-trivial constructors: means that you can't properly use constructor chaining and set up const members.
- not being able to set up const members means that your class can't be initialized containing reference objects.
- instead of using constructors the way Bjarne intended, there's a paradigm of using init() methods and explicitly calling the superclass init(), checking for errors everywhere.
- for memory management, I have to explicitly manage reference-counting in certain circumstances. This is because copy-construction and assignment operators can't be implemented properly in order to create a true smart-pointer class.
- the CF (CoreFoundation) container classes won't work in the kernel. To work around this, there is a simplified version of these containers available, where we have OSArray and OSNumber and what-not instead of CFArray and CFNumber. In certain circumstances, such as when working with the registry, voodoo magic results in user-space CF container objects being magically transmogrified into OS container objects. The design of both frameworks is biased towards the Objective-C runtime and not very "C++" ish.
- One feature that would have been of great utility in the kernel, where loadable modules fit into a single environment: namespaces! Instead, we're expected to preface the names of classes with com_mycompany_myproduct... uglifying everything in sight. This can be eased a little using macros, but then we've got... macros. What was the rationale that the EC++ consortium used for banning namespaces?
"The typical target CPU for the Embedded C++ specifications does not have much memory. Therefore, the size of application programs cannot be very large. Under such conditions, names seldom, if ever, come into conflict.." but the kernel is not a typical embedded application; it is precisely a place where many drivers from many different vendors will be prone to name collision.
Actually, Apple's documentation is silent on the subject of namespaces (as it is silent on many subjects). The compiler accepts them, but using them results in problems when using the macros for defining our default constructors...
- RTTI. No dynamic cast; instead we use another... wait for it... macro. With "fake" RTTI in the OSObject base class taking the place of a standard language mechanism.
Now, templates, streams, and STL, I'm actually in favor of keeping out of the kernel. (Although the standard string class, and perhaps istringstream would be nice, if it could be implemented without STL and templates). So I don't want to see all of C++ banned. Forbidding exceptions arguably makes some sense, but the consequences in this implementation cascade into a lot of pain.
Modern C++ practice calls for declaring const things const, using references instead of pointers where practical, and maintaining an allocation-is-initialization style. Embedded C++ bans "mutable," bans RTTI, forces explicit initialization, screws up const members and the use of reference members, and basically results in banning much of the modern C++ world that helps make code more robust. I don't think this is progress!
Wow, I read the essay and I'm quite stunned: in the first paragraph he's talking about "a very small Japanese gentleman" (well, yeah, a lot of Asians are somewhat smaller than us burly Americans; get over it...) with his hair cut "like a homosexual mushroom" (what the hell does that mean? You can identify gays by their haircuts?)
Then his attack on Miyamoto ("a real gun would have made Miyamoto pee in his pants from fear"). The use of the phrases "sucks," "Mario Kart: Double Ass." "Nintendo's two faced B.S."
It's also clear that he doesn't have the foggiest notion of what goes into software development; he thinks Mario Sunshine should have been released for the N64 (trying to model those water mechanics with that processor? please...) and keeps insisting that the sequels are just "re-skinned" N64 games. Game development doesn't quite work that way. I'd be surprised if a single texture, model, or line of code was actually reusable as-is.
I can't believe I've wasted so long reading this inflammatory, uninformed piece.
The main reason I have bothered to continue to support Nintendo's platform, and purchased a GameCube, and continue to play and track down old N64 games:
Nintendo's committment to putting out highly playable games... and Miyamoto's huge successes. (They haven't all been sparkling gems, but I can't think of any other game developer with such a string of successes).
Having played through 20 or 30 shines in Mario Sunshine, I can say that I won't bother to finish the game; it is good, the graphics and impressive, and some of the levels (for example, conquering the two-dimensional self-dividing manta rays) were quite fun, but overall it does not make itself sufficiently distinct from Mario 64, which is _still_ extremely playable by comparison. (My 8-year-old son concurs).
I played Zelda: the Wind Waker and finished it; the game has a few playability flaws and is a bit short, but I still rate it quite highly. The graphics are truly impressive and fluid. I've played Pikmin up to the last two ship parts; I may not finish. The Nintendo platforms are the ones that gave us Paper Mario, a great game that was also worth playing all the way to the end, and a lot of interesting oddities for the more adventurous: Rocket Robot on Wheels, Space Station Silicon Valley, Conker's Bad Fur Day (a poor seller, but it has its points, if you like poop jokes), Kirby: The Crystal Shards, the Smash Brothers games, and a lot of others that I've enjoyed and my 8-year-old son has enjoyed. (No, he doesn't get to play Conker).
It's a real testimony to the staying power of the Nintendo games that with other platforms available, other games available, and the GameCube sitting next to the N64, we still pop in Mario 64 and Kirby because they are fun to play. Really, what else is there?
Slashdot Mirror
I'm a big fan of Tolkien's works; I've even read and enjoyed large portions of the History of Middle Earth volumes, including his fascinating Lost Tales, early drafts of stories that later became parts of the Silmarillion, and some of the long poems. But I have found that some of them, such as The Silmarillion itself, and now The Children of Hurin, really benefit a lot from an audio presentation rather than just reading. I tried to get into The Silmarillion several times, but the text never really engaged me; my eyes would start to just slide down the page without absorbing anything. That is, until I listened to Martin Shaw's unabridged reading. It really comes to life; it is no longer like reading the phone book in Elvish. The same thing applies to The Children of Hurin. There is a great unabridged reading by Christopher Lee.
These readings don't make good background sound while working; they need your concentration. I'm a notorious multi-tasker and sometimes I think I've lost the ability to focus on one thing at a time, unless it is code. But they would be great for a long commute or to listen to on your iPod at the gym.
>I'm a 250 pound weightlifter
Well, I'm a 185-pound elite cyclist. But I'm cleverly disguised as an overweight middle-aged software engineer! Unless you are actually seven feet tall or more, your BMI says you're just fat. Are you sure you didn't misspell "obese couch potato who tries to convince himself that he's a jock because he goes to the gym once a week?"
The _point_ is, I think, that the laptop is now so light, and requires so few accessories, that it is a no-brainer for a business traveler to decide whether to take it along or not. He or she will just do it automatically. Because that businessperson is more likely to have the computer available to type up a note or answer a message at any given point during a work day, it just became considerably more valuable.
It doesn't hurt that it looks pretty damned sexy as well. Unfortunately Apple's sexiest toys start to look scratched-up and fugly after only a year or two, but that seems intentional so they can sell you the next expensive pretty thing.
I would bet that this is not a real use case in the demographic they've studied. In other words, people who really do strip down the weight of what they are carrying don't actually swap out the battery. Doing so requires you to carry an extra battery, and it is additionally painful to carry a second battery if you don't actually carry an external charger as well, since you have to swap batteries in your laptop while it is plugged in (perhaps in the middle of the night while you're asleep in your hotel room) to charge the second battery. So people don't do it. Instead, most people use it for a few hours on the battery, and plug it in back in as soon as they can. Personally, I've used quite a few different laptops over the last 15 years or so and carrying backup batteries rarely seemed worth the effort. If the MBA battery actually gives you five hours of real use, I think that will be remarkably effective for most users. That's well over a work day of on-and-off use typing, editing, whatever which tends to be a very on-and-off activity for a laptop.
I'd agree that the Air doesn't meet all use cases, but the more I consider what they left out, the more I think that they actually got the product very nicely targeted at the product's target demographic. If it seems like it would not match the way you use a laptop, perhaps that's a good indication that you aren't in the target demographic?
I'm sorry, but I just don't understand. You think it is _intuitive_ that if you drag an object (a folder) into a window representing a folder, and it has the same name as a folder that already exists, the two should be magically _merged_?
OK, now you've got an instant version control problem. Was the destination folder (the one you merged into) the canonical one? Was the source folder the canonical one?
With merging, you didn't lose anything, but now you have two folders, the original and the merged, that don't match. How does that help anyone keep their files organized?
Replacing isn't the default behavior -- that's why it asks you if you really want to do it.
You wrote "from the user's perspective you aren't really moving the directory, the intent is to move the files." Why do you think that? You've got to understand that most people -- including most computer users -- don't actually understand hierarchies, and never will. The icon == the directory. And that is what they are moving. Just as a physical file folder (the original metaphor, originally somewhat strained) is not the papers inside.
I guess you young-uns are too young to remember the days when cell phone clocks were about as accurate as PC clocks and you had to set them yourself when the battery went dead.
>Turns out these guys weren't reading the reply. How do I know? Well I followed the same 'booby trap' method. In a couple of e-mails
>I inserted the words "if you read this sentence, e-mail be back and I'll buy you a case of beer"...
It was probably their spam filters...
Several times I've recently had situations where a friend has written me increasingly agitated followup e-mail messages: "did you ever write me back?" and "Why haven't you written me back?" only to find that my detailed replies had gotten stuck in his spam filtering...
Ditto this. I've done development of MacOS X kernel extensions for PCI hardware. It is very rare to see a crash that wasn't the fault of my own kext. We did, though, have boxes arrive with bad RAM that caused kernel crashes. These inevitably turned out to be due to bad DIMMs installed by MacConnection or MacMall or whoever offered a free memory upgrade with purchase. I know Apple charges faintly ridiculous amounts for their memory so I can completely understand going with another vendor for RAM, but I'd encourage people to go with Crucial RAM and not unknown RAM from one of the big resellers.
You are correct, sir or madam... I mis-remembered the drive situation. It makes complete sense that I would have removed the somewhat useless floppy drive and put in the spacer.
It depends on what you mean by "fire." My name (my real name) is Paul R. Potts, and I hereby certify, affirm, swear, testify, and whatever else that, when working at the Health Media Research Lab at the University of Michigan's Comprehensive Cancer Center in Ann Arbor, Michigan, I did take posession of a brand new PowerBook 5300. This unit had swappable drive bays. I don't remember exactly what I was doing, but I think I had just removed the CD drive and was powering the unit on, and it gave out a cooking sound and a puff of bad-smelling burning-insulation smoke, and yea, verily, it worked no more.
I fetched my supervisor, and he called the appropriate people, and told me that Apple wanted to examine it, since it was the first report of its kind. We got a replacement.
I'd be willing to testify under oath to this effect, to sign an affadavit, etc. "Proof" would be difficult; this would have been around ten years ago; there was no video taken of the incident. I could probably get my boss to recall it.
Is this the "flaming battery" problem? I dunno... there was no flame. It may have been a different problem. That particular model did seem to be cursed. If this happened to other users, which it very well may have, it probably got conflated with the fire incident seen in the lab.
The 5300 was the only PowerBook I ever used (and I've used all of them) that started smoking within 10 minutes of opening the box. It had swappable drive bays; I tried to put in the CD-ROM drive, a "bzzt!" was heard and a curl of black smoke came pouring out, and it was defunct. Not impressive.
My favorite model was actually the PowerBook Duo 250. Grayscale screen, exceptionally small and light, and long battery life. I used this as my primary development machine for years, doing a lot of Newton development work on it. I think there is still a possible market for an ultra-light dockable portable with no built-in drives. At the time, having a crips grayscale screen was a big cost savings over the color 270.
I have made it something of a crusade to try out as many languages as possible and not pre-judge their usefulness and capabilities. I have recently been using Ruby very successfully for some small scripting projects. I've found in the process that, although there are some things about it that drive me crazy, for this kind of task (file filters, modeling some data structures with a test script built using RubyUnit, etc.) I like it far more than Perl or Python. As far as I'm concerned, it is the logical successor to Perl. This doesn't mean I think there is no room for improvement in scripting languages, but just that Ruby's advantages already make it so I never want to look at a Perl script again.
What I like about it:
- Being able to leave off unused parentheses and chain together method calls like a_string.chomp.each... allows putting together complex file filters really, really quickly!
- Nice use of iterators in just about every place it makes sense
- Flexible post-statement "if" and "unless"
- Faster than one might expect for a fully interpreted language
- Reasonably good display of syntax errors (better than some)
- Far more consistent syntax than Perl, but makes easy a lot of the same things that Perl makes easy
- Excellent regexp support
- Extensive library
- (Most of the time) "it just works" -- an awful lot of my code ran perfectly on the first try, even though I was a Ruby Nuby.
- "More than one way to do it"
- "Everything is an object"
- Duck typing
- Support for continuations
What I dislike about it:
- Gratuitous spelling of "elsif" (When switching languages a lot, it is really frustrating to have to constantly remember whether I need to use "else if," "elsif," or "elif"
- Syntax doesn't seem to lend itself well to a formal grammar; too much context-sensitivity in parsing
- The last time I looked at the source it was hideous pre-ANSI C implemented with horrifying preprocessor abuses; this may be fixed now.
- The closure syntax is awkward and seems limiting to writing in a truly functional style - I want to be able to pass functions around like any other object, make functions that receive multiple functions as parameters, etc., without extensive additional syntax. (Caveat: I am still learning Ruby's peculiarities, so some of this may be doable, and my difficulties may stem from surface syntax issues and the confusion over the ways it is different it is from, say, Scheme, Dylan, NewtonScript, Self, etc.)
- Conventions for spelling variable scopes such as globals are enforced rather than just conventions
- Not quite multi-paradigm enough for my taste (why can't I work with plain functions, for example, instead of everything's-a-method?)
- Support for methods on singletons didn't do what I expected (but maybe I misunderstood)
- No compilation to machine code or C
- Duck typing doesn't seem consistently applied in the libraries
Anyway... I am a big defender of the principle that one should know many programming languages and use the one best suited to a particular task. I also not truly an experienced Ruby programmer yet, but so far my experience has been pleasant enough that it makes me want to use it wherever it is appropriate.
There is one problem that I see looming. I'm a long term Mac user and have done a lot of development on the platform for 68K MacOS = 7, PowerPC MacOS through 9, and MacOS X, everything from drivers to GUI applications, HyperCard, C, C++, AppleScript...
Over the course of 20 years with the platform I have a lot of old code, little apps, archives, tools, and old software. I've got programs ranging from a version of Quicken from a few years back that I never bothered to upgrade, to a lot of documents that require old applications: Claris Draw, Canvas, Word 5 and earlier, Nisus, archived files that need DDExpand to open, or Compact Pro, or really old versions of Stuffit. Even old desk accessories. Think C projects. Apple Dylan stuff. Ready, Set, Go! files. Archives from a half-dozen different e-mail programs. Old applications like a Turing Machine simulator. Really old stuff.
And, a lot of it, stuff that never became PowerPC-native, much less for the Intel ISA.
Over the years as I've had time, I've tried to get ancient files into either plain text or something more compatible with modern applications, but there is a lot of my old writing, drawing, and programming material I haven't gotten around to yet.
While very CPU-specific tools have always broken, Apple up until this transition has had a remarkable record of backward compatibility. Unfortunately it sounds like they are going to drop support for Classic altogether. It is easy to understand why; it would need a lot of hacking to handle all the endian transforms.
I'm all-too-aware now that the clock is ticking on this stuff. It makes me wish I had not even bothered to maintain all this stuff in digital form over the years, but just printed out a few hundred pounds of paper instead. Unfortunately, as they say, you can't grep a tree. I'll probably have to buy at least one more PowerPC-based Mac. But I find it appalling that the compatibility story for my old PC files, including DOS applications, is now better than Apple's compatibility story.
As far as financial impact to me: almost none. But the discontinuity in my whole history on the platform -- almost the whole salvageable history of anything I've ever done on computers, given that writing and programming I did for the TRS-80, Apple II, and C64 is irrevocably gone -- is disturbing, and really is making me think harder about the problems associated with digital data in general.
No, memory prices haven't always gone _down_. Sometimes they've gone _up_.
One of my college roommates and computer science classmates paid something like $5,000 for 4MB of RAM for his Macintosh II in around the 1988 timeframe. There was a memory price "bubble" at the time, but he needed it to run MPW (the Macintosh Programmer's Workshop) for his independent study project, so unfortunately had to suck it up. There was certainly a lot of swearing involved, though. Especially when prices went back down a few months later.
You are correct in that using the original 128K Mac was painful. _Constant_ floppy disk-swapping. Occasionally, the floppy-swapping would go into effectively an infinite loop, and the user would get so frustrated that he or she would just cycle the power.
Fortunately, the 512K "Fat Mac" came out very shortly thereafter. There was an upgrade path.
These machines were quite expensive, but the Lisa Apple's "useful machine?" To whom? Give me a break. I started using computers with the TRS-80, the Commodore PET, and the Apple II. I've even used an Apple III, but I've never even seen a Lisa. It's an obscure bit of computer history now. What is a $10,000 computer in today's dollars?
Before the LaserWriter, there was the ImageWriter, the dot-matrix printer. One of Apple's innovations was to make the aspect ratio of the printer exactly the same as the aspect ratio of the screen. You could literally hold up your printout to the screen and line up the dots. That was remarkable at the time - WYSIWYG before the LaserWriter, which was not truly WYSIWYG, given the use of separate screen and printer fonts.
The Mac "a toy?" By today's standards, perhaps. But it worked great. Many, many college papers and even books were produced with MacWrite or Microsoft Word or FullWrite on Fat Macs. And, very shortly, magazines.
Apple's real success, though, was in constantly revving their line while doing a fantastic job maintaining backward compatibility. I had a Macintosh SE, with a built-in hard drive. It is still being used by one of my friends to do real work. Where are the PCs that came out in 1987?
The 68000 did not have an MMU, so I'm not certain what you mean about "a bug in the 68000 which made page fault processing unsafe" or what you mean when you say that "Motorola was years late with the MMU." The 68020, with an MMU, was used by the Mac II in 1987, 3 years after the release of the Mac, although Apple's OS did not take advantage of it. At the time that the Mac was released, the Intel equivalent was the 80286, with its segmented architecture, limited address space, and weird memory workarounds.
With no MMU and OS support, a "page fault" is an address error. I think you're saying that the 68000 could not be turned into a decent UNIX workstation. That may be true. I don't know much about UNIX boxes from the period, but I do know that the 68020 and later Motorola CPUs powered a lot of UNIX boxes.
"No multitasking?" Not really correct. There was multi-tasking with the introduction of MultiFinder and later systems. There actually several forms of multi-tasking in the original Macintosh OS with cooperative multi-tasking with desk accessories. As the OS was improved, network and disk activity and print spooling became background tasks. The Mac always gets slammed for not having preemptive multi-tasking and protected memory early on, but it is important to keep in mind just what they were competing with at the time and just what was possible, and what provided a good user experience, at that price point. Remember that Windows 3.0 did not come out until 1990, and it did not really do preemptive multi-tasking between applications either.
I'm with your dad. Starbucks' coffees taste like burnt ass.
It isn't the roast: I've had great light roasts and great dark roasts. It isn't that they use espresso roasts. I make espresso; I like to drink good espresso straight. I frequently drink my brewed coffee with nothing added, if it is good. I love to try exotic coffees. Some of them have really fine flavors, complex and delicious, like wines.
I'm not sure what Starbucks does to their beans, or where they get their beans, but their blends comes out sour- and bitter-tasting. Somehow they've made the world think that gourmet coffee is supposed to taste this way. It isn't.
I've also gotten gift sets of Starbucks coffees: four different blends, once. They were all rancid. Roasted coffee stored at room temperature starts to taste bad after a while. Coffee just can't be shipped around and stored for months or years or it won't taste good.
To compare, get something like Lavazza espresso or Dalmyr Prodomo. These are both pre-ground and should be available at a decent gourmet grocery. Make them yourself and compare. A true coffee Nazi would probably sneer at buying these pre-ground and pre-packaged coffees, and they may not be as good as the best you can get by buying fresh-roasted and grinding them at home, but I've found these to be very reliable. Keep them in the freezer in an airtight container and they will taste decent for longer.
Consider also only buying Fair Trade coffees. That system isn't perfect, but it helps to prevent some of the more greivous of the economic injustice suffered by coffee growers.
There were worse and stranger problems than this. I had a straight Compaq I bought from Sears, running Compaq's Windows 98. I bought it to run one particular program for beta-testing purposes (Functional Objects' Functional Developer (Dylan) IDE).
Most of the time, it just merrily ran the screen saver. Until I noticed that I'd be sitting in my apartment reading, or dozing in bed, and at approximately the same time every night, it would reboot... going through the whole disk check, did-not-shut-down-properly, etc.
In other words, my brand-new out-of-the-box Compaq running Windows 98 wouldn't stay up longer than 24 hours in a row. Astounding.
I never did determine exactly who to blame: Microsoft's 98 distribution or Compaq's customizations or even the motherboard hardware. I just installed Linux. That was the last time I have owned a machine running Windows...
My brand new office G5 1.6 GHz has a dead CD drive. Omigod. This represents a MAJOR manufacturing problem. Obviously the G5 system is a misbegotten train wreck of bad design and broken, untested hacks. You should never buy one.
.dmg.bin (disk image files packaged for download) are now showing up with an icon for Toast Titanium instead of the icon for Disk Copy.
Or not. But how would you know? Actually it is very fast and has a really slick design. So a CD-writer failed. It happens. The only things I've been able to find to gripe about are there are some little cables dangling too near the upper PCI card slot and that the case metal is soft and easily scratched (when the instructions tell you to lay it on a soft towel, believe them. I've got some nice little gashes in the aluminum case material where some grit on our carpeted floor scraped it).
But maybe that's FUD too. Everything I'm telling you could be a lie... even this.
My point is that the macfixit.com story is interesting, and perhaps contains a lot of important and valid warnings, but it is not really a detailed bug report. It contains a lot of highly detailed ANECDOTAL cases about people who did this, and (then unknown things) and then additional things happened. They may be valuable, or they may not be, because you haven't run a controlled test on the machine in question.
To be really compelling even as anecdotal evidence, we'd need to be fairly certain that no other changes were made to the system which might result in the problems mentioned. To be really compelling as a bug report, I'd want to see the lines of code in question and an explanation of how code X running on system Y with network chip Z or framework version Q interact, in detail, to produce a problem.
In practice I did see one problem arise from the 10.2.8 update which I mistakenly installed (a friend of mine had jumped the gun and was urging me to update to fix the security issues, even though I am usually deliberately lazy by a week or two about installing updates for this very reason). I'll mention it later.
I think it is also worth noticing that at least a few of the issues are issues of compatibility with third-party programs. For example, "if you use TransparentDock to modify Dock behavior and/or appearance." Apple of course can't guarantee that arbirary system components that have been modified by third-party utilities will never change out from under these utilities.
Then there are problems like the MODU incompatibility. That sounds like a standard kind of problem with a third-party driver that works right on one version of the system and breaks on the next. Whether it is Apple's bug, or MOTUs, or just the assumption that an API will work a certain undocumented way... it doesn't matter that much. This kind of incompatibility over the life cycle of OS releases is common. Kernel drivers by definition have to do things that, if they go slightly wrong, can crash the system. (I write them for a living).
In this case it might have been avoided if Apple had separated out the security patches from the more generalized system patches. That is probably the real lesson to be learned here: "don't do monolithic updates." Of course, then we get bent out of shape because there are too many small updates.
Some of the problems, such as overwriting a flash plug-in, must be examples of weak installer scripts that don't adequately check version information. That's a very common problem. Does anyone remember DLLs getting overwritten with earlier version on Windows sytems? If you haven't seen this problem before, you haven't administered very many Windows systems.
By the way, the problem I noticed was listed in the MacFixit article under "File mapping issues." This is some degree of corroboration. Files of type
The workaround is to use "open with." I'll also check out the sugestion to use Cocktail and see if that works. Is it a pain in the ass? Yes. Do I regret installing the upgrade before it was pulled?
We're not unaffected... I've gotten a thousand copies over the last few days, and they are still coming, sometimes in bursts of two or three a minute, and my mail server has turned to sludge under the load of not just my account but no doubt hundreds of others getting crapped on. It would be nice if we were truly unaffected. Yes, my G4 box can't run the worm, but it has still managed to make it miserable trying to get my work done, since I supervise local and overseas contractors and we do all our communication by e-mail.
I agree it is a good thing. Doing development and testing on a number of hosts I have had to bounce back and forth between machines running Solaris, Linux, and MacOS X, and on these various machines (a dozen) I never used each account often enough to customize it. I was always banging my head against the desk over such basics as how to set an environment variable. I had finally pretty much gotten used to bash before hitting MacOS X. Yes, I know I could still use bash, but again I'm working on a half-dozen machines... how much time do I really want to spend customizing them?
And it's also true that people can write quite elaborate programs as shell scripts... but just because something CAN be done doesn't mean it should be done. Talk about non-orthoganal, idiosyncratic, hard-to-remember language constructs. I mean, someone could probably write an operating system in Cobol, but why would that be a good idea? Ruby is a good choice, and Perl is widely available. Umm... did I mention that it is widely available?
So I ask the accumulated wisdom of Slashdot:
I'm a MacOS X user who would prefer to use the GNU versions of certain basic tools (cp, ls, ps, tar, tail, wc, find, cat, perhaps shells, whatever). Not for any particular political/free/proprietary/open/GPL agenda, but because I'm more familiar with the GNU versions, and (to me) they seem have better man pages, better support for flags, and more consistent usage directives. What's the best way to get them? Build individually from source? Replace bundles of them in one go?
p.s.: actually, the page cited above now says "APSL version 2.0 qualifies a free software license. Apple's lawyers worked with the FSF to produce a license that would qualify. The problems described in this page are still potential issues for other possible licenses, but they do not apply to version 2.0 of the APSL."
Personally I want to know how long it will take to recompile Gwydion Dylan (http://gwydiondylan.org) and various other projects including several drivers and a large body of drivers and cross-platform C++ code built using ProjectBuilder. I'm quite certain it will be faster than either a desktop G4/867 dual processor or my first-version Powerbook G4/400, but how much faster? This test is of far more relevance to me than raw integer performance, and includes a lot of disk I/O and significant memory use.
As a developer writing IOKit drivers for MacOS X, I have to respectfully disagree with calling the Embedded C++ framework a "masterpiece of design." I'll grant it this: it works. But it doesn't support expedient coding, porting, or good modern C++ practice.
The limited dialect of C++ has been a major hassle, and the embedded C++ standard seems to be completely arbitrary. There are a lot of consequences for the C++ developer trying to write good code in the kernel. This is all allegedly done for the sake of a lower footprint and efficiency, but I just plain don't believe this arguments. I will believe that supporting these C++ features, especially as GCC has gone through revisions, would cause binary ABI compability thrashing... but that's a problem to be solved by the kernel developers. Solving it by turning C++ back (mostly) into C is not helpful.
Here's what "EC++" means to me:
- no exceptions: means that you can't have non-trivial constructors. So you're expected to use macros to generate a default constructor for your class, which initializes the base class reference count and what-not.
- no non-trivial constructors: means that you can't properly use constructor chaining and set up const members.
- not being able to set up const members means that your class can't be initialized containing reference objects.
- instead of using constructors the way Bjarne intended, there's a paradigm of using init() methods and explicitly calling the superclass init(), checking for errors everywhere.
- for memory management, I have to explicitly manage reference-counting in certain circumstances. This is because copy-construction and assignment operators can't be implemented properly in order to create a true smart-pointer class.
- the CF (CoreFoundation) container classes won't work in the kernel. To work around this, there is a simplified version of these containers available, where we have OSArray and OSNumber and what-not instead of CFArray and CFNumber. In certain circumstances, such as when working with the registry, voodoo magic results in user-space CF container objects being magically transmogrified into OS container objects. The design of both frameworks is biased towards the Objective-C runtime and not very "C++" ish.
- One feature that would have been of great utility in the kernel, where loadable modules fit into a single environment: namespaces! Instead, we're expected to preface the names of classes with com_mycompany_myproduct... uglifying everything in sight. This can be eased a little using macros, but then we've got... macros. What was the rationale that the EC++ consortium used for banning namespaces?
"The typical target CPU for the Embedded C++ specifications does not have much memory. Therefore, the size of application programs cannot be very large. Under such conditions, names seldom, if ever, come into conflict.." but the kernel is not a typical embedded application; it is precisely a place where many drivers from many different vendors will be prone to name collision.
Actually, Apple's documentation is silent on the subject of namespaces (as it is silent on many subjects). The compiler accepts them, but using them results in problems when using the macros for defining our default constructors...
- RTTI. No dynamic cast; instead we use another... wait for it... macro. With "fake" RTTI in the OSObject base class taking the place of a standard language mechanism.
Now, templates, streams, and STL, I'm actually in favor of keeping out of the kernel. (Although the standard string class, and perhaps istringstream would be nice, if it could be implemented without STL and templates). So I don't want to see all of C++ banned. Forbidding exceptions arguably makes some sense, but the consequences in this implementation cascade into a lot of pain.
Modern C++ practice calls for declaring const things const, using references instead of pointers where practical, and maintaining an allocation-is-initialization style. Embedded C++ bans "mutable," bans RTTI, forces explicit initialization, screws up const members and the use of reference members, and basically results in banning much of the modern C++ world that helps make code more robust. I don't think this is progress!
Wow, I read the essay and I'm quite stunned: in the first paragraph he's talking about "a very small Japanese gentleman" (well, yeah, a lot of Asians are somewhat smaller than us burly Americans; get over it...) with his hair cut "like a homosexual mushroom" (what the hell does that mean? You can identify gays by their haircuts?)
Then his attack on Miyamoto ("a real gun would have made Miyamoto pee in his pants from fear"). The use of the phrases "sucks," "Mario Kart: Double Ass." "Nintendo's two faced B.S."
It's also clear that he doesn't have the foggiest notion of what goes into software development; he thinks Mario Sunshine should have been released for the N64 (trying to model those water mechanics with that processor? please...) and keeps insisting that the sequels are just "re-skinned" N64 games. Game development doesn't quite work that way. I'd be surprised if a single texture, model, or line of code was actually reusable as-is.
I can't believe I've wasted so long reading this inflammatory, uninformed piece.
The main reason I have bothered to continue to support Nintendo's platform, and purchased a GameCube, and continue to play and track down old N64 games:
Nintendo's committment to putting out highly playable games... and Miyamoto's huge successes. (They haven't all been sparkling gems, but I can't think of any other game developer with such a string of successes).
Having played through 20 or 30 shines in Mario Sunshine, I can say that I won't bother to finish the game; it is good, the graphics and impressive, and some of the levels (for example, conquering the two-dimensional self-dividing manta rays) were quite fun, but overall it does not make itself sufficiently distinct from Mario 64, which is _still_ extremely playable by comparison. (My 8-year-old son concurs).
I played Zelda: the Wind Waker and finished it; the game has a few playability flaws and is a bit short, but I still rate it quite highly. The graphics are truly impressive and fluid. I've played Pikmin up to the last two ship parts; I may not finish. The Nintendo platforms are the ones that gave us Paper Mario, a great game that was also worth playing all the way to the end, and a lot of interesting oddities for the more adventurous: Rocket Robot on Wheels, Space Station Silicon Valley, Conker's Bad Fur Day (a poor seller, but it has its points, if you like poop jokes), Kirby: The Crystal Shards, the Smash Brothers games, and a lot of others that I've enjoyed and my 8-year-old son has enjoyed. (No, he doesn't get to play Conker).
It's a real testimony to the staying power of the Nintendo games that with other platforms available, other games available, and the GameCube sitting next to the N64, we still pop in Mario 64 and Kirby because they are fun to play. Really, what else is there?