Excuse my Bios, but...

Check out the Phoenix Technologies announcement on their BIOS hardware authentication scheme.

People like Bruce Schneier lecture us all on how hard it is to create a trusted network verification model that holds up under a variety of conditions and needs. And who needs this (very few)?

Some of you may recall how Microsoft had to pull back on their extra evil hardware authentication when it turned out XP didn't work when you added a device like a DVD. Everybody complained, vendors got really annoyed with customer support, and Microsoft got blamed (well, it was their fault). They're trying to moderate this in practice, but it's not a deterministic strategy for a host of technical and practical reasons.

But Microsoft has an OS monopoly and can get away with failure. Does Phoenix have a monopoly on the BIOS? Don't think so. The customer hates this process of verification - it makes him feel like a criminal. So the vendor notices the customer hates the product, buys another BIOS from AMI or any of the hundreds of others, gets rid of this nonsense for the customer, and the problem is self-correcting.

And now Phoenix is going to disallow network access from people who don't match this same faulty hardware profile? Great - it didn't work before, so let's make it even bigger this time. Sounds like lunacy? It is. Phoenix has been trying this trick for years and years - and it won't work unless you keep people from upgrading / fixing their PCs.

Can you imagine how people would react if you told them they couldn't change the oil filter on their cars, or take it to the local oil changers and buy a standard filter? You'd have to throw the car away - sorry Charlie.

As the real security guys will tell you, verification of trusted networked sources is actually a very difficult game, even using hardware and secure links. You fool yourself into believing that you can live in a black and white universe. In reality, with security this brings more problems, because too narrow a window results, so exceptions are made to the rules and soon you're back to the same corner case issues as before. The real success comes down to knowing the character of the individuals and the use / practice of measures, such as the friend/foe rules of engagement process used in the military.

The last thing everyone needs is an Internet where people are refused access for arbitrary reasons, subverting the entire point of TCP/IP and networked communications - to exchange information - by preying on people's fears of the "bad guys" gaining access. Maybe if Microsoft would just secure their OS better, we wouldn't have this fear in the first place.

Now that I've pointed out the problem from the perspective of an Internet expert, we could all use a crafty rebuttal from a security expert as to why this is just another brand of snake oil. Hey Bruce, where are you?

If You Can't Beat Them, Go Lower

I remember when Linux was just gearing up, and many of the Sun people (who started with BSD, remember SunOS?) mocked them. I heard about what a lousy architecture it was (yes, that's true, but what did it matter to someone who got something working for nothing?), that it wasn't good enough for enterprise (well I've seen a lot of enterprise crap over the years, so that doesn't wash), and that you'd never get it working or supported (seems that isn't true either from the look of things).

The problem with smart people is that they can easily come up with a lot of good-sounding excuses when they don't want to see it like it is, and what it is right now is that people don't want to pay for free software - and I suppose that's why it's called "free". This hits Sun pretty hard, since they built a pretty nice OS and want to get people to show their appreciation by actually paying for it. So it looks like Sun is taking a page from the Microsoft playbook (you know, "open source is evil, expensive, evil, and did we mention evil") with today's announcement.

The jist is simple - Sun will sell Solaris to freebie OS users by "tout[ing] their aggressive move into an area dominated by vendors that sell systems running so-called commodity chips and low-cost Linux software." Now, admittedy, they're trying to target Red Hat, but does anyone really believe that most Linux users pay for Linux from Red Hat? Not if you look at Red Hat's financials, where they have to give most of it away to get worried commercial customers to buy service contracts - which is a respectable, if not blockbuster, business.

So where do Microsoft and Sun go when their customers are using stuff for free? Well, they go lower. And lower. And lower. Fortunately, unlike Microsoft, they claim in a Sally Field moment that they really love Linux, they really do: "We are very much a good citizen of the community and love the Linux community," said Anil Gadre, Sun's chief marketing officer. "But we believe we have a superior product offering from a performance, stability, security and price advantage standpoint compared to the brand of Linux called Red Hat."

Perhaps they are still "superior" - as a colleague I have great respect for the kernel side of the business and some of the work they've done - but in a WalMart world, is "superior" better than "free" anymore?

Video on Demand over TCP and Jitter

