This whole thing is stupid. The time you save by going from Qwerty to Dvorak is always going to be tiny compared to the time you lost in the first place by learning the Qwerty layout when you already knew the alphabetical layout.
Keyboards should arrive in alphabetic layout - either ABCDEFGHIJ across the top, KLMNOPQRS in the middle, and TUVWXYZ on the bottom, or ADGJMPSVXZ across the top with BEHKNQTWY in the middle and CFILORU on the bottom. Either way would make it dramatically faster for new computer users / typists.
For the 0.5% of the computer users who would gain productivity by switching to something faster, they can go the Dvorak route, or anything they choose. For the rest of us, the right thing to optimize is the initial learning curve.
Alternately, if we could just change the ABC song so it goes, "QWERT, YUIOPAS. DFG, HJK, LZXCVBNM. No I know my QW, next time won't I sing with U", then that would also lessen the learning curve, without making all those Qwerty keyboards obsolete...
Man, I was looking forward to being able to actually walk into a store and not have them be sold out of Wii, or maybe even have a Wii at a discount... and now this. Great. Thanks a lot, pro-family church nazis.
Even if DCA can't be patented, the use of DCA in combination with some other drug *can* be patented. Enforcement might be an issue, but if the results of DCA in combination with something else are even better than DCA by itself, this is something the drug companies would pursue.
As a side note, DCA is described as "relatively non-toxic". Ummmm.... relatively?? As Venkman said, could we clarify that? I'm a little unclear on the whole non-toxic/relatively non-toxic thing.
> 20% of time working on personal projects > > Fine, but if you're working in a smaller, less demanding > company, you might have that time free, so you can work > on the projects without the company knowing about it.
On company time?
The great thing about Google 20% time is Google is aware of it and sponsors it. So when my 20% time project got big enough that I couldn't run it as a process on my desk anymore, they set up a machine (complete with an SRE to watch over it) on a rack somewhere to run my project. And then another. Now I work on it more than half the time, and if it goes where I hope it will, I'll be recruiting a team for it soon. That doesn't happen at most small companies, where your project is generally seen as a distraction from the few things that the company desperately needs, in order stay in business.
You do remember that Google's CEO, Eric Schmidt, recently joined Apple's board, right?
And you do remember Google's place in Steve Jobs' commencement speech at Stanford? And I quote:
When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.
> Copies of the notes were captured by a handful of bloggers and > shared around the Web. The company subsequently took down its > original PowerPoint slide presentation and replaced it with a > 94-page Adobe Acrobat file, devoid of the speaker notes.
Also, to be fair, adoption of writely is picking up very quickly, mostly because it does something Word can't do: put a shared document somewhere where a lot of people can simultaneously make edits to it, without the horrid wiki interfaces. And most text is composed within e-mail apps, not a word processor. And why would you use Word for anything that is predominantly straight text, for which HTML does very nicely? I guess what I'm saying is, word processing, which was the first "killer app" for personal computers, isn't so killer anymore. And, of course, not everyone has a Windows machine, since the default for most Googlers is a Linux box, and usually it's your laptop that runs Windows - though only if you opt for a Windows machine instead of a PowerBook.
But, you know, other than that.... If you have a Windows box, AND you don't need to collaborate with your document, or share it through a predominantly HTML medium, AND it's not so simple that you could do it with HTML and <B>, <I>, and <U> tags, then, you know, definitely you would reach for Word, and not OpenOffice or Adobe Arcobat. ("Other than that, Mrs. Lincoln... how'd you like the play?"... Sigh.)
jbx
ps Just as a sidenote, I worked at MacBU within Microsoft, and our shipping bonus for Mac Office 2004 was an iPod. Only a few months later, the fuss about Microsoft employees using iPods erupted; I almost made T-Shirts that said "Microsoft gave me my iPod"!
Nearly anyone at Google who wants to write a long document uses Word. If they want to work on a spreadsheet, they launch Excel. And a presentation? PowerPoint.
And the predominant Google laptop? An IBM ThinkPad running Windows, with Office pre-installed.
> I'd say one of the mail problems with GMail is the fact that their outbound SMTP relayers > are off-and-on listed in the dnsbl.sorbs.net blackhole. This means mail you send out may > get blocked by receiving servers that check this blackhole. > > I'm regularly getting these kinds of messages when I send out mail and that really sucks: > > PERM_FAILURE: SMTP Error (state 9): 554 Service unavailable; Client host [64.233.166.180] > blocked using dnsbl.sorbs.net; Spam Received See: http://www.sorbs.net/lookup.shtml?64.233.166.180
How is that a problem with GMail? Seems to me it's a problem with sorbs.
sorbs has suggested to GMail that GMail should expose the IP address from which the message originated; that way sorbs could block by real IP instead of GMail's mailing agent's IP. GMail has responded that to expose the IP of the sender would violate the privacy of the sender. sorbs responds, basically, "well, IP address is how we work. If you only give us one IP address to work with, that's the one we list as blackholed." And so they list the GMail outbound IP addresses as blocked.
More saliently, sorbs says:
sorbs does NOT block email, websites or the Internet. sorbs is NOT CAPABLE of blocking email, websites or the Internet.
What you need to do is contact the mail server that (after communicating with sorbs) decided to block your mail. The only way sorbs will ever change their policy of "you must violate the privacy of your users or we will block your mail" is of enough of their users complain about it.
> "Each app runs as a virtual Mac, with the OS acting to stitch together the virtualizations." > > ACK! He says, mentally running through the point of contacts with the hardware, events, file system, > networking, windowing, interapplication communication, scripting, clipboard. Yeah, you could do it, > and in fact, they did do it with Rhapsody's Blue Box "Classic" mode, but you'd practically have to > write an entire OS to put beneath it... which, from a certain perspective, is what they did.
Yes, my point exactly: they had to do this in order to handle the "Classic" mode anyway. But instead of putting in a shim that the ClassicOS talks to, they should have put in a shim that the ClassicOS *apps* talk to.
And given that a lot of the performance issues under Carbon in OS X don't happen under Classic, they probably could have avoided them in a "MultiClassic" environment too.
Ah well. Looks like the spirit of killing pre-OS X technologies lived long enough to kill Classic on the Intel Macs, so I think it'll only get harder to actually ever make something like this happen.
> As to OS X'isms, and speaking as someone who did Apple/Lisa/Mac development in 77/83/84
Wow, you did Lisa development? Man, I'd love to see a Virtual Lisa, to show people who believe that the Mac started it all. (I always hated that Apple was so tight on its restrictions as to who was allowed to develop for Lisa.)
> "Apple's development organization became convinced that to truly take the machine > forward, they would require a totally new OS." > > That's true. But a good portion of that reasoning lay in the fact that to get to > preemptive you needed to rewrite the kernel, event manager, memory manager, file > manager, good portions of quickdraw and the graphics engine, device drivers, etc., > to make them reentrant. So, by the time you've done that you've rewritten practically > the entire OS, and then the real question becomes: do we want to do all of that work, > only to fundamentally end up back where we started? And can we even do that without > breaking half the applications out there that depend on some obscure bit of > functionality or behavior?
Ah, now we're getting somewhere. I think that's roughly the reasoning they followed - since we have to rewrite it anyway, why not *really* rewrite it?
The answer is pretty simple: because there's a lot of good stuff in what had been written - for example, a graphics engine that had been written at a very low level to run efficiently on very slow hardware. (Consider that on the original Mac, menus were drawn on-demand, as the user interacted with them. Same on Windows. But on OS X it's so slow to draw the menus that they have to draw them in advance and cache the resultant bitmaps) And the flipside is there, too: there's no guarantee that the new design you come up with won't have its own fundamental flaws and shortcomings. It's a choice between the beast you know and the beast you create. In my experience it's easier to fix the beast you know. (At least, as long as the beast you know has as many good points as Mac OS had.)
The insight that no one ever had was that rather than fix it from the inside, you could treat the whole thing as a virtualization and fix it from the outside: Each app runs as a virtual Mac, with the OS acting to stitch together the virtualizations. That is to say, imagine multiple copies of Classic running alongside each other. Each is memory-protected from the other; each can crash horribly and not affect the rest of the OS. Each can be pre-emptively scheduled against the other. If you approach the problem from that direction, the need to re-write everything disappears. Of course, it would still be a lot of work; the file manager and device manager would have to be stubbed out and put in a central place for example. But it would be a lot less work than a complete rewrite. A lot of the work to stub out the file system was done already for A/UX, Apple's first attempt at a Unix-based Mac, and just needed to be carried over.
> "The car you drive is a series of incremental improvement..." > > I don't think you want to go down that road, because if you do, we can start talking > about the decades of incremental improvements that have gone ito Unix, BSD and Mach. > (grin)
To the contrary; I think that's an excellent point. If I were a user of BSD, I would look at OS X and be quite happy with what Apple's done with it - preserving the good parts of BSD while adding a lot of extra value. Heck - you can even boot a Mac in single-user mode with no GUI if you want to! If only the experience for old Mac people could have been as positive, or had a similar way to turn the new OS X-isms off!
> For all practical purposes it was B&W unless you were printing, and even then you had to > jump through hoops. To get color onscreen we needed the nearly complete rewrite that was > Color Quickdraw on the Mac II.
Yes. But you know what? That didn't require a ground-up rewrite. And they added a lot more than color: support for multiple screens and support for third-party graphics cards, for example. And if you wanted run the screen in black-and-white, you could still do it - something you can't do in OS X.
> "The overhead of swapping out a hundred low-level globals... but it's just not a > factor these days." > > Right. Because when you're switching application contexts a thousand times a second you > really want to waste time moving hundreds of discontinuous memory locations. Heck, these > days just swapping out the stack is a performance hit that has systems designers gnashing > their teeth.
I wish more of those systems designers worked at Apple.
hundreds of discontinuous memory locations... OK, let's say 100 4-byte values plus 100 2-byte values. That's 600 bytes.
Now let's look at the bare minimum of what a PowerPC has to swap: 32 32-bit registers plus 32 64-bit floating-point registers plus 32 128-bit AltiVec registers, plus the 32-bit PC and 32-bit condition-code register. That's 32 * (4+8+16) + 32 + 32, or 960 bytes.
You remind me of the folks who used to complain about Apple's "Ticks" low-mem global, which kept track of how many 60ths of a second had elapsed since system startup. They complained because it wasn't aligned on a 4-byte boundary - yet it was accessed so often - read and written to!
The reality is, it just doesn't take that much longer to increment a mis-aligned longword. On later PowerPCs it makes absolutely no difference, in fact.
By contrast under OS X, if you want to read the value of Ticks, you have to call TickCount(). But under OS X, that first makes a call which determines the number of microseconds since start, turns that into a floating-point variable, and then turns it back into an integer. Old OS X programs (like Metrowerks CodeWarrior) called TickCount() a lot to see if enough time had elapsed to check for user interaction; those programs had to be re-written because suddenly the call to TickCount() was a bottleneck!!!
> And we still had an entire cottage industry devoted to memory managers and debuggers > that tried to track down the bugs that system encouraged.
I believe there is still a cottage industry for memory managers and debuggers on Windows and Linux. No?
> If "rewriting" a few parts of the system were that easy they would have down it.
Now you're hitting on the true problem. This ceased to be true after System 7 shipped. Apple's development organization became convinced that to truly take the machine forward, they would require a totally new OS. So a small group of people continued to maintain System 7, while the "real" work went into Pink, which became Taligent. And when that failed, into Copland. And when that failed, into OS X. And OS X shipped way, way, way late.
Time and time again, Apple's large teams, working on the "next big thing", failed, while the small group of people (Blue Meanies et al) working on 7.x, 8.x, and 9.x were actually delivering the incremental improvements that people needed. Had Apple put together a small team to "hack on" memory protection into System 7, it would have been done long ago. But Apple's management preferred to build empires of superteams working on a new revolutionary OS, so they could say, "I lead a team of 200 programmers".
"the original MacOS was a great acheivement. So was the Model-T. Today, I refuse to drive either one."
The car you drive is a series of incremental improvements on the Model-T. Even after all these years, the basic design laid down back then is the one we still use: conveyor-belt-style assembly of a car wi
> This is highly unlikely. HLock originally only ever set a flag. It now doesn't even need > to do that, since a Handle never moves under OS X, but if it did, it still would only > need to set a flag. Even allowing the overhead of calling through a shim into Carbon > this wouldn't amount to a huge call. There may be other APIs that do exhibit the > behaviour you mention, but this was a very bad example to pick.
I can't tell if you're clueless to the horrible Carbon implementation under OS X, or just baiting me.
I was one of the people involved in the port of Mac Office to OS X, at Microsoft, during 2001/2002. My particular job was to make Entourage perform fast under X, and one of the things that repeatedly came up when running Apple's sampling profiler tools was time spent inside HLock/HUnlock. Apple's answer, rather than making HLock/HUnlock faster, was "just remove your calls to HLock and HUnlock, since they don't do anything anyway."
Unfortunately the code in question came from a third-party text rendering engine, and the locked-or-not state of handles was actually important, so I couldn't just get rid of the calls. But the time I spent reducing the frequency of them being called made things much faster.
Later on I talked with the author of iTunes about this, and he remarked that he was able to just #define away his HLock/HUnlock calls, for OS X iTunes. (OS 9 iTunes still needed them, of course) He said it made the app smaller, and about 10% faster.
"it was also written from the ground up to be B&W, single-threaded, single-tasking, use fixed-size memory spaces, and totally without any form of internal or user-based security."
Incorrect. It was designed to allow 3-bit color, actually - the quickdraw headers defined 8 colors, not two.
"Or are you saying a modern OS should swap out hundreds of shared low-level global variables on every context switch?"
The overhead of swapping out a hundred low-level globals in 2006 is, oh, about a hundred cycles. Oops: swap, so 200. Whoop-de-doo. People complained about that when a lot of the user base still had 68000-base machines running at 8MHz, but it's just not a factor these days. Even so, you could re-write OS 9 not to have so many globals without the extensive re-write that was OS X.
"why should a modern OS have a handle-based non-protected fixed-patition-sized memory system, itself probably responsible for half the memory allocation/corruption bugs and crashes in any given Mac application."
Oh, so the OS causes your app to crash? I could respond that multi-threading causes so many hard-to-understand bugs that it's responsible for half the crashes, but I'm against the shirking of responsibility.
As for Handle-based, Handles allowed programmers to write programs that were nearly 100% efficient in their use of memory - albeit at the expense of slow compactions from time to time. Not so far removed from Java, actually, though without the benefit of automatic garbage collection. The OS X equivalent - to just use Ptr-based memory instead, and swap a lot, is one of the reasons OS X requires a lot more RAM than OS 9 does. (Well, it doesn't actually need the RAM; but you'll swap a lot without it.)
"Perhaps you can explain why the system resource and process-slicing allocation kernal of a modern OS needs to be "graphical" from the ground up? Or conversely, why graphics, networking, file management, and other subsystems should not be layered on top of a rock-solid base?"
The system resource, process-slicing kernel of the OS doesn't need to be graphical. And indeed the nanokernel inside PowerPC Macs was not. But layering graphics APIs on top of file-based IPC mechanisms introduces dramatic inefficiencies. Networking and file management had a pretty solid base under OS 9, just not a fast one. (file access is one of the few things where OS X is notably and dramatically faster, incidentally - e-mail database rebuilds are about 2x faster under OS X.)
OK, first off, you're right that OS 9 and its predecessors didn't have memory protection or full SMP support. But adding these things doesn't involve the amount of memory bloat or performance reduction that OS X has. I added memory protection as a feature for Jasik's Debugger back in '90 - even going so far as using the MMU to be able to prevent an application from reading from the first 4K - that is, dereferencing a NULL pointer - and that was just a hack that took about 2 months of time. There's no doubt in my mind that people who had real access to the sources for the OS, and a real amount of time, could do much better.
SMP is a hell of a lot trickier, especially given Apple's graphics architecture and its penchant for global variables... but Apple was a lot further along this path than people realize. And they would have gotten even further, except that Steve/Avi started blocking development of OS 9 APIs.
And yes, OS X is way, way more reliable. Any time I go back to OS 9, and am forced to reboot due to a crash, I ponder why on earth we Mac users lived with this for all those years.
But the 'everything is a file' mantra... Uggh. This, and the idea of seperating different parts of the OS into different processes, is a big part of the problem. On the original Mac, you say "MoveTo(10,10);" to move the pen, and it does a couple if dispatches, stores the new values of x and y, and returns. Under OS X, this involves... oh hell, frankly I have no idea because you can't just step into another process and follow the work. I'm relatively certain it involves dispatching a message to another process. What I really want to do is write a small benchmark and use Shark to tell you where the time is being spent - it would be very illustrative... LineTo would be an even better example, because under OS 9, it could actually be graphically accelerated to draw the line. Under OS X, the line is drawn to an off-screen buffer first. Then a custom region of "dirty bits" is updated so that, later down the line, the blit that copies the off-screen bits onscreen can copy only the bits of the actual line to the screen. Even ScrollBits, which was perfect for acceleration under 9, is performed by the CPU under X, with the GPU doing only the bitcopy from main RAM to graphics RAM.
You say a modern OS "needs to do more work". Sure, but not the absurd amount of work that OS X actually does.
As for HLock, OS X doesn't need to do any more work. newsflash: under OS X the only thing this call needs to do is set a bit so that future callers of HGetState get the bit back. It doesn't need to go to a seperate process, doesn't need to deal with MP. And unlike OS 9, it doesn't need to deal with ROM handles or 24-bit heaps. It could be implemented in two instructions if they were willing to allow a little memory wastage, or about ten if they didn't. Or they could hire bozos and implement it as a dictionary-of-locked handles, which seems to be what they did, given its slow perf.
Look, let me put it another way: run OS 9 under OS X through the Classic emulation layer. Then write a program which does nothing but open a window and draw a bunch of stuff, maybe call HLock a few hundred times. Then time the exact same thing as a "native" OS X app. Then explain to me why the OS 9 version was so much faster.
(Annoyingly, I'm writing this on my personal Mac, which is Intel-based, and Apple's upgrade of my old machine neglected to copy any of the built-in dev tools to the new Mac, so I can't report real numbers to make my case. Or run Classic anymore - Grrrr.)
You are right that the switch to OS X was brave. well-conceived? Maybe. Well executed? No way.
For all the talk about the speed of OS X, Apple has never addressed the most obvious issue: on a machine that can run either OS 9 or OS X, OS 9 is very much faster. They took an OS written from the ground up in the early 80s to be graphical, and replaced it with an OS written the 70s to be textual, with the GUI glued on top of it.
And then even worse, the people who wrote Carbon, the MacOS backward-compatibility layer, had no idea how to write it to be fast - simple calls like HLock which used to be two instructions on the original 128K Mac are now thousands of cycles under OS X. (And Apple's answer to this? "Remove your HLock calls; they don't do anything anyway.")
Don't get me wrong; they've done great things, given what they started with. But they threw out the baby with the bathwater when they ditched MacOS.
I'm not so sure about that. Deleting your account is more serious than just emptying your trash; I believe that in some European juridictions, there are strong privacy laws that mandate that Google/Yahoo/Hotmail/whoever really will delete your account if you tell them to. (Within 3 days, if I recall correctly.)
This is just the beginning. If this stands (and is not overruled by a higher court), then soon the government will have the right to run "undelete" on your hard drive looking for things, or go searching through your trash and your shredder looking for evidence!!
Have you ever typed an address into Google? I do it a fair amount, because it's easier to type the address into the Google searchbox of Firefox, and then click the map button, than to first type "maps.google.com" and then type the address.
So there's lots of addresses in the search logs. Not just IP addresses - I mean real addresses.
Also, a lot of people type in their own credit card numbers. It's an easy way to be sure your credit card is not on the internet: just type it into Google. No hits, no worries.
People also type UPS/FedEx tracking numbers. And telephone numbers. Some search for their own SS# to be sure some idiot hasn't leaked it. And never for a second do any of these people think, "the government is going to take my search and put it into a big list of things people searched for".
Also, I Am Not A Lawyer, but wouldn't the results of this subpoena become public record?
> Then send your kids to private parochial (or other such) school.
Yeah, sure, if I could afford it.
Maybe if the government would give me the $9,000 per year (or whatever it is these days) that they would have to spend on my child's education, if I left them in public school, then I could afford to send my child to private school. As it is, they tax me enough for private school, then refuse to let that money go to my child's education - unless of course I send my child to one of *their* schools.
Anyway, this fight isn't about "mythology". This fight is about preventing the government from teaching my kids that all scientists believe that humans came about through random evolution from lower species. And when the bible-thumpers try to add even the smallest disclaimer, like beginning the evolution teaching with "by the way, this is only a theory, and it's not the only commonly-accepted theory, either", all hell breaks loose.
The government wants to take my money from me and use it to teach my children that religion is wrong about the origin of our species. That is *not* seperation of church and state - that is state-sponsored atheism.
Re:I was on the MacIE 6 team when it got canned...
on
Microsoft Ends IE for Mac
·
· Score: 4, Informative
Jimmy Grewal posted a follow-up to this on his blog, which covers some extra points:
A lot of what he says is true; but the story is more complex than this and there were many other factors that came into play. Issues which he doesn't cover...primarily because he wasn't working on the product much until the last few months of development:
* - Mac IE was the first real browser running on Mac OS X. We had it running on Developer Preview 2 and it shipped on the Public Beta CD-ROM. That was a great engineering achievement but it came at a very high price. Developing for OS X in those early days was a nightmare and we spent so much time struggling with OS bugs and changing APIs that precious time that could have been used to improve the product was wasted just trying to maintain compatibility with each new beta release of OS X.
* - Apple was a pain in the ass sometimes. For a company with such great PR, they really were very unprofessional and treated developers poorly. I know that the OS X transition was tough, but there are so many stories I could tell of stupidity at Apple and policies which made no sense...but I won't. I'll just say that Apple had a lot more involvement in the development of Mac IE and it's eventual end than Jorg ["jbx"] gives them credit for. There were times during the last two years of working at Microsoft that I really hated Apple's management...which was very difficult for me being such a loyal fan of their products and having so many friends who worked there.
* - No clear direction from our management was the last major factor which Jorg touched upon but is important to mention again. Towards the end, we had some major changes in management at the MacBU and the new team was inexperienced both with the products they were managing and how to deal with Apple. They were further handicapped by lack of clear direction by our execs who were too busy worrying about AOL, the DOJ, and our stock price.
Anyway, enough about the history. Mac IE is dead, and it's up to Apple and the Mozilla team to continue to innovate for us Mac users. Sadly, there are still many very useful features in Mac IE that neither company has replicated in their browsers and there are still too many sites which don't look right in Safari. I remember calling up CNN and ESPN and getting them to fix problems in their websites...it worked and I hope Apple has a group of people doing the same thing.
Since Microsoft will no longer be offering Mac IE 5 for download on their website, I'm going to provide a community service by linking to it here. It has not been totally replaced and at least I need a place to be able to download it from for my own personal use...but you'll have to know what to click on to download it.;-)
If you ever want to know who the people behind Mac IE 5 were, just type "about:tasman" in the address bar of Mac IE and you'll get a list of the people who put their heart and soul into making it such a remarkable and successful product.
I have to laugh (and cry) a bit at Jimmy's comment concerning Apple's management. Apple has screwed over developers time and time again, even while at the same time giving them lots of lip service and spending lots of time and money on developer programs. The tip of the iceberg: no Mac program written prior to 1999 will run - at all - on the new Intel-based Macs. In fact, most 2001 programs won't either. (By contrast, many 1984 apps *do* run on today's machines) More to the point: A Mac developer from 1998 who was 100% up-to-date on Apple's technologies will find today that those technologies have all been either deprecated (in favor of Cocoa or Intel) or outright eliminated (intelligent memory management through Handles, trap-patching, MixedMode expertise). It's all part of Steve Jobs' "they have no respect for the status quo" - a nice quote until you discover yourself at the receiving end of it.
I was on the MacIE 6 team when it got canned...
on
Microsoft Ends IE for Mac
·
· Score: 5, Interesting
MacIE had one of the strangest and saddest histories I've seen, of any product.
MacIE 5 was an awesome release, critically aclaimed and everything, with a good development team and a strong testing team, that included daily performance measurement.
And yet, almost immediately after 5.0 was released, the MacIE team was redeployed to work on a set-top DVR box. The notion at the time was that the team would continue to do MacIE work in their spare time, since IE 5 was the leader among Mac browsers and no longer needed a full-time team.
The problem with that notion was that WebTV, the team's new bosses, had no reason to actually schedule any time for real IE work. So later, when that particular set-top box got cancelled, the IE team got redployed for other WebTV work, and since this was now out of MacBU's control, nothing could really be done.
3 or 4 years went by before enough people in the Mac division wanted to resume work on IE, and when it looked like we might actually need the technology, as a base for MSN-for-Mac, the IE 6 team was formed. It got a firm OS X-only foundation, a new even more complient browser base, and then suddenly it became apparent that Apple was doing their own browser, because, well, there were lots of small clues, but the big clues was that Apple had started calling the old Mac IE team offering them jobs.
By that time the Mac division had formally committed to MSN-for-Mac-OSX, so it's not like we were completely going to stop work. But a meeting was held internally, the outcome of which was that it didn't make sense to build our own browser if Apple was going to bundle one, because the marketshare and mindshare of the distant-second-place browser, on the distant-second-place platform, wasn't worth pursuing. A week later we had a meeting with high-up people at Apple, where they told us they were doing a browser. And the week after that, after confirming it with Bill Gates, who was reportedly sad but understanding of the decision, MacIE was officially shut down.
MSN-for-MacOSX went ahead, and was also critically acclaimed, but once released, indications were that the number of users was about the same as the number of developers. After that, MacBU concentrated once again on the next Office release, and MacIE has been well and truly and permanently dead ever since.
Over the whole sad journey, the single most surprising thing I ever discovered was from a small conversation that went:
Me: "Look, if it makes sense to devote dozens of people to WinIE, then surely it makes sense to devote half a dozen to MacIE!"
Higher-up: <confused look> "There aren't dozens of people on WinIE. WinIE had some great people on it! We need those great people on products that make money!"
Me: "Then why on earth did we pursue IE in the first place? Just so that the DOJ would sue us?"
Higher-up: <confused look>
Some day I hope to get a proper answer on our motivation to do WinIE and MacIE in the first place. It seems to be that we were scared of not having control of the HTML standard. And indeed, now that Firefox is gaining traction, Microsoft has added more people to WinIE again.
Epilogue: All of this made it a lot more easy for me to quit and go work at Google Reminder: I may or may not be leaving some parts out for NDA reasons.
... because every time I profile my code, it seems I end up spending a lot of time in my bubble sorts. In all that code, surely someone took the time to write a really fast bubble sort, right?
Why, this reminds me of something I saw the other day on a blog: "Certain bloggers, fed up of seeing their work just lifted by the mainstream press, have created The Press Plagiarist Of The Year award. Examples are given of national newspapers simply cutting and pasting entire articles from web sites and passing them off as their own."
But all of Google execs *are* programmers!
on
The Google Caste System
·
· Score: 2, Insightful
> The executives and managers are still in control of the company's future, > regardless of what the programmers, DB admins, and the like want to believe.
Your statement assumes some sort of line between non-engineer execs and non-exec engineers. But there *are* no non-engineer execs. Heck, as far as I can tell, there aren't even any non-engineers PMs! Know why that is?
The exec team spends a fair amount of time thinking about, "how can we lose this" / "how does this all go wrong"? One example they cite is Apple, which was great, lost it, and is only recently getting great again... and one big problem they point out is that for a while Apple had no engineers at board level! (Remember when Sally Ride was on the board of directors at Apple??)
The lesson is clear: when you have engineers everywhere, no one at the bottom or mid level can pull the wool over your eyes. The moment you start saying "A good manager doesn't have to be an engineer", you forget that a non-engineer manager can be fooled by an incompetent engineer who "manages up well", and then things start to sink.
The troika that rules Google, Sergey, Larry, Eric: they can all code. If that over stops being the case, that's probably an early signal to sell the stock!
Slashdot Mirror
... we disected a mouse brain, and there, in little tiny letters, was:
What do you get if you multiply 6 by 9?
But the teacher just muttered something about base 13, and told us to ignore it.
This whole thing is stupid. The time you save by going from Qwerty to Dvorak is always going to be tiny compared to the time you lost in the first place by learning the Qwerty layout when you already knew the alphabetical layout.
Keyboards should arrive in alphabetic layout - either ABCDEFGHIJ across the top, KLMNOPQRS in the middle, and TUVWXYZ on the bottom, or ADGJMPSVXZ across the top with BEHKNQTWY in the middle and CFILORU on the bottom. Either way would make it dramatically faster for new computer users / typists.
For the 0.5% of the computer users who would gain productivity by switching to something faster, they can go the Dvorak route, or anything they choose. For the rest of us, the right thing to optimize is the initial learning curve.
Alternately, if we could just change the ABC song so it goes, "QWERT, YUIOPAS. DFG, HJK, LZXCVBNM. No I know my QW, next time won't I sing with U", then that would also lessen the learning curve, without making all those Qwerty keyboards obsolete...
Man, I was looking forward to being able to actually walk into a store and not have them be sold out of Wii, or maybe even have a Wii at a discount... and now this. Great. Thanks a lot, pro-family church nazis.
Even if DCA can't be patented, the use of DCA in combination with some other drug *can* be patented. Enforcement might be an issue, but if the results of DCA in combination with something else are even better than DCA by itself, this is something the drug companies would pursue.
As a side note, DCA is described as "relatively non-toxic". Ummmm.... relatively?? As Venkman said, could we clarify that? I'm a little unclear on the whole non-toxic/relatively non-toxic thing.
> 20% of time working on personal projects
>
> Fine, but if you're working in a smaller, less demanding
> company, you might have that time free, so you can work
> on the projects without the company knowing about it.
On company time?
The great thing about Google 20% time is Google is aware of it and sponsors it. So when my 20% time project got big enough that I couldn't run it as a process on my desk anymore, they set up a machine (complete with an SRE to watch over it) on a rack somewhere to run my project. And then another. Now I work on it more than half the time, and if it goes where I hope it will, I'll be recruiting a team for it soon. That doesn't happen at most small companies, where your project is generally seen as a distraction from the few things that the company desperately needs, in order stay in business.
You do remember that Google's CEO, Eric Schmidt, recently joined Apple's board, right?
And you do remember Google's place in Steve Jobs' commencement speech at Stanford? And I quote:
When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.
> You have sources for any of those suppositions?
x ?type=technology&storyid=nN07296137&imageid=&cap=
Don't you remember this story about the infamous PowerPoint presentation?
http://today.reuters.com/news/articlebusiness.asp
And I quote:
> Copies of the notes were captured by a handful of bloggers and
> shared around the Web. The company subsequently took down its
> original PowerPoint slide presentation and replaced it with a
> 94-page Adobe Acrobat file, devoid of the speaker notes.
Also, to be fair, adoption of writely is picking up very quickly, mostly because it does something Word can't do: put a shared document somewhere where a lot of people can simultaneously make edits to it, without the horrid wiki interfaces. And most text is composed within e-mail apps, not a word processor. And why would you use Word for anything that is predominantly straight text, for which HTML does very nicely? I guess what I'm saying is, word processing, which was the first "killer app" for personal computers, isn't so killer anymore. And, of course, not everyone has a Windows machine, since the default for most Googlers is a Linux box, and usually it's your laptop that runs Windows - though only if you opt for a Windows machine instead of a PowerBook.
But, you know, other than that.... If you have a Windows box, AND you don't need to collaborate with your document, or share it through a predominantly HTML medium, AND it's not so simple that you could do it with HTML and <B>, <I>, and <U> tags, then, you know, definitely you would reach for Word, and not OpenOffice or Adobe Arcobat. ("Other than that, Mrs. Lincoln... how'd you like the play?"... Sigh.)
jbx
ps Just as a sidenote, I worked at MacBU within Microsoft, and our shipping bonus for Mac Office 2004 was an iPod. Only a few months later, the fuss about Microsoft employees using iPods erupted; I almost made T-Shirts that said "Microsoft gave me my iPod"!
Nearly anyone at Google who wants to write a long document uses Word. If they want to work on a spreadsheet, they launch Excel. And a presentation? PowerPoint.
And the predominant Google laptop? An IBM ThinkPad running Windows, with Office pre-installed.
> I'd say one of the mail problems with GMail is the fact that their outbound SMTP relayers
> are off-and-on listed in the dnsbl.sorbs.net blackhole. This means mail you send out may
> get blocked by receiving servers that check this blackhole.
>
> I'm regularly getting these kinds of messages when I send out mail and that really sucks:
>
> PERM_FAILURE: SMTP Error (state 9): 554 Service unavailable; Client host [64.233.166.180]
> blocked using dnsbl.sorbs.net; Spam Received See: http://www.sorbs.net/lookup.shtml?64.233.166.180
How is that a problem with GMail? Seems to me it's a problem with sorbs.
sorbs has suggested to GMail that GMail should expose the IP address from which the message originated; that way sorbs could block by real IP instead of GMail's mailing agent's IP. GMail has responded that to expose the IP of the sender would violate the privacy of the sender. sorbs responds, basically, "well, IP address is how we work. If you only give us one IP address to work with, that's the one we list as blackholed." And so they list the GMail outbound IP addresses as blocked.
More saliently, sorbs says:
sorbs does NOT block email, websites or the Internet.
sorbs is NOT CAPABLE of blocking email, websites or the Internet.
What you need to do is contact the mail server that (after communicating with sorbs) decided to block your mail. The only way sorbs will ever change their policy of "you must violate the privacy of your users or we will block your mail" is of enough of their users complain about it.
> "Each app runs as a virtual Mac, with the OS acting to stitch together the virtualizations."
>
> ACK! He says, mentally running through the point of contacts with the hardware, events, file system,
> networking, windowing, interapplication communication, scripting, clipboard. Yeah, you could do it,
> and in fact, they did do it with Rhapsody's Blue Box "Classic" mode, but you'd practically have to
> write an entire OS to put beneath it... which, from a certain perspective, is what they did.
Yes, my point exactly: they had to do this in order to handle the "Classic" mode anyway. But instead of putting in a shim that the ClassicOS talks to, they should have put in a shim that the ClassicOS *apps* talk to.
And given that a lot of the performance issues under Carbon in OS X don't happen under Classic, they probably could have avoided them in a "MultiClassic" environment too.
Ah well. Looks like the spirit of killing pre-OS X technologies lived long enough to kill Classic on the Intel Macs, so I think it'll only get harder to actually ever make something like this happen.
> As to OS X'isms, and speaking as someone who did Apple/Lisa/Mac development in 77/83/84
Wow, you did Lisa development? Man, I'd love to see a Virtual Lisa, to show people who believe that the Mac started it all. (I always hated that Apple was so tight on its restrictions as to who was allowed to develop for Lisa.)
> "Apple's development organization became convinced that to truly take the machine
> forward, they would require a totally new OS."
>
> That's true. But a good portion of that reasoning lay in the fact that to get to
> preemptive you needed to rewrite the kernel, event manager, memory manager, file
> manager, good portions of quickdraw and the graphics engine, device drivers, etc.,
> to make them reentrant. So, by the time you've done that you've rewritten practically
> the entire OS, and then the real question becomes: do we want to do all of that work,
> only to fundamentally end up back where we started? And can we even do that without
> breaking half the applications out there that depend on some obscure bit of
> functionality or behavior?
Ah, now we're getting somewhere. I think that's roughly the reasoning they followed - since we have to rewrite it anyway, why not *really* rewrite it?
The answer is pretty simple: because there's a lot of good stuff in what had been written - for example, a graphics engine that had been written at a very low level to run efficiently on very slow hardware. (Consider that on the original Mac, menus were drawn on-demand, as the user interacted with them. Same on Windows. But on OS X it's so slow to draw the menus that they have to draw them in advance and cache the resultant bitmaps) And the flipside is there, too: there's no guarantee that the new design you come up with won't have its own fundamental flaws and shortcomings. It's a choice between the beast you know and the beast you create. In my experience it's easier to fix the beast you know. (At least, as long as the beast you know has as many good points as Mac OS had.)
The insight that no one ever had was that rather than fix it from the inside, you could treat the whole thing as a virtualization and fix it from the outside: Each app runs as a virtual Mac, with the OS acting to stitch together the virtualizations. That is to say, imagine multiple copies of Classic running alongside each other. Each is memory-protected from the other; each can crash horribly and not affect the rest of the OS. Each can be pre-emptively scheduled against the other. If you approach the problem from that direction, the need to re-write everything disappears. Of course, it would still be a lot of work; the file manager and device manager would have to be stubbed out and put in a central place for example. But it would be a lot less work than a complete rewrite. A lot of the work to stub out the file system was done already for A/UX, Apple's first attempt at a Unix-based Mac, and just needed to be carried over.
> "The car you drive is a series of incremental improvement..."
>
> I don't think you want to go down that road, because if you do, we can start talking
> about the decades of incremental improvements that have gone ito Unix, BSD and Mach.
> (grin)
To the contrary; I think that's an excellent point. If I were a user of BSD, I would look at OS X and be quite happy with what Apple's done with it - preserving the good parts of BSD while adding a lot of extra value. Heck - you can even boot a Mac in single-user mode with no GUI if you want to! If only the experience for old Mac people could have been as positive, or had a similar way to turn the new OS X-isms off!
> For all practical purposes it was B&W unless you were printing, and even then you had to
... but it's just not a
> jump through hoops. To get color onscreen we needed the nearly complete rewrite that was
> Color Quickdraw on the Mac II.
Yes. But you know what? That didn't require a ground-up rewrite. And they added a lot more than color: support for multiple screens and support for third-party graphics cards, for example. And if you wanted run the screen in black-and-white, you could still do it - something you can't do in OS X.
> "The overhead of swapping out a hundred low-level globals
> factor these days."
>
> Right. Because when you're switching application contexts a thousand times a second you
> really want to waste time moving hundreds of discontinuous memory locations. Heck, these
> days just swapping out the stack is a performance hit that has systems designers gnashing
> their teeth.
I wish more of those systems designers worked at Apple.
hundreds of discontinuous memory locations... OK, let's say 100 4-byte values plus 100 2-byte values. That's 600 bytes.
Now let's look at the bare minimum of what a PowerPC has to swap: 32 32-bit registers plus 32 64-bit floating-point registers plus 32 128-bit AltiVec registers, plus the 32-bit PC and 32-bit condition-code register. That's 32 * (4+8+16) + 32 + 32, or 960 bytes.
You remind me of the folks who used to complain about Apple's "Ticks" low-mem global, which kept track of how many 60ths of a second had elapsed since system startup. They complained because it wasn't aligned on a 4-byte boundary - yet it was accessed so often - read and written to!
The reality is, it just doesn't take that much longer to increment a mis-aligned longword. On later PowerPCs it makes absolutely no difference, in fact.
By contrast under OS X, if you want to read the value of Ticks, you have to call TickCount(). But under OS X, that first makes a call which determines the number of microseconds since start, turns that into a floating-point variable, and then turns it back into an integer. Old OS X programs (like Metrowerks CodeWarrior) called TickCount() a lot to see if enough time had elapsed to check for user interaction; those programs had to be re-written because suddenly the call to TickCount() was a bottleneck!!!
> And we still had an entire cottage industry devoted to memory managers and debuggers
> that tried to track down the bugs that system encouraged.
I believe there is still a cottage industry for memory managers and debuggers on Windows and Linux. No?
> If "rewriting" a few parts of the system were that easy they would have down it.
Now you're hitting on the true problem. This ceased to be true after System 7 shipped. Apple's development organization became convinced that to truly take the machine forward, they would require a totally new OS. So a small group of people continued to maintain System 7, while the "real" work went into Pink, which became Taligent. And when that failed, into Copland. And when that failed, into OS X. And OS X shipped way, way, way late.
Time and time again, Apple's large teams, working on the "next big thing", failed, while the small group of people (Blue Meanies et al) working on 7.x, 8.x, and 9.x were actually delivering the incremental improvements that people needed. Had Apple put together a small team to "hack on" memory protection into System 7, it would have been done long ago. But Apple's management preferred to build empires of superteams working on a new revolutionary OS, so they could say, "I lead a team of 200 programmers".
"the original MacOS was a great acheivement. So was the Model-T. Today, I refuse to drive either one."
The car you drive is a series of incremental improvements on the Model-T. Even after all these years, the basic design laid down back then is the one we still use: conveyor-belt-style assembly of a car wi
> This is highly unlikely. HLock originally only ever set a flag. It now doesn't even need
> to do that, since a Handle never moves under OS X, but if it did, it still would only
> need to set a flag. Even allowing the overhead of calling through a shim into Carbon
> this wouldn't amount to a huge call. There may be other APIs that do exhibit the
> behaviour you mention, but this was a very bad example to pick.
I can't tell if you're clueless to the horrible Carbon implementation under OS X, or just baiting me.
I was one of the people involved in the port of Mac Office to OS X, at Microsoft, during 2001/2002. My particular job was to make Entourage perform fast under X, and one of the things that repeatedly came up when running Apple's sampling profiler tools was time spent inside HLock/HUnlock. Apple's answer, rather than making HLock/HUnlock faster, was "just remove your calls to HLock and HUnlock, since they don't do anything anyway."
Unfortunately the code in question came from a third-party text rendering engine, and the locked-or-not state of handles was actually important, so I couldn't just get rid of the calls. But the time I spent reducing the frequency of them being called made things much faster.
Later on I talked with the author of iTunes about this, and he remarked that he was able to just #define away his HLock/HUnlock calls, for OS X iTunes. (OS 9 iTunes still needed them, of course) He said it made the app smaller, and about 10% faster.
"it was also written from the ground up to be B&W, single-threaded, single-tasking, use fixed-size memory spaces, and totally without any form of internal or user-based security."
Incorrect. It was designed to allow 3-bit color, actually - the quickdraw headers defined 8 colors, not two.
"Or are you saying a modern OS should swap out hundreds of shared low-level global variables on every context switch?"
The overhead of swapping out a hundred low-level globals in 2006 is, oh, about a hundred cycles. Oops: swap, so 200. Whoop-de-doo. People complained about that when a lot of the user base still had 68000-base machines running at 8MHz, but it's just not a factor these days. Even so, you could re-write OS 9 not to have so many globals without the extensive re-write that was OS X.
"why should a modern OS have a handle-based non-protected fixed-patition-sized memory system, itself probably responsible for half the memory allocation/corruption bugs and crashes in any given Mac application."
Oh, so the OS causes your app to crash? I could respond that multi-threading causes so many hard-to-understand bugs that it's responsible for half the crashes, but I'm against the shirking of responsibility.
As for Handle-based, Handles allowed programmers to write programs that were nearly 100% efficient in their use of memory - albeit at the expense of slow compactions from time to time. Not so far removed from Java, actually, though without the benefit of automatic garbage collection. The OS X equivalent - to just use Ptr-based memory instead, and swap a lot, is one of the reasons OS X requires a lot more RAM than OS 9 does. (Well, it doesn't actually need the RAM; but you'll swap a lot without it.)
"Perhaps you can explain why the system resource and process-slicing allocation kernal of a modern OS needs to be "graphical" from the ground up? Or conversely, why graphics, networking, file management, and other subsystems should not be layered on top of a rock-solid base?"
The system resource, process-slicing kernel of the OS doesn't need to be graphical. And indeed the nanokernel inside PowerPC Macs was not. But layering graphics APIs on top of file-based IPC mechanisms introduces dramatic inefficiencies. Networking and file management had a pretty solid base under OS 9, just not a fast one. (file access is one of the few things where OS X is notably and dramatically faster, incidentally - e-mail database rebuilds are about 2x faster under OS X.)
OK, first off, you're right that OS 9 and its predecessors didn't have memory protection or full SMP support. But adding these things doesn't involve the amount of memory bloat or performance reduction that OS X has. I added memory protection as a feature for Jasik's Debugger back in '90 - even going so far as using the MMU to be able to prevent an application from reading from the first 4K - that is, dereferencing a NULL pointer - and that was just a hack that took about 2 months of time. There's no doubt in my mind that people who had real access to the sources for the OS, and a real amount of time, could do much better.
SMP is a hell of a lot trickier, especially given Apple's graphics architecture and its penchant for global variables... but Apple was a lot further along this path than people realize. And they would have gotten even further, except that Steve/Avi started blocking development of OS 9 APIs.
And yes, OS X is way, way more reliable. Any time I go back to OS 9, and am forced to reboot due to a crash, I ponder why on earth we Mac users lived with this for all those years.
But the 'everything is a file' mantra... Uggh. This, and the idea of seperating different parts of the OS into different processes, is a big part of the problem. On the original Mac, you say "MoveTo(10,10);" to move the pen, and it does a couple if dispatches, stores the new values of x and y, and returns. Under OS X, this involves... oh hell, frankly I have no idea because you can't just step into another process and follow the work. I'm relatively certain it involves dispatching a message to another process. What I really want to do is write a small benchmark and use Shark to tell you where the time is being spent - it would be very illustrative... LineTo would be an even better example, because under OS 9, it could actually be graphically accelerated to draw the line. Under OS X, the line is drawn to an off-screen buffer first. Then a custom region of "dirty bits" is updated so that, later down the line, the blit that copies the off-screen bits onscreen can copy only the bits of the actual line to the screen. Even ScrollBits, which was perfect for acceleration under 9, is performed by the CPU under X, with the GPU doing only the bitcopy from main RAM to graphics RAM.
You say a modern OS "needs to do more work". Sure, but not the absurd amount of work that OS X actually does.
As for HLock, OS X doesn't need to do any more work. newsflash: under OS X the only thing this call needs to do is set a bit so that future callers of HGetState get the bit back. It doesn't need to go to a seperate process, doesn't need to deal with MP. And unlike OS 9, it doesn't need to deal with ROM handles or 24-bit heaps. It could be implemented in two instructions if they were willing to allow a little memory wastage, or about ten if they didn't. Or they could hire bozos and implement it as a dictionary-of-locked handles, which seems to be what they did, given its slow perf.
Look, let me put it another way: run OS 9 under OS X through the Classic emulation layer. Then write a program which does nothing but open a window and draw a bunch of stuff, maybe call HLock a few hundred times. Then time the exact same thing as a "native" OS X app. Then explain to me why the OS 9 version was so much faster.
(Annoyingly, I'm writing this on my personal Mac, which is Intel-based, and Apple's upgrade of my old machine neglected to copy any of the built-in dev tools to the new Mac, so I can't report real numbers to make my case. Or run Classic anymore - Grrrr.)
You are right that the switch to OS X was brave. well-conceived? Maybe. Well executed? No way.
For all the talk about the speed of OS X, Apple has never addressed the most obvious issue: on a machine that can run either OS 9 or OS X, OS 9 is very much faster. They took an OS written from the ground up in the early 80s to be graphical, and replaced it with an OS written the 70s to be textual, with the GUI glued on top of it.
And then even worse, the people who wrote Carbon, the MacOS backward-compatibility layer, had no idea how to write it to be fast - simple calls like HLock which used to be two instructions on the original 128K Mac are now thousands of cycles under OS X. (And Apple's answer to this? "Remove your HLock calls; they don't do anything anyway.")
Don't get me wrong; they've done great things, given what they started with. But they threw out the baby with the bathwater when they ditched MacOS.
I'm not so sure about that. Deleting your account is more serious than just emptying your trash; I believe that in some European juridictions, there are strong privacy laws that mandate that Google/Yahoo/Hotmail/whoever really will delete your account if you tell them to. (Within 3 days, if I recall correctly.)
This is just the beginning. If this stands (and is not overruled by a higher court), then soon the government will have the right to run "undelete" on your hard drive looking for things, or go searching through your trash and your shredder looking for evidence!!
What's that? They already do?
<emily litella>Never mind.</emily>
You don't think there are privacy concerns?
Have you ever typed an address into Google? I do it a fair amount, because it's easier to type the address into the Google searchbox of Firefox, and then click the map button, than to first type "maps.google.com" and then type the address.
So there's lots of addresses in the search logs. Not just IP addresses - I mean real addresses.
Also, a lot of people type in their own credit card numbers. It's an easy way to be sure your credit card is not on the internet: just type it into Google. No hits, no worries.
People also type UPS/FedEx tracking numbers. And telephone numbers. Some search for their own SS# to be sure some idiot hasn't leaked it. And never for a second do any of these people think, "the government is going to take my search and put it into a big list of things people searched for".
Also, I Am Not A Lawyer, but wouldn't the results of this subpoena become public record?
> Then send your kids to private parochial (or other such) school.
Yeah, sure, if I could afford it.
Maybe if the government would give me the $9,000 per year (or whatever it is these days) that they would have to spend on my child's education, if I left them in public school, then I could afford to send my child to private school. As it is, they tax me enough for private school, then refuse to let that money go to my child's education - unless of course I send my child to one of *their* schools.
Anyway, this fight isn't about "mythology". This fight is about preventing the government from teaching my kids that all scientists believe that humans came about through random evolution from lower species. And when the bible-thumpers try to add even the smallest disclaimer, like beginning the evolution teaching with "by the way, this is only a theory, and it's not the only commonly-accepted theory, either", all hell breaks loose.
The government wants to take my money from me and use it to teach my children that religion is wrong about the origin of our species. That is *not* seperation of church and state - that is state-sponsored atheism.
http://www.jimmygrewal.com/?p=187
I have to laugh (and cry) a bit at Jimmy's comment concerning Apple's management. Apple has screwed over developers time and time again, even while at the same time giving them lots of lip service and spending lots of time and money on developer programs. The tip of the iceberg: no Mac program written prior to 1999 will run - at all - on the new Intel-based Macs. In fact, most 2001 programs won't either. (By contrast, many 1984 apps *do* run on today's machines) More to the point: A Mac developer from 1998 who was 100% up-to-date on Apple's technologies will find today that those technologies have all been either deprecated (in favor of Cocoa or Intel) or outright eliminated (intelligent memory management through Handles, trap-patching, MixedMode expertise). It's all part of Steve Jobs' "they have no respect for the status quo" - a nice quote until you discover yourself at the receiving end of it.
MacIE had one of the strangest and saddest histories I've seen, of any product.
MacIE 5 was an awesome release, critically aclaimed and everything, with a good development team and a strong testing team, that included daily performance measurement.
And yet, almost immediately after 5.0 was released, the MacIE team was redeployed to work on a set-top DVR box. The notion at the time was that the team would continue to do MacIE work in their spare time, since IE 5 was the leader among Mac browsers and no longer needed a full-time team.
The problem with that notion was that WebTV, the team's new bosses, had no reason to actually schedule any time for real IE work. So later, when that particular set-top box got cancelled, the IE team got redployed for other WebTV work, and since this was now out of MacBU's control, nothing could really be done.
3 or 4 years went by before enough people in the Mac division wanted to resume work on IE, and when it looked like we might actually need the technology, as a base for MSN-for-Mac, the IE 6 team was formed. It got a firm OS X-only foundation, a new even more complient browser base, and then suddenly it became apparent that Apple was doing their own browser, because, well, there were lots of small clues, but the big clues was that Apple had started calling the old Mac IE team offering them jobs.
By that time the Mac division had formally committed to MSN-for-Mac-OSX, so it's not like we were completely going to stop work. But a meeting was held internally, the outcome of which was that it didn't make sense to build our own browser if Apple was going to bundle one, because the marketshare and mindshare of the distant-second-place browser, on the distant-second-place platform, wasn't worth pursuing. A week later we had a meeting with high-up people at Apple, where they told us they were doing a browser. And the week after that, after confirming it with Bill Gates, who was reportedly sad but understanding of the decision, MacIE was officially shut down.
MSN-for-MacOSX went ahead, and was also critically acclaimed, but once released, indications were that the number of users was about the same as the number of developers. After that, MacBU concentrated once again on the next Office release, and MacIE has been well and truly and permanently dead ever since.
Over the whole sad journey, the single most surprising thing I ever discovered was from a small conversation that went:
Me: "Look, if it makes sense to devote dozens of people to WinIE, then surely it makes sense to devote half a dozen to MacIE!"
Higher-up: <confused look> "There aren't dozens of people on WinIE. WinIE had some great people on it! We need those great people on products that make money!"
Me: "Then why on earth did we pursue IE in the first place? Just so that the DOJ would sue us?"
Higher-up: <confused look>
Some day I hope to get a proper answer on our motivation to do WinIE and MacIE in the first place. It seems to be that we were scared of not having control of the HTML standard. And indeed, now that Firefox is gaining traction, Microsoft has added more people to WinIE again.
Epilogue: All of this made it a lot more easy for me to quit and go work at Google
Reminder: I may or may not be leaving some parts out for NDA reasons.
... because every time I profile my code, it seems I end up spending a lot of time in my bubble sorts. In all that code, surely someone took the time to write a really fast bubble sort, right?
Why, this reminds me of something I saw the other day on a blog: "Certain bloggers, fed up of seeing their work just lifted by the mainstream press, have created The Press Plagiarist Of The Year award. Examples are given of national newspapers simply cutting and pasting entire articles from web sites and passing them off as their own."
> The executives and managers are still in control of the company's future,
> regardless of what the programmers, DB admins, and the like want to believe.
Your statement assumes some sort of line between non-engineer execs and non-exec engineers. But there *are* no non-engineer execs. Heck, as far as I can tell, there aren't even any non-engineers PMs! Know why that is?
The exec team spends a fair amount of time thinking about, "how can we lose this" / "how does this all go wrong"? One example they cite is Apple, which was great, lost it, and is only recently getting great again... and one big problem they point out is that for a while Apple had no engineers at board level! (Remember when Sally Ride was on the board of directors at Apple??)
The lesson is clear: when you have engineers everywhere, no one at the bottom or mid level can pull the wool over your eyes. The moment you start saying "A good manager doesn't have to be an engineer", you forget that a non-engineer manager can be fooled by an incompetent engineer who "manages up well", and then things start to sink.
The troika that rules Google, Sergey, Larry, Eric: they can all code. If that over stops being the case, that's probably an early signal to sell the stock!