In a few years, you’ll be cruising along in your Apple car, if rumours are to be believed, and it will suddenly shut down. No warning lights, no messages, just no power and no response to its controls. Then it will spontaneously restart, pick up where it left off, and carry on as if nothing had happened.

If it’s anything like OS X El Capitan, that will be the case.

For this week it has gradually dawned on me that is what my iMac is doing, every 2-5 days. Of course being a mere computer, rather than a car with all its safety concerns, it isn’t really that serious, is it? If it did it a couple of times, perhaps not. But having done so since I upgraded to OS X 10.11.4 back in March, it has become seriously tedious.

No matter where you look, for once opinion is agreed that kernel panics and complete collapse of an operating system should be extremely rare. In fact, they should never really happen at all. One occasional excuse is a hardware failure, such as duff memory, which should be revealed by running hardware diagnostics. We have, those of us who suffer these freezes, we have, and they report that everything is working normally.

What Apple prefers to call an ‘unexpected restart’, which everyone else knows as a kernel panic, now seems to work as follows:

1. Out of the blue, the Mac becomes completely unresponsive, or ‘freezes’. The clock stops, pointer and keyboard are locked, and Magic Trackpad 2 models cease to ‘click’.
2. After a period of a minute or so, the screen goes black, and the Mac restarts.
3. When it restarts, no alert is displayed to inform the user that was a kernel panic.
4. No panic log is written, and therefore no report of the kernel panic is sent to Apple.

This breaks the established process for handling such events, violates the principles of good interface design, and makes it well nigh impossible for even the highly knowledgable user (or sysadmin) to diagnose the cause of the kernel panic.

In OS X 10.2 to 10.7, when a kernel panic occurred, OS X attempted to inform the user of that event. When the operating system is badly borked, this doesn’t always work, of course, but by and large most panics were identified as such by the distinctive alert which was displayed. Removing that from OS X 10.8 was wrong, and leaving it removed perpetuates that error. The OS must always try to keep the user informed of such serious issues.

It is, though, good design that modern Macs automatically restart after a while, which saves the user having to fumble around trying to do that themselves.

Once restarted, OS X should then generate a kernel panic log. That is not always an easy matter, but again this was quite a reliable process until recently. Without some indication as to what caused the panic, anyone – including Apple and its Genius Bar staff – has an almost impossible task to work out what happened, thus how to try to prevent further panics. My logs just go completely blank until the restart is announced in the entry BOOT_TIME, which marks the beginning of the startup process.

The fact that even one Mac does this should be a matter of great concern. It demonstrates a series of fundamental flaws in OS X El Capitan, no matter what is causing the kernel panics. Today it is my iMac, tomorrow it could easily be your Mac which manifests the same design and coding errors.

These are compounded by lack of documentation, and by Apple’s startling failure to maintain even its developer documentation. The support information given to users is inadequate and imprecise, and that given to the knowledgable is several years out of date. Once again these demonstrate failures in process: when the OS X engineers changed the handling of kernel panics, that should automatically have triggered rewriting of the documentation, which should always accurately reflect reality, not some superceded ideal.

With no news of any beta-releases of OS X 10.11.7, it looks as if Apple is steaming straight ahead for macOS Sierra, whose kernel should already be pretty well finished. I hope that these mistakes are not going to be perpetuated.