Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | Search | Xfile Test Drive
Home » Learning Curve » Developers Workshop

Karma's right around the corner

A Catalina wish-list. Knock knock.


Get It

Try It

1. Fix task management

CLIX was (is) a great app, used by over 150 Apple engineers, and it's made a lot more secure than Apple could have made it, even (or especially) with their code-signing. It uses a method best described as 'attach a padlock on the outside from the inside'.

And it still works great, even today.

But this method - 'Houdini' - is not the problem. The problem is akin to what Steve G encountered a few iterations ago, when one of his background processes suddenly started popping up in the Dock. This was reported to Apple, who evidently resolved the issue. Now it's back again, this time in CLIX, in a new and picaresque manifestation.

Programming bug or not, it's not worth reporting - some 50+ bug reports later, the writing on the wall is clear. But no worries: the current CLIX works fine. But it's always white.

2. Restore Services

The Services menu used to be better. NeXT only allowed two levels of hierarchy, but at least there were two. Now there's only one, something that severely limits usability.

Apple also got morbidly paranoid about Services - perhaps because they'd screwed up with root-enabled servers? Of course that could have been remedied without trashing the entire system... And having to in practice reboot a machine to see if a service actually works: that's unacceptable. You can do better, guys.

3. Untie Finder from launch control

Finder used to be configurable through a property list file. Finder is tied to the Dock as File Viewer was to the Workspace. But removing Finder from the Dock should be an option, and users could 'opt in' through a context menu.

See below as well.

4. Restore NSDocumentController

Who's being protected here? Some Apple suit who marks his files read-only and then can't find his feet in broad daylight? Files can't be 'locked' on Unix, you silly whoever-you-are. There's no such thing.

But the 'hack' you came up with to satisfy your morbid boss is flawed: you changed NSDocumentController, the module that actually controls documents. Instead of copying in files from the temporary location, you move them in instead?