A recent question to me from a "born back bencher" eavesdropping on the end-to-end groups musings asked "...how they can even believe they can accomplish a good result with TCP for VOD [Video On Demand]? Yeah they gave me good on SACK and NACK and no matter how many RFCs and drafts they quote, which I have never read, the logic still seems obtuse if the window is end to end". Actually, this isn't a silly question - it's a good one in that we need to examine our environment and definitions carefully and has a lot of richness. Just what a physicist loves!

VOD isn't just TCP, although end-to-end quality is very much based on how the customer perceives the stream (if you're truly streaming). If you're transiting through wireless, all bets are off - no one does good work in this area (yet) as I discuss in Buffer, Buffer, Where is the Buffer? on Byte.

But to get to the gestalt, in a video quality study I conducted several years ago we found you had to deal with VOD at several levels, from production of video for the Internet to TCP streaming optimization - in this case we used InterProphet's SiliconTCP here at the datacenter as well as client end (see SiliconTCP, EtherSAN, and Scalability). It's really the big pipe / little pipe problem at the customer end that's the bigger issue here - but we're now in Internet infrastructure land, and that's a hard-fought area. But in all cases, jitter is the key!

Why jitter for video? Well, the answer falls out of some work we did on making very small packets (ATM cell-like) work as efficiently as ATM with better cost-benefits for telecom. Turns out true VOD demands are equally significant. Of course, now we get to some interesting crossroads, such as whether you are concerned about quality and VOD over TCP because you are trying to stream videos for sale as a content provider? Or are you wanting to develop a video distribution business? Or are you trying to develop the Internet infrastructure necessary for the performance and outcompete the Cisco's of the world? They're really very different businesses, and have different cost structures. Now it's what you're willing to pay for.

Do not fall back on the chimera of UDP as an "easier solution". Everyone likes to fall back to creating their own layer4 on top of layer3. They don't rely on the scaling of what's already in place on the network to gracefully handle TCP, so they lose scalability. To buy back some of that scalability deficit, they often try to do a "more efficient" job by cutting out key elements of TCP (such as checksumming and windowing), only to find it works inefficiently and breaks for others. As Rocky says to Bullwinkle "That trick never works". TCP has been shown to be superior as a VOD protocol going head-to-head with UDP for many years. It's an old argument that never panned out.

So if TCP is really is good enough as a protocol, why do we have problems with VOD. It's not the protocol itself - it's the complexity that magnifies the problem. The Internet isn't just two tin cans and a string - it's a interconnected network of networks. To maintain end-to-end semantics, one has to find a way so that the semantics are preserved throughout the sytem. Simplistically, this means we only crack, assemble, and checksum at the end-points. We've always done this.

However, we could use the same mechanism throughout the Internet itself, using a form of divide and conquer. In this manner, we view the Internet today as if it was composed of smaller portions, each independently solved, so the problem of jitter, complexity, and overhead is mitigated. In other words, we're back to scaling, and high to low capacity at the edge causes the congestion.

But why is production important if we're talking about jitter? In both video and audio, if you're doing near realtime (so to speak) the problems are easily seen by the end viewer, but the problems induced by this can't be easily remedied. That's why production is so important as the first step if you're a content provider. You've got that much control in terms of tech - understanding your QOS and end-to-end quality issues, you can produce to mitigate some of these issues. The actual bigger problem of Internet jitter is the second step of control. This is much harder - you can control how you produce a video piece for the Internet, but you can't control the Internet itself.

If you're doing video downloads as a content provider, but don't control the end-to-end distribution (e.g. you use colo and service providers and proxies), there are also good mitigation strategies as well on the edge, but the problem here isn't really technical (it's pretty straightforward) - the problem is the bizdev deals to handle the edge. But that's not really worrying about the protocol. My husband William Jolitz worked at Tandem with the earlier VOD biz deals (dealt with the Hollywood studio crowd) - so I learned about what *not* to do as well as what's needed. VOD isn't new. :-)

So the question really is - what is your goal? Reliable video streaming? Reliable wireless video streaming? Unreliable video downloading / offloading from a central site? Centralized versus distributed video vault / synchronization / integrity issues? They really run the gamut here. And they are all interesting.

Digerati Watch the Guy with the Glasses, Women Entrepreneurs Listen to the Voice of Experience

Well, last Friday was the "invite-only" conversation with Bill Gates of Microsoft and John Hennessy, President of Stanford University, at the Computer History Museum. I must admit, even if it was invitation-only it sure seemed everyone was invited - even me!

