About | ACP | Buy Stuff | Forum | Industry Watch | Learning Curve | Search | Test Drive
Home » Learning Curve » Developers Workshop

Hack Your Mac

Can they do it? Of course. Apple left the door open. And that's only the tip of the iceberg.

Get It

Try It

Apple devs have been working hard, it seems. Perhaps it's time they devoted a little time to fixing a number of long-lingering issues in their supposedly POSIX-compliant 'Rock Solid Foundation'.

Beyond the 'Dark Mode' which gives users a minimum freedom of choice, Apple offered increasingly convoluted APIs, whose purpose one can only fathom. Yet there are a number of very rudimentary issues with their system's behaviour, issues that didn't always exist, but crept in over time, and, despite reports coming in, are ignored to this day.

- It's no longer possible to opt out and in of showing extensions when saving files. Has no one noticed that this doesn't always work? Has no one noticed that Cocoa applications, via Info.plist, can accept files with any number of extensions? How in such case can a user see which extension will be used on saving? Or is there an unwritten assumption that no new files are ever created? Whoever signed off on this change in Mojave wasn't thinking straight, and/or found it impossible to repress an urge to return to the good old days when four-byte type codes reigned supreme.

- This 'file is locked' nonsense. It's never worked, still doesn't work, and never will work. What is it? It's a very amateurish attempt to get users past the almost nonexistent situation where a file is not marked for writing. What most users will of course do in such a situation is - change the file attributes! But this seems to have been rocket science for someone at Apple.

So the entire behaviour of the NeXT document controller was changed. Built originally to afford the possibility of intermittent failsafe saves, this technology was perverted to allow sidestepping the most basic of Unix file rules - namely that if a file is not marked for writing, then it's not to be written!

Of course there's a way around this - there's a way around everything. You could always... remove the original file and replace it with another? So the file has the same name but in fact is a brand new creation?

This is probably over the heads of the fanboys, who probably think this 'unlock' thing is the bee's knees. But it's not - for there's a catch.

What happens if the parent directory isn't marked for writing? Again, this most basic element of Unix filesystem intrinsics is probably over the heads of the fanboys, but there you go: you get stuck in a situation where the 'system' tells you something has to be adjusted with the file, when it's actually the directory that has to be looked into. The average user? The average user won't understand.

Mojave shows that the Apple devs have heard the criticism, but they're damned well not going to change their overall policy! Today you can - in some but not all cases - get a diagnostic that tells you something - gasp - is wrong not with your file but with your directory!

Question to these Apple devs: if you once thought it OK to offer people a way to 'unlock' a file, why don't you give them a way to unlock a directory? This is very basic IT for these times. Most users understand it. Most users understand more than they're given credit for by the HI group, who themselves seem to understand next to nothing.

- The tableviews. What a mess. Selections in GUIs follow the same rules, no matter the platform. Whatever you use to advance your caret or selection, hold down shift to get to the same place but also selecting everything in between. For multiple selections, use a designated key to begin a new selection (without removing the old selection). And so forth. Eminently simple. And accepted universally across the board.

Except at Apple. Once again, right around the time that Tiger segued into Leopard and the iPhone was announced. Apple's own selection management, which actually went a step further than anyone else's, became practically dysfunctional.

(Once again, a bit of hand-holding might be needed with fanboys who will of course rush to defend Apple, saying things like 'but this works great'.)

But these things did work once upon a time, and they worked on the current 'NeXT' platform, and mostly likely on the old 'MacOS' platform as well.

- Speaking of 'once upon a time': there's no viable filesystem management in the system. Gobs of embarrassing scandals over the years, and nothing changed. The NeXT filesystem management wasn't great, but it's better than what Apple have today. Once again, fanboys won't get it. Perhaps it's best to ignore. But no, there's no proper management. And this is why things like Safari Build 48 could happen, and why Tom Karpik's discovery could happen, and so forth.

Apple's filesystem is unorthodox in the extreme. Their approach makes it easier for their developers, much more difficult for application developers, and highly dangerous for end-users.

And traditionally Apple will do all they can to cover things up when accidents inevitably happen.

So we'll take it slow.

Normally when you want to copy a hive of files onto another hive, each file at the destination is opened for writing if it exists, then the corresponding file at the source is read, its contents copied to the destination.

This propagates all the way down the hierarchy. File by file.

But this requires the type of meticulous programming as found in the Unix modules. It requires meticulous attention to detail. It requires watching out for all types of mishaps, for blackouts, brownouts, what have you. Operations have to be enclosed in exception handlers. Nothing can be left to chance.

This is evidently too much for Apple, who instead take the cheap and easy way: they just obliterate the destination in its entirety, then copy in the contents of the source.

There are of course issues with this. No file found at the destination but not at the source will exist once the operation's complete. The type of user prompts found on other systems, on any system but Apple's, are nonexistent here. There can be important files buried down in the destination hierarchy, but you won't get a reminder about them. They'll be gone.