Which of course introduces another issue: namely what occurs when the host directory is marked read-only. (Not to speak of the haywire workarounds needed to preserve application-specific metadata. Yes it's a mess. You know it.) And for that you had no solution, and your poor perplexed user is left more perplexed, told the lie that there's something wrong with a file when there's nothing wrong with any file - IT'S THE DIRECTORY. User-friendly? Oh yeah. For real. So what happened to 'honesty is the best policy'?

Those were trainees from Redmond on loan for the summer?

5. Stick to consistent industry-standard selection behaviour

Apple's behaviour with regard to data selection - inherited from NeXT - was best in the industry. Things went wrong with Leopard or Snow Leopard. All selections in table views, whether by column or by row, should be the same as they are for text.

But not now. After twenty years. When Scott Forstall's recruits moved to the iPhone project, those left behind were supposed to guard the legacy NeXT code. They didn't need to write a lot of new code. And they definitely didn't have carte blanche to muck about with code they didn't understand. Code that in many cases was twenty years old, tried and proven and true.

Rixstep happened upon such an incident and reported it to Apple and actually got an apology. And Apple restored the old code - but only for future iterations, which of course was unacceptable.

The tableview team screwed up too. And they know this. For successive point updates showed they'd been trying to fix the error - in vain, failing over and over again. Instead of just going back to the original code and fixing things properly. This remains a classic 'Epic Fail' in a class of its own.

6. Remove redundant cache and temp file locations

Why do we have all these cache and temp files all over the place? We have them in ~/Library/Caches. We have them in /var/tmp. But that's not enough. We have to have them in /var/folders too.

_CS_DARWIN_USER_DIR
_CS_DARWIN_USER_TEMP_DIR
_CS_DARWIN_USER_CACHE_DIR

And they're duplicated in at least one more - but sometimes two more - locations.

Too many temp and cache files, guys. Your system is a mess. It's chaos. There's elegance in simplicity, don't forget. And this is not elegant.

7. Rescue defaults

Aka 'bring back that guy from lunch'.

The beauty of the old defaults system was that it was tangible and issues were readily remedied. The patent solution for any application misbehaviour was to exit and wipe out the prefs file, automatically restoring 'factory defaults' on next launch.

But not anymore. Oh no. The documentation explicitly states that might not work anymore. And why not? And if settings are not in the prefs file, and not in the mutant monster /var/folders (what an original name) then, pray tell, where are they?

What kind of invisible superstructure are you running?

This is worse than Microsoft's Registry.

One can always send a 'synchronize:'. It's always worked. Bring back the dude from lunch.

8. Static API underbody

How would MVS have fared? Or VMS? Or Unix itself? Or Linux?

You can't go on changing the OS underbody. This only keeps third party engineers busy rewriting the same old code over and over again. But perhaps that's the point?

9. No Finder straightjacket

Oh it's so cute and cosy for the unwashed. But then? If you can't offer a decent file manager, then make the Dock configurable so you can remove it. But honestly: can anyone take Apple seriously with a file manager like that? As the pros say:

'Show them the server hardware and their eyes go moist. Show them the Finder and they walk away.'

And for heaven's sakes get rid of .DS_Store. You can't use that 'spatiality' excuse anymore.

Standard user directories:

/Network/Applications, /Network/Applications/Utilities,
/Applications, /Applications/Utilities, /Library, /System,
~/Applications, ~/Applications/Utilities, ~/Desktop, ~/Documents, ~/Downloads, ~/Library, ~/Movies, ~/Music, ~/Pictures, ~/Public, ~/Sites.

You got room for that?

Cars aren't complex, John. Get over it. This isn't a toy - it's a real operating system. Can you man up?

10. Merge on file ops

A yuge point, one that's decades overdue. It must be important because so many ISVs offer it. And Apple's OS is the only one in the world not following this paradigm - which is why they use the term 'merge' to describe it.

Implementing it at filesystem level doesn't have to be difficult - it's for example not always necessary to check return codes on directory creations as subordinate copies will also fail - but it has to be centralised. Why? Two reasons. At least.

  1. Because it's some of the most important code on a computer, and it has to be rigorously tested against known and unknown exceptions, against more common filesystem errors, against blackouts and brown-outs; it has to be able to 'roll back'; it has to be able to take over user interaction and manage the entire operation from beginning to end, no exceptions and no client interference.

  2. Because you don't want every Tom Dick and Harry trying to implement the code on their own for heaven's sake. That's not only stupid and wasteful, it also welcomes errors and mishaps and a lot of bad publicity for Apple.

The 'massive data loss' disaster uncovered by Tom Karpik would never have happened if this code were written correctly.

Yes, it's more difficult than what you're doing now - almost anything is - but it need be done only once and you're the ones who have to do it - yes it's that important.

No one in the world outside Cupertino will take Apple seriously until they show they take their file management seriously. Counting on vigilantes to patrol message boards for negative comments about Apple's screwups is not and never will be an honourable or intelligent solution.

11. Cohesive self-contained (and protected) file management object

A superset of the above. The filesystem is at least as vital as the devices, its management code at least as vital as that of any driver. File management functionality must be encapsulated. Client applications should have no direct access to the filesystem, but instead send requests to the file management object. Thanks to Dave Cutler, this is one thing Microsoft actually did right. Again: no one is going to take Apple seriously until they start taking file management seriously. Should they do this properly, they can rule the world, as even Unix is weak here. Apple can take a quantum leap forward and never again risk the bad publicity they've got so many times in the past.

Implementing change notifications at filesystem level would also be a good (and relatively trivial) thing.

12. Directories listed first in I/O dialogs

So counterproductive as things stand. Directories can be huge today. Users shouldn't have to scroll through hundreds of files to find the directories they're looking for.

13. Open Darwin

Open Darwin should be revived. Open Darwin should be the complete source to a functional OS underbody.

As long as the superstructure behaves, no other code need be revealed. But Apple's OSes should be open source in the final analysis.

14. Introduce new features by 'opt-in'

Time and again you make the same mistake: you guess where Gretsky's puck is going and you get it wrong. 'Save As' became 'Export' which became... How many iterations have we seen? Three at least, no?

Steve Jobs could see the puck - you can't.

Not to speak of what this does to ISVs through Xcode. Only to find you back-pedaling through it all, time and again.

You happened upon a good idea? Great! But make it an opt-in until you see how it's adopted, instead of getting egg on your faces.

15. Open Distribution

If you're that big;
If you have nearly a trillion dollar market cap;
Then you can afford to open your system.

Stop thinking about profits tomorrow and more about where they'll be twenty-five years from now.

You might see your enterprise prosper in a way even you and your fans never imagined before.

Your App Store system slows apps down; it has to. Who needs that? You deliberately crush the ISVs, wiping out the 'freedom to tinker'. You've replaced fun with rote and drudgery - who cares about quality anymore? An indy cut out for the field who will work all hours because it's fun - or a faceless, nameless, soulless orc hidden deep in a cubicle who keeps checking the time on the latest Apple Watch?

From a company who understood nothing about mobile security you've devolved into a paranoid carnivore perpetrating a con-game more sophisticated than that of Keyser Söze. And sooner or later the word will get out and spread. You want to risk it all for a quick buck? Really?

16. Build on simplicity

Karma's right around the corner. Knock knock.

You're a yuge company, with thousand of programmers, reporting to managers reporting to managers.

Fred Brooks famously said one can't create an OS with less than a thousand bugs (even if Bill Gates said his company could get it down to seventeen) and yet the essence of what you're building on today was created by two tinkerers in New Jersey mostly all by their lonesome.



You can't build on complexity. You'll only end up with a mechanism for further confusion and possibly your destruction.

You can only build on simplicity.

Keep up the good work.

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.

CONTACT INFO:
John Cattelin
Media Contact
contact@rixstep.com
PURCHASE INFO:
ACP/Xfile licences
User/Family/Business
http://rixstep.com/buy
About | ACP | Buy | Industry Watch | Learning Curve | Search | Xfile Test Drive
Copyright © Rixstep. All rights reserved.