Matt Marshall in the San Jose Mercury News notes today that even Frank Quattrone joined the crowd to hear Gates speak. I didn't notice him myself - there were just too many people with multiply colored labels and press tags everywhere. But since I got the invite to that event myself, does that mean I'm a "friend of Frank" too?

I'm sure many others will cover the discussion, so I'll mention the other stuff. Did anyone there notice how "non-networking" the crowd was? I spoke briefly to a few people, but really - no one was talking to anyone else. Instead of a "happening" event, it was more like going to a funeral. Not really fun or upbeat. And I had my cool purple jacket on and everything.

Second, we weren't allowed to wander about the museum before the talk. Now, wandering about among the old computers is actually my favorite part of visiting the Computer History Museum, especially when people are not very sociable, because the computers give everyone something to talk about. But alas, no wandering. Guess I'll have to wait until the Vintage Computer Faire.

On the other hand, I had a lot more fun hearing Margaret Heffernan talk up her new book The Naked Truth last Weds night at Golden Gate University's San Jose campus. Margaret is a very enjoyable many-time CEO and Fast Company columnist who has a lot of very interesting things to say about the experiences of women in business. But don't just take my word for it - watch her for yourself as she discusses women, networking, and business.

I know everyone will be talking around the water cooler today about the guy with the glasses, and that's OK. But it's just too bad only the guys get the mainstream press coverage, while an experienced businesswoman and columnist gets all but ignored - but I guess that's what Margaret's talking about.

Fun Friday - Now, What is it About Unix or Yourself You'd like to Change?

Well, it probably comes as no surprise that I read Physics Today. But it sure came as a surprise to me to see GRE and research proposal disguised as recruitment ad...

Some of the questions are very interesting. Like question 5, "What's broken with Unix? How would you fix it?" or question 4, right out of Adventure Unix days, or 12 "In your opinion, what is the most beautiful math equation ever derived? (perhaps Hamilton's, as any physicist knows, but I'm sure they don't). Even 14 - What will be the next great improvement in search technology?

It's a GRE-styled booklet test. Not an ad. A booklet. If it had been blue instead of green, it would have been a classic "blue book" from Berkeley for exams. It was made for scientists - not just compsci people. Remember the most beautiful equation question - that's speaking to a physicist's heart and also a mathematician, but I don't know if they bother with hearts at Google or any other Silicon Valley company these days.

It's called the GLAT (Google Labs Aptitude Test). Would you know how to solve in a 2-d rectangular infinite lattice of 1-ohm resisters the resistance beteen two nodes a knights move away? (I'll give you a hint - we use an infinite lattice to avoid edge effects so the equations are simple). :-)

Interesting? Especially the Unix question...this shouldn't be here in a "work for Google" ad. Nor the Adventure one. Or should it?

IBM Steps into Gluecode

Open source services company Gluecode got slurped up by IBM this week. It provides custom services to companies who use Geronimo, an open source competitor to IBM's WebSphere. JBoss is another competitor in this market.

Why would IBM want to buy a company that appears to compete with one of its products? Actually, IBM can't do much about Geronimo - it's open source - no easy money there and no way to take it off the market. And they don't want to go low-end with Websphere - the descent may be endless. So why not buy up the services side? Costly customization is the IBM way.

Running the Microsoft Personnel Gauntlet

Ed Frauenheim of cnet discussed the difficulty of running the Microsoft personnel gauntlet, er, "puzzle". Why are they so arrogant? Obvious answer - they're a big fish. And some managers think that if their company is big, so are they and act accordingly. However, once they leave the "hive" they usually sink back into the ooze they emerged from in the first place.

When one of the Microsoft recruiters came for me back in the mid-1990's, I ended up hiring him to staff one of my funded startups - InterProphet. I recommend that startups in competitive times recruit a Microsoft recruiter - they're very good.

On the serious side, the simple reason that Microsoft has difficulty in hiring is their antipathy to anyone who has worked with open source. This "us versus them" mindset has caused them to lose out on very talented people and on new directions in research and development in operating systems.

I recall one time during an invite-only get-together on media, I happened to ask the Microsoft VP about how they could ensure that a university using their software could maintain their academic freedom in their research on operating systems without impacting anyone's rights. Instead of dealing with a very narrow question he launched into a diatribe about how open source will not succeed. I didn't mention "open source" - I was talking research and academic control of works - but it didn't seem to make any difference to Microsoft. They don't understand why a university researcher needs a great deal of freedom in working out new solutions to new problems. In fact, they don't even see a problem, even when their own people (as in the comments section) find themselves mired in endless patches and pre-release cycles.

