Categories
Oct 2007
Aug 2007
Jun 2007
May 2007
Apr 2007
Mar 2007
Feb 2007
Dec 2006
Oct 2006
Sep 2006
Aug 2006
Jul 2006
Apr 2006
Mar 2006
Feb 2006
May 2005
RSS
Categories
Oct 2007
Aug 2007
Jun 2007
May 2007
Apr 2007
Mar 2007
Feb 2007
Dec 2006
Oct 2006
Sep 2006
Aug 2006
Jul 2006
Apr 2006
Mar 2006
Feb 2006
May 2005
RSS
OSX
Microsoft and Ethics
Over at The Register there is an amazing story of Microsoft first awarding a developer 'Most Valued Professional' status for a program that extends Visual Studio (the give-away version, "VS Express"). The amazing part is that they then turn around and sue him for the same program!!!

The basic problem is that they (MS that is) were lazy - they released a "technically limited" version of the software, and just removed some of the modules they wanted to reserve for the loadsamoney version. They didn't remove the ability of other modules to interact with the removed one, but instead relied on a clause in the (still untested in court) EULA that no-one reads.

So here's their problem. A guy called Jamie figures out how (using only public interfaces) to re-enable the plugin ability of the give-away version of VS. Re-read that sentence - he uses only the public API's to do this. Any public API is fair game for a developer - it's a promise (a "contract", if you will) that the developer can use this code however (s)he sees fit...

Now, let's look at the EULA clause, and see what it is that MS are trying to argue...
"...you may use the software only as expressly permitted in this agreement. In doing so you must comply with any technical limitations in the software that only allow you to use it in certain ways... You may not work around any technical limitations in the software."
Ok, that seems fairly clear, and at first glance, MS would appear to have him cornered, game over, thanks for playing. Oh, wait, hang on - Jamie only used public API's - the ones that Microsoft publish so that developers can use them - the "supported" way to access Microsoft code. So, in fact, Jamie is not working around any limitations, he's using the officially-supported way to code-up his program.

Now, Microsoft might never have expected Jamie to use their code in the way he did, but he's not doing anything wrong by doing so - this is not "working around" limitations, this is using the provided, supported API for something that MS never intended. Here's the simple example:
Consider a function that adds 2 numbers, and returns the result. It's called 'add2Numbers'; if you pass in {2,3}, you get 5. Jamie, however uses it a little differently - he passes in {3,-2}, and gets 1. This behaviour is the same as the forbidden function 'subtract2Numbers' which only people who pay loadsamoney to Microsoft get to use.
Now MS are upset about the use of 'add2Numbers' which does the same thing as their "loadsamoney" function 'subtract2Numbers' if you use Jamie's code, but they can't do anything about it... Except they do, of course. They first try to bully him (without telling him exactly what it is he's done wrong, mainly because he hasn't done anything wrong), and then they lawyer-up.

The use of public API makes whatever you do a supported action by the publisher of that API. Microsoft may not supply the facility that Jamie has stepped in to provide, but they most certainly do support it. If they support it, they shouldn't be able to sue when someone actually does it...

My suggestion to Jamie (and those like him) is to come over to the side of the Angels - get a Mac, run Xcode (the full version, no charge), and develop to your heart's content. Here's why:
  • Macs really are cool to code for. It's sort of like a mature version of VS.net
  • Objective C really (really!) rocks. It hits the complexity sweet-spot, and lets you easily do so much!
  • The community is a real one, not a fake one that bites you if you counteract some vague as-yet-undisclosed business plan.
  • We won't tease you (much, we're only human) for your previous life as a Windows coder.
  • Do something cool, and Apple tend to buy your company, not sue your ass.
  • If you love unix, you'll love OSX. If you loathe unix, you'll love Cocoa which shields you from it. You'll probably learn to love unix eventually though :-)
  • We have cookies.
  • There are more reasons, but you ought to find out for yourself...


