|Home » Learning Curve » Red Hat Diaries
Field of Dreams
Ray Kinsella believes.
An operating system is what's between the hardware and the applications just like the applications are what's between the operating system and you.
Today there's an added level of complexity to support the graphical layer: instead of reading intelligible commands in text the operating system has to offer myriad doodads so you can click on things to eventually get where you would have got a long time ago with your keyboard.
The addition of the graphical layer burdens application code by a factor of 100-120%: at least half of all application code today takes care of the interactivity and the graphical doodads and has nothing to do with the task at hand.
Add the file system: the file system is (or at least should be) a tightly integrated partner of the operating system itself. These two should work hand in hand to both improve both usability and security.
Given those premises how does Leopard stand up? With only a day remaining before the official release there's not much worry about NDA transgressions anymore. Here's a brief summary of what should be important in the new release of OS X.
64-bit: this is what's really news and yet not many pundits are talking about it. The move to 64-bit represents a sea change the likes of which haven't been seen in fifteen years. 64-bit computing implies 64-bit programming and then all the rules change. The perennial 'long >= int >= short' changes all over again. Pointers are now 64-bit. And so forth. Small adjustments all over in the code as the basic definitions change.
The change from 16-bit to 32-bit in microcomputers was a sea change because addressing requirements plus preemptive multitasking required something better than 32-bit which 32-bit could achieve but 16-bit could not. Suddenly PCs could support 'real' operating systems like Unix and VMS (NT).
Will 64-bit give us more than 32-bit? Not in terms of speed it won't. 32-bit programs are probably faster because there's only so much a CPU needs to do and after that all the extra bytes in program instructions go wasted. Plus of course a now sidestepped fact that Intel architecture implies a lot of juggling all the time as the CPU can't hold that many variables on board.
64-bit means bigger variables but it doesn't mean more variables - Intels are going to be switching in and out of the CPU at a frenetic pace where Power based chips just kick back and relax.
Moving 64 bits at a time is more work than moving 32 but in terms of application domains it's better - as Bill Joy once quipped, it's not a database anymore - it's a data structure. Even with limited physical RAM the possibilities grow, thanks to virtual memory.
And if a 32-bit operating system could support a 64-bit file system then it probably follows a 64-bit operating system will be able support a 128-bit file system. Such as ZFS. Which takes computing about as far as scientists currently think it can ever need to go.
It's likely Apple have a 'ralkram' project alive inside the Loop just as they had their Intel project and just as they have their ARM based iPhone project. It helps to enforce a modicum of hardware independence - Microsoft totally abandoned this and solely supporting Intel hasn't helped them one iota.
Apple still have their abortive HFS. They may have cleaned up their .DS_Store act a bit but those nasty critters still exist. Fanboys have to rely on all their folders coming up in the same place and with the same size each time so they don't have to really look at them but can immediately recognise them from their size and position - all 25,000 of them. If Finder can be smart enough to not drop its doo-doo in other than a user's home area it will be a big step forward. Check to see once you've started playing with the system.
Apple love graphics and their business is graphics and you naturally do what you can to support blazing graphics but application icons weighing in on an average of over 300,000 bytes? Not so very long ago NeXT raised the bar by using 48x48 icons when everybody else had 32x32. Then came the move to OS X and 128x128. Now we've got 16 times that size.
NeXT icons weighed in at 5-10 KB; Tiger icons weighed in at 40-60 KB; multiply that by 5 and you're up to Leopard graphics standards. When your app executable once stripped is only 50 KB and the doodad it displays in the dock is six times that size? Yes it's totally out of proportion but if you want the good graphics you live with it - unless you find a better way. Is there a better way? Has anyone bothered to look?
Just as a lot of people reacted to Tiger Mail a lot of people are going to react to the new user folder icons - those and 'Applications' and 'Developer'. They're almost two dimensional, they basically look all the same - drab. The system offers toolbar icons with a lot more colour but the standard file system icons are going to make a lot of people react negatively.
Right up to the wire there are serious rendering issues. They seem to be part of the Tiger Quartz legacy. Big blank splotches on screen, remnants, etc. One wonders how this system is going to fare in showrooms or perhaps staff are going to be instructed in what programs one does not open in front of potential customers?
The developers: there can be a lot of fanatics in the Loop but the better guess is a lot of them just want to hold down a job. And working on an operating system can be cool - even if Steve Jobs is looking down and cracking a whip. But to suddenly be told to put everything on hold and jump over to the iPhone project?
Word namely has it Steve Jobs was against hiring on more programmers for the iPhone project - those already gainfully employed instead had to straddle two projects at once. It never seemed to work for Microsoft, Jobs was to have said. Do programmers really perform better when they're stressed to an extreme?
Imagine how it must be with so many unresolved bugs for Tiger still in the pipeline. Now before these are taken care of you jump from Tiger (or Leopard) to the iPhone and then back again. And you simply don't have enough time. Neither to write nor to test. You're stressed all the way. Do you perform better? Perhaps - but what happens to you? Rumour has it a great many programmers in the Loop are close to burn out as a result.
And what happens when Leopard's released? A new flood of bug reports? When do they get a break? And even if they've been mercilessly stressed you know who's going to get the blame, don't you?
Apple's applications are really irrelevant. Fanboys in all camps try to compare their operating systems by feature. Which is ridiculous. Third party write the features; the OS vendors write the OS. And perhaps a few other apps to get people going. If the OS vendors can concentrate on the OS and make the OS as rock solid as possible everyone benefits. If they try to add the doodads themselves everyone loses.
Certain applications are unavoidable: personal computers must work today 'out of the box' with all that implies - especially the Internet connection and rudimentary net tools such as the web browser and the mail client. And some digital hub stuff. But you don't need much more.
If the 'rock solid foundation' is rock solid enough the features will come. All you have to do is wait for them. Don't get it rock solid and things will never be right.
To be rock solid Leopard has to have a stable and secure kernel, a dynamic and flexible file system, an accurate graphics layer, and a superior API.
The API: no contest there. No matter the issues added after the fact it's still in a class of its own.
The file system has to be set out to pasture: it's been around over twenty years and it's at least thirty years out of date.
The graphics layer still isn't working right. No one really understands why things had to go downhill after the flawless Panther and no one understands why things can't be brought back into line either.
The kernel: are there outstanding issues? From the days of Tiger there certainly are. Simple bookkeeping things like 'repair permissions' which opens the system to a root attack; input managers which allowed any malfeasant to hijack any application; misplaced configuration files like the screen saver password prompt.
The metadata layer now inserted under the launch services: its code is flawed. Whilst the launch services can take care of a situation where the requested application cannot be found the metadata layer cannot. And so after nixing the bad request the launch services dutifully pass the data on to the metadata layer which promptly crashes.
Input managers are finally gone. Kevin Finisterre (and Rixstep) put considerable pressure on Apple over the years to get rid of this security eyesore. It's finally gone.
The 'repair permissions' hole is a design flaw: anyone can muck with BOMs which then are picked up by DU, meaning rogues can create hijack scripts DU will allow them to run as root. A lot of thought will have to have gone into fixing it. Hope for the best.
Leopard isn't bona fide Unix but it's close enough. It would be better if the kernel were completely open: this would lead to better code and more trust in it. It would also imply no one could sidestep the security of the kernel and jeopardise the user. It would be even better if Apple simply used the FreeBSD tree as that could free them to do other things that are more important. Daydreams.
But as it's close to Unix it's infinitely superior to Windows. Windows has no security model at all.
The Unix certification means less than nothing: it might mean a bit for certain types of contracts but otherwise it's just a fancy diploma. Even Microsoft have equivalent certifications. And it's an expensive diploma too. And it does not imply one is 'real Unix' through and through - for OS X is not - nor can it be construed to mean OS X 'behaves' as a real Unix system - for it does not.
None of the Linux systems such as supported by IBM and Novell are likely to ever get (or want) a Unix certification - it's a lot of money and it doesn't net much more than a bit of PR and prestige. Linux and especially IBM are doing fine without it, thank you.
An operating system is a foundation. A foundation others build on. The final arbiter on Leopard is to what extent third party flock to the platform. If Eric Raymond's to be believed there are good chances Apple can achieve hegemony on the 64-bit battlefield despite Microsoft's current dominance in the PC market: 64-bit is a new ball game, says Raymond: the slate is wiped clean, the players start anew.
A good foundation is something you build so you can build other things on top of it. In the best of all possible worlds this Leopard foundation would be around and not be mucked with for a great many years. Not mucked with - just perfected. As David Pogue recently quipped, the development trend in software today is to keep enhancing it until you finally ruin it. Keep things simple, perfect the code you already have, resist the temptation to add more doodads - and then just wait. Ask Ray Kinsella for he knows.
If you build it they will come.