To paraphrase Charles Darwin, "all things must evolve" - even operating systems and companies. And that, so to speak, is the "source" of their recruiting and corporate problem.

Academics versus Developers - Is there a middle ground?

Jim Gettys of One Laptop per Child is engaged in a furious discussion on the networking / protocol list as to whether academics should take responsibility for reaching out to the Linux community and maintaining their own work within the Linux code base. His concern is that networking academics, when they do bother to test their pet theories, use such old versions of Linux that it becomes infeasible to integrate and maintain this work in current and later versions. The flippant academic response is usually of the form of "we write papers, not code" variety (which isn't precisely true and actually then brings into question the relevence of said papers and the claimed work that stands behind them).

As Jim says himself, "If you are doing research into systems, an academic exercise using a marginal system can only be justified if you are trying a fundamental change to that system, and must start from scratch. Most systems research does not fall into that category. Doing such work outside the context of a current system invalidates the results as you cannot inter compare the results you get with any sort of 'control'. This is the basis of doing experimental science."

This is an old dispute, and one that has its roots in the creation and demise of Berkeley Unix (BSD) distributions. So perhaps a little perspective is in order.

Berkeley started with Unix through the direct involvement of one of its creators - Ken Thompson. One of the projects that was begun before the creation of BSD and it's research group was a modification Professor Fabry suggested to the scheduler of then Version 6 Unix. There was a PDP-11/70 with more than 70 users on it, so any inefficiency in the scheduler was revealed, usually in a ghastly manner. This was a production system, because it was also in use at other universities and in use at Berkeley's own computer center with 6 large time-sharing environments. Originally, v6 Unix simply used a process table with an index. Dr. Fabry wanted it to use a ready-to-run queue sorted on priority. Ken Thompson insisted that the benefit would be small, and the complexity (which was an issue due to the tiny address space -- the kernel program at that time fit into 64 KBytes, later raised by overlays done by William Jolitz as a CS199 project) would be considerable.

The change was implemented (I'm not sure by who -- anyone remember?), and the same machine with the same user base was run over week periods and results compared. The gain was found to be more than Ken had predicted. This empirical method of taking a production system and testing a revision was highly successful in proving Dr. Fabry's point and established a model for the creation and testing of systems.

With the success of this project, Unix at the University of California went from a convenience to hackers to the status of a research tool, and a research group of students (graduate and undergrad) was established later under Dr. Fabry's supervision.

At this time, universities were in fierce competition for ARPA grants, and there were proposals for the modernization of the ARPANET solicited. Elements of the modernization included creating a common platform for researchers (hardware and software), and an operating system that would support the networking protocols (originally CATENET, later INTERNET) from BBN and applications. Berkeley took a beta-level minimalist port to the VAX (done by Tom London) and revised it heavily (Bill Joy - system organization, rearchitecting and Ozalp Babaoglu - virtual memory).

There is a considerable list of networking and operating systems advances integrated and tested in this manner at Berkeley, and it fell under Dr. Fabry's purview. Among their later successes was the work later released in the original NET/1, as well as work integrated into NET/2 releases. Many papers came out of this academic-developer collaboration.

So why did it eventually end? The model of how an academic operating system worked at Berkeley depended upon the maintenance of a "near-production" version of an operating system continuously on a machine with a group of student systems programmers, later supplemented by staff programmers. Academics would collaborate with that group on an idea, the idea would be implemented by the aforementioned programmers, statistics would be gathered, and a paper would be published. But often, the academic did not do the implementation - instead, a programmer in this research group did.

The problem that arose is that as the research group became less a province of student programmers obtaining a CS299 / CS199 credit and more a province of professionally paid staff programmers, the academics, especially at Berkeley, began to see the lessening of an academic mission. In addition, the staff programmers were seen as "hackers", and no one on tenure track wished to be seen as consorting with hackers, so they disassociated themselves from the implementation work that led to outside success. Meanwhile, many of the programmers expressed frustration (many of them held degrees) and thwarted academics ambition -- their hard work was not taken as serious academic work. Finally, the people who would appreciate the implementation the most were other "hackers", so their professional circles diverged.

In a sense, an inadvertent class structure was created. While the Berkeley group still published papers, oftentimes these paper were done with outside academic groups, and the number of papers were fewer and fewer. The CS department at Berkeley had difficulty reconciling this work with their academic and research mission, and the social divide widened.

After Dr. Fabry left, there was no one within the faculty who could be persuaded to take on the management role long-term (it was handled by faculty on an ad hoc basis), and the group drifted. They survived by effectively taking on development work to pay for the maintanance of the software distributions upon which many other universities now depended, and questionable decisions were made independent of Berkeley's research mission. The academic-developer rift was complete, and this led to the eventual demise of the BSD releases.

But academics are still nostalgic for that brief period of time when networking work was in its "golden years". Much of the early Internet successes came out when when this model was fresh, equitable and seriously managed, so it is no surprise they would like to see it reestablished.

But as one can see from Jim's exploration of the matter, the academic-developer rift still remains. And given the real costs of developing and maintaining any new work in this area, it is unlikely to change until there is a real sense that the "hackers" who write the code should be considered the equal partners of academics who think up the ideas, and that perhaps both belong on that paper's authorship list.

Models, Simulations and Bugs, Oh My!

A recent discussion on e2e focussed on the efficacy of mobile / wireless simulations. You see, in the world of computer academia, simulations are de rigor to getting a paper through the peer review process, because it can provide you with lots of neat numbers, charts and diagrams that look nice but may mean absolutely nothing in practice. But "in practice" means applied (or horrors, development) work, and that's usually met with disdain in the academic world (see Academics versus Developers - Is there a middle ground?). In other words, blue sky it but never never build it if you want to get a paper approved.

Simulations and models are an important tool in understanding the behavior of complex systems, and they're used in most every scientific discipline today. But there's a delicate distinction between a model of an environment and using the model as the environment -- one that is often lost in the artificial world of networks and operating systems.

My son Ben Jolitz won a number of science fair awards at Synopsys 2007 this year in part for a computer simulation of varying salinity levels in marsh grasses in the San Francisco Bay wetlands and the impact on these different species due to global climate change. Marsh grasses (cordgrass Spartina) are a baseline indicator of health in the wetlands for many other species. Unexpectedly, his simulations showed that hybrid species of these marsh grasses would likely crash as salinity levels increase while the native grass showed remarkable resiliancy. While this is cool to environmental scientists, its also important to the rest of us because several bay regional agencies have allocated a tremendous amount of resource to eradicating this species as "non-native". However, if it is going to undergo stress and collapse, funds might be better focussed on preventing wholesale collapse of all wetlands (the hybrid is very entrenched throughout the region) by developing "plots" of the native within hybrid colonies. As the hybrid retreats, the native expands. This is very different from the "mow and blow" approach on the drawing boards.

Of course, simulations are just simulations. The more complex the environment, the more difficult it is to claim with certainty that what we see 50 years hence or 15 billion years in the past (in the case of certain cosmological models) is accurate and true. Environmental, biological and physical models are hence carefully scrutinized and debated in these disciplines. It is too easy to be led astray by state-of-the-art processing tools and statistical methods to the exclusion of the science. But what if simulations are the only tool that can be used, as in the evaluation of certain mathematical proofs? Well, these too are carefully evaluated and debated, and usually long in acceptance because other tools cannot be used to "test" them against. Research is a life-long examination of the evidence.

OK, what does this have to do with computer science and networking? Well, like other disciplines, simulations of Internet routing, for example, or impacts of congestion on wireless networks are complex and ever-changing. But unlike these other disciplines, we are working on man-made objects of our own design, which means we can actually build and test systems. We can go beyond simulations! This should mean that emphasis in results in papers should be given to those who build and not just simulate. I know scientists in other disciplines who have expressed envy at the comparative ease to which we can build and test a model in such an artificial environment (or at least, the belief it can be done) when wrestling with environmental, biological or cosmological questions. But in their case, so much is unknown that the simulation is a matter of educated guesswork, and projections may not be verifiable within the lifetime of the scientist. "How nice" they would say "to be able to see your work validated".

So here we are, in the computer biz, with the ability to prove every bit of our creations, from network processors to operating systems to applications, simply by building it and testing it. You'd think that the academic world would be brimming with these real-world results in papers. And you'd be completely wrong.

The reasons given for why simulations are "good" and actual results are "bad" is that in the real world implementations on which things are run are "buggy", rendering the results imperfect. Now, that probably doesn't make a lot of sense to an ordinary scientist or engineer who spends his or her entire career dealing with systems full of "bugs" or unknowns. Why would a unrealistic perfect simulation be better than a "buggy" real-world result?

The real-world answer is far less glamorous than computer scientists would like to admit. In essence, they're afraid of having to fix bugs in other people's code. I don't blame them -- there's a lot of lousy code out there. They also believe if they become developers they lose their status as researchers. God forbid you should ever do something that people use. I suppose if I'd have had that attitude, there would have been no 386BSD and no Porting Unix to the 386 writings on the project and no open source BSD today (and possibly Linux - Linus and the GNU folks read the series too). It might have made me more respectable in the academic world to have avoided building the first patented first prototyped and first demonstrated Silicon TCP low-power state machine TCP protocol processing engine as well, but would that have made me a better researcher? Would I have been pleased with a simulation when I could get the money to build it and prove it worked? I don't think so.

Aside from philosophy, I think Jim Gettys of One Laptop Per Child puts it quite well:

I suppose we all want it easy. But if we've already got it easy compared to a physicist, biologist, or environmental scientist, shouldn't we all do the work we can do? Shouldn't we give credence to papers with real results instead of discounting them for disingenuous reasons? And finally, shouldn't we respect people for all the work they do, from gathering the data in the field to writing the paper? After all, science is about hypothesis, test and results. Epistemology and creative writing belong in the philosophy and fiction departments -- not networking and computers.

GPLv3 - Yes, You Can Run DRM (If You're Very Very Sneaky)

GPLv3 and DRM. Yes, we've heard it all before. The license says you can't use it (essentially, if you use it, you have to show the code, which means people can remove it). The advocates from the Linux Foundation and their mouthpieces say you can. It reminds me of the policeman shrieking "Do not panic, all is well" at the rioting crowd in Animal House right before he's trampled. Meanwhile, open source followers seem to be trapped in the alleyway...

So, does it ban DRM or doesn't it? It does, but there is a big loophole, and Microsoft (and a few of us old hands at open source - after all, we helped invent it) know it.

So here's the little secret - use a virtual machine.

Now, I'm not fond of DRM myself. It never works right. It's a blight on people who buy legit software and music and movies and all sorts of other media, because the law clearly states people have the right to make backups. And it encourages nasty little forays into personal punishment like the Sony rootkit fiasco. I sympathize with artists and creators of copyright works about compensation -- after all, I'm an artist and writer myself. But Internet disruption is going to be with us a while, and we should focus on trying to form new monetization mechanisms instead of being regressive. From the earliest days of "copy protection" of software and VCRs, consumers have required the ability to protect their investment.

But here's the key to using it (and anything else you don't want GPL'd by the way -- perhaps you've created some new hamburger helper for a database or codec). Virtual machines are external to an operating system. As one notes in Microsoft's Vista EULA, they are considered a distinct operating environment like a processor, but they are not truly a processor because they are not a hardware device. One could use DRM external to a program in one of the interfaces that the program uses to access its operating environment. Attempts to make this seem a form of "dynamic linking" (which is covered under the GPLv3) might run into problems, because the lawyers trying to disprove this contention would show the similarities between dynamic linking and their implementations (all would correlate), while the virtual machine ones and their non-invasive means of operation (they are by design "invisible" to running programs) would appear very different. Microsoft worked a great deal with VMware to make it possible to detect them, out of exactly this concern.

So it would be very difficult for a judge to see dynamic linking and using a virtual machine as similar.

As to the efficacy of doing DRM this way, one would in the virtual machine track files, network connections, and changes to the program's context, looking for fingerprints, watermarks and the like and invalidating operations or enforcing exceptions when the DRM rules are violated. One could even come up with a very pervasive form of DRM that would practically resemble a rootkit -- more powerful than current DRM mechanisms today.

For history buffs, a dynamic linking hardware / software combination was originally done in Multics with the GE645 and was not some invention of the 90's. The way dynamic linking was accomplished was via a form of a virtual machine. You'd go to reference through a special pointer arrangement a new segment (library). If the library had been mapped (i.e. it had been loaded already), the reference would continue with the hardware; otherwise, a trap would be triggered (a segment fault) and the operating system would act like a virtual machine to search and load the appropriate dynamic library (segment) and allow the operation to continue. Had the designers of the dynamic library systems popular during the rise of open source Unix learned from the Multics experience, there would have been no difference between VMs and dynamic loading. One of the things that we looked at with 386BSD was doing dynamic libraries and other operations this way, because we were concerned about the fragility and integrity of simplistic dynamic library mechanisms. Our concerns have been proven out, as this episode demonstrates. Sometimes you can learn from history -- if you're willing to listen.

And that's why Microsoft doesn't let you roll your own virtual machine for Vista. This may also provide a strategic opening for Xen, because one could integrate into their virtual machine dynamic loading in an interesting way. Maybe everybody else should twig to the game before things get out of hand again?

Safari Goes Corporate - Jobs Announces Windows Version

Steve Jobs today announced that Safari, the annoyingly broken browser for the Mac, would soon be appearing on Windows systems as another annoyingly broken Windows application. Aside from the obvious joy at the thought that browser compatibility testers would no longer require a Mac to do their job, is there any other import to this announcement? Well, there are a few possibilities...

One possibility is this is part of the strategy of going ever closer into direct competition with Microsoft, although Safari isn't in the same class as IE (or even Firefox). Safari was built on the KDE Project's KHTML layout, BTW. For a number of years there was frequent sniping between the groups - the KDE volunteers felt Apple didn't comply with the spirit of open source (they'd take their time in submitting changes, for example) while Apple complained they weren't quick enough fixing their bugs. I always found the latter complaint hilarious because Apple was notorious for never fixing their bugs even when they could. The source trees have diverged greatly since this initial schism (schism in open source? perish the thought), and there are dreams of somehow "mending the rift" through "unity" initiatives. But this is a lot of work for a questionable gain.

Open sourcerers are good at fractionating markets, but lousy at aggregating them. It's just too easy for someone to run off and roll his own when he gets miffed for a potential quick gain (while wacking the older group). Fractionation totes up in the big book of life as a long-term cost hit on the entire open source market segment, and is something Microsoft loves to see.

As Apple has migrated off the PowerPC, the distance between them and a Wintel platform (Mactel?) has diminished mightily. The "next step" (yes, a pun) is moving their software onto Windows to develop an audience, so the distance between Windows and Mac becomes a matter of taste. Apple knows that eventually they have to face the harsh economics of the Wintel world. They also know Microsoft has to move the Windows franchise intact to a very broad market, while they only have to appeal to a subset of that market.

Is it better to be a remora or a whale? If they can profit from the current Microsoft open-source obsession (you know, "Get Linux"), they can do very well taking bites out of Microsoft's market, since Microsoft prefers to fixate on one enemy at a time. If Apple gets too troublesome, Microsoft can always buy it. Of course, maybe something in that Microsoft-Apple agreement signed years ago makes this a lot easier than one might think (although nothing is ever easy around Steve Jobs).

Oh Microsoft, Google is Calling - They Want the OS Space

With the announcement of Android, the Google open source mobile platform, there has been breathless talk of Google taking out the "locked" cellphone market with a Linux OS version. But we all know there are many open source Linux OS mobile versions already out there, so grabbing one and putting some stuff into it isn't really that hard. In fact, one wag I know had this little joke:

Hmm, ever since the bright kids at Google were accused of appropriating code to build their social networking site Orkut (see Google Stole Code? Is Social Networking that Hard?), many techies have expressed a somewhat low opinion of Google's technical expertise, especially when doing the actual work with all those incredible resources in people and money is probably a lot easier than "borrowing" somebody else's "crufty" code and figuring it out. Sometimes, by the way, "crufty" means "I can't figure out your code because I'm too stupid so I'm going to run it down". I got that a lot with 386BSD. But given the incredible brainpower Google has gathered, I would think they could not only eventually figure it out, but maybe do a better job from the beginning...

So if Google is so full of smart people, why I am asked did they just take a Linux distro and hack it? Why didn't they give us a "from the ground up" genius OS?

Google is full of smart people, and Linux (and BSD and Windows BTW) are not optimal OS's for mobile computing and they know that. They also do have the resources to completely change the paradigm of open source and mobile computing but choose not to. That's a fact.

But choosing a Linux distro and entering the mobile space is the perfect feint if a very large and very rich company has decided to take on Microsoft in the OS market, but is worried given their rival's monopoly that they already would look like a loser if they competed directly. By cudgeling one of the Unix lookalikes and stuffing it into a small device, they can appear like they are a real contender in a big space and work their way into the heart of Microsoft's defenses.

So it is a smart strategy. Too bad people only think tactically nowadays - they're missing the real battle.