Seriously. If MS put you in a spot like this, get legal advice, and point out to your lawyer that using public API in an until-then-undiscovered fashion is a good thing. At the end of the day though, the cross-hairs are centered on you - don't forget that.


OSX disk performance
This is actually in reply to a comment on slashdot, but I couldn't format my reply properly... You used to be able to turn on <pre> tags, and get pre-formatted text to look ok - not any longer, at least not that I can see. Oh well, loss in functionality, but it looks a lot prettier now...

So, here's the post:

  • In a server setting, ports must be open. OS X much-vaunted security (mostly, no ports open) is now at risk.

  • In a server setting, you would use a supported distribution of Linux. This includes security updates. Same as Apple.

  • In serving Windows clients, SMB would be provided by SAMBA. The web administration of SAMBA is the same.

  • OS X has always performed very badly in disk access (its architecture is bad for this).

  • Local service can provide setup and maintainance contracts. The small shop does not a full-time guru.


To address these point-by-point

  • Although the OS is shipped with ports all closed, this is only one small facet of the security of an OS. This also ignores the fact that in the firewall configuration, you can specify address-groups, and configure custom rules per group. Just as with any firewall, a port doesn't have to be open to the world, just those that need access to it. Still, there's a lot more to OSX's security than a firewall...
  • I'm fine with the idea of using a supported Linux distribution - I'm trying to correct wrong impressions of OSX, not put down Linux - I've been running Linux since it came with a boot-disk and a root-disk, and you had to be careful about whether you had an FPU...
  • The web-interface is the same, but I think you get more from OSX. The integration is better (it's more similar to all the other users), and the feedback is better - realtime stats are available (as they are for pretty much everything).
  • This is what prompted the reply. This is just plain wrong. I downloaded, compiled and installed 'bonnie++' ...
    prompt% sudo port install bonniexx
    ...and ran it on my Xserve. Now this isn't an X-raid (those can really fly) - this is a RAID-1 (mirrored) setup, with 2 of the slow-but-large internal 750G drives that Apple supply. Here's what I get with bonnie++ -q -s 4096 -n 128




    Now before everyone looks at the 'per-char' figures and compares them to random bonnie++ results on the 'net, it's worth noting that the figure was intentionally lowered in version 1.92 of bonnie++ (it's in the Changelog, if you want to see why). For a 2-disk RAID-1 system, those are very respectable results. Certainly it doesn't "perform very badly" - note the figures in red, for block input and output...

    Just for giggles, I also ran this on an XServe/XRaid combination, with two XRaid (RAID-5) units bonded into one logical disk (for a total storage of ~10TB). Here's the bonnie++ report:



    Have a look at that for i/o - the disks are sustaining a GByte/second (!) I think that's actually limited by the transfer protocol (4x 2Gbit fibrechannel cables connect the xserve to the xraids, 2 to each unit). Yeah, that's really performing "very badly" [grin]

    I've taken the latency figures out, because it's hard enough to understand the output from Bonnie, but they were all pretty respectable too - all in the uSec or mSec ranges...

  • As for requiring a "guru"... The point of OSX-server is that you don't have to be a guru to administer it. The average 'office-computer-know-it-all' ought to be able to administer the network (and probably get a pay-rise because of it), if (s)he's using OSX-server...


There are parts of OSX that could stand some improvement, mainly because of the mach-based underpinnings of the OS. fork(), thread-creation, context-switching etc. Could all happily see some gains. On the other hand, it could be that message-based underpinning that means OSX scales more meaningfully to larger numbers of cores. Oh look, what's on the horizon ?
Oct 2007
Aug 2007
Jun 2007
May 2007
Apr 2007
Mar 2007
Feb 2007
Dec 2006
Oct 2006
Sep 2006
Aug 2006
Jul 2006
Apr 2006
Mar 2006
Feb 2006
May 2005
RSS
Categories