And this is only scraping the surface. NeXT inherited this thinking from Apple, and the open source GNUstep had to jump through hoops to avoid the worst of the evils. Not so with Apple: they just let that bad stuff happen.

GNUstep code is riddled with repetitive layers of checks, with the concomitant 'are you sure' messages, to make sure things like this don't happen. Old NeXT also did this - but once Apple started resuscitating their Finder, code was migrated all over the place, and the necessary interaction with the user was removed.

Things were so bad at one point that the hapless Finder escaped by the skin of its teeth: running subordinate processes that held onto target files, it was thwarted in completing self-destructive cyclical operations only because the subordinate processes kept fighting each other.

Serious file management indeed.

Then Tom Karpik discovered how badly the code had deteriorated...

- And:the:colons: how long is it now that we thankfully - officially at least - don't:have:colons:in:file:paths? That the colon is no longer used as a path component separator?

So why does Safari still replace colons with dashes on file saves?

Does anyone at Apple realise how batshit this is?

Why can't Apple just do the right thing? Do they still think that PR 'spin' is all they need to do?

When will they understand that, as things stand today, they have lost all respect in the wider Unix and open source communities?

What's a computer, Tim? If you don't know what it is, and if you seriously don't understand why anyone would even want one, perhaps it's time you turned over your position to someone who does?

And not everything can come back as crumbs off the iOS table. Your iOS platforms aren't selling as before. You need the mother system, and you know it.

So WTF are you doing?

The list is too long. Time and again, Apple took perfectly good NeXT code, based on perfectly good Unix code, and bastardised it. Perhaps a few people remember the outrage when they trashed DTrace. As one of innumerable examples.

That code they're using - it's good code, and it's free code. It's there for the taking. Just use it. Ah but no. No, because Apple fork everything. Everything. Remember when their 'sudo' was dangerously out of date? 'sudo' is a project with OpenBSD. But Apple first had to study that code and see where they'd already deviated, then try to put the bug fixes in.

Remember what Charlie Miller said? About how EASY it is to 'hack a Mac'?

You just go to this file:


And check the version numbers of all the modules. Then compare those numbers with the latest version numbers at the respective websites. Then, if there's a discrepancy, YOU STUDY THE CHANGE LOGS.

You see what vulnerabilities they've discovered, then you use that information to 'hack your Mac'.

Dead easy. And they know this at Apple. So WTF are they doing?

Oh yeah. Let's CODE-SIGN everything. That'll do it!

Except code-signing has precious little to do with user safety. It's all about the Benjamins. Knocked for a loop by the peaked mobile market, Apple need to keep revenues up. So they return to their old computer platform. And do they ever have plans for you!

That's worth a few billion a year. It'll almost compensate for the downturn in iPhone sales.

There's a way to build respect in the industry, Apple, and that's not it.

No Reason

No reason. There is no reason Apple can't be at the top of the heap in personal computers. The only thing holding Apple back is - Apple.

Going back to the early days of the 'merger', Apple had, thanks to NeXT:

- The best graphics on the planet. PDF effectively used for vector-based screen rendering with floating point coordinates, floating point RGB values, and a floating point 'alpha' channel for transparency. This came built in to the system, and you might remember when Microsoft tried to do the same thing. Microsoft and others still grapple(d) with 16-bit and 32-bit integers, no alpha, and not vector-based.

- A true objected-oriented, document-centric user interface, the best one in the world, based on the work of Alan Kay, who coined the term 'object orientation', had less than flattering things to say about the competition, and who became an Apple fellow. This interface is again unique. Gnome and KDE copied the Microsoft paradigm, thinking they were doing people a favour when they were doing the diametric opposite.

- A variation of Unix running a microkernel, based on work at Carnegie-Mellon University. This made Unix even more stable than found on other platforms, such as those based on Linux.

- Good taste. This is beyond 'user-friendly', it's a type of characteristic Steve Jobs often mentioned. Look at the KDE file manager to see the opposite. Things have to be as pretty and smooth as possible, and there are people at Apple who've known how to do that.

- No malware. Riffraff don't seem to care much, but this is highly important, as eliminating 99% of the malware, by putting Windows to sleep for good, would and still will make a sea change of a difference to the World Wide Web and the world around.

- An open goal as far as Microsoft was concerned. Microsoft didn't really consolidate their position until the release of Windows 98SE ('Second Edition'). Apple's new system was actually ready for release by then. But no. And what happened in the New millennium, only two years later? ILOVEYOU happened is what. ILOVEYOU and literally millions of malware strains that have plagued humanity ever since. What would things be like if Apple had made a 'dent in the universe' by May 2000?

- Open source. For this was open source at one point. And Rob Brown tried to get 'Open Darwin' off the ground. It's really not enough to open the kernel - things can be done to a system to undermine things from higher levels. Red Hat's open source. What would happen if Apple crowded Red Hat in their market?

See Also
Learning Curve: The Mouse and the Labyrinth

About | ACP | Buy Stuff | Forum | Industry Watch | Learning Curve | Search | Test Drive
Copyright © Rixstep. All rights reserved.