Big Safari & Kernel issues fixed in iOS 16.3.1, macOS 13.2.1 updates

Next comes the “I hope it fixes... the issue I’ve had for years but Apple won’t acknowledge” comments.

lkrupp said:

Next comes the “I hope it fixes... the issue I’ve had for years but Apple won’t acknowledge” comments.

It feels “snappier”, is that better? 😎

I wish Apple would consider starting over like Google Fuchsia - a modern take on a posting system with new security considerations architected from the ground up.

All of these issues are garden variety programming errors that have been plaguing software quality for decades, like accessing memory that’s already been freed and failing to sufficiently verify input parameters. In my opinion, one of the root causes of the perpetuation of these fundamental programming errors is the difficulty human brains have with dealing with the complexity introduced as a result of multiprocessing and concurrency in applications and operating systems.

In other words, it’s difficult enough for a programmer to mentally keep track of all of the “accounting” related to the memory management, state management, persistence, volatility, privacy, security, exception handling, etc., for a single threaded user mode application. You know, making sure all the ‘i’s are dotted and all of the ‘t’s are crossed and how it relates to the underlying operating system. But in most cases eventually getting everything dealt with in these relatively limited cases is resolvable, often by brute force. When you add in multiprocessing, threading, concurrency,  loss of atomicity with context switching, etc., the ability of most human brains is quickly overwhelmed. Practicing good accounting and hygiene from a single threaded perspective is no longer sufficient when you step into a multiprocessing environment. Brute force testing no longer works, largely because the humans driving the testing don’t fully understand every angle from which to apply the force, whether surgically directed or brutish. They don’t know what they don’t know.

In much the same manner, programming successfully in an environment where privacy and security were not within the sphere of concern pretty much guarantees that the artifacts of those efforts are going to fail miserably where security and privacy is a real concern. Nowhere is this more apparent than in legacy code. A lot of the underpinnings in the most popular current computing environments is legacy code that’s considered to be, at some level, “not broken” and thus not to messed with. Try asking an engineering director for time, money, and resources to dig around in existing “working” code to look for problems rather than applying all that expensive things to building new product features. They may say “no problem” - about 5% of the time. Truth be told, they’ve probably had some bad outcomes in the 5% cases. So the legacy code lives on. I’d imagine that some of the legacy code in macOS, iOS, etc., that traces its roots back to OS X, NextStep, and Unix is older than the engineers who are currently maintaining that legacy code.

The current complexity of the not only multiprocessing but also highly distributed computing means that humans are effectively unable to fully understand whether their applications are correct, secure, resilient, crash resistant, etc. Too many moving parts, any of which can break or be broken by anyone who starts poking at them long enough to discover their weaknesses. This is clearly an area that requires additional help.

My hope is that forward thinking companies will look at AI, ML, and similar technologies and techniques to improve software quality by overcoming some of the limitations of human cognition in these narrow domains. Sure, it’s not sexy or exciting like human-like chat bots or other such AI applications, and it will never be perfect, but until we get to the point where we can actually trust the software we depend on, we’ll always be waiting around for the next mole that needs to be whacked. The wait won’t be long, it never is, especially for the folks who actively search for moles.

dewme said:

All of these issues are garden variety programming errors that have been plaguing software quality for decades, like accessing memory that’s already been freed and failing to sufficiently verify input parameters. In my opinion, one of the root causes of the perpetuation of these fundamental programming errors is the difficulty human brains have with dealing with the complexity introduced as a result of multiprocessing and concurrency in applications and operating systems.

In other words, it’s difficult enough for a programmer to mentally keep track of all of the “accounting” related to the memory management, state management, persistence, volatility, privacy, security, exception handling, etc., for a single threaded user mode application. You know, making sure all the ‘i’s are dotted and all of the ‘t’s are crossed and how it relates to the underlying operating system. But in most cases eventually getting everything dealt with in these relatively limited cases is resolvable, often by brute force. When you add in multiprocessing, threading, concurrency,  loss of atomicity with context switching, etc., the ability of most human brains is quickly overwhelmed. Practicing good accounting and hygiene from a single threaded perspective is no longer sufficient when you step into a multiprocessing environment. Brute force testing no longer works, largely because the humans driving the testing don’t fully understand every angle from which to apply the force, whether surgically directed or brutish. They don’t know what they don’t know.

In much the same manner, programming successfully in an environment where privacy and security were not within the sphere of concern pretty much guarantees that the artifacts of those efforts are going to fail miserably where security and privacy is a real concern. Nowhere is this more apparent than in legacy code. A lot of the underpinnings in the most popular current computing environments is legacy code that’s considered to be, at some level, “not broken” and thus not to messed with. Try asking an engineering director for time, money, and resources to dig around in existing “working” code to look for problems rather than applying all that expensive things to building new product features. They may say “no problem” - about 5% of the time. Truth be told, they’ve probably had some bad outcomes in the 5% cases. So the legacy code lives on. I’d imagine that some of the legacy code in macOS, iOS, etc., that traces its roots back to OS X, NextStep, and Unix is older than the engineers who are currently maintaining that legacy code.

The current complexity of the not only multiprocessing but also highly distributed computing means that humans are effectively unable to fully understand whether their applications are correct, secure, resilient, crash resistant, etc. Too many moving parts, any of which can break or be broken by anyone who starts poking at them long enough to discover their weaknesses. This is clearly an area that requires additional help.

My hope is that forward thinking companies will look at AI, ML, and similar technologies and techniques to improve software quality by overcoming some of the limitations of human cognition in these narrow domains. Sure, it’s not sexy or exciting like human-like chat bots or other such AI applications, and it will never be perfect, but until we get to the point where we can actually trust the software we depend on, we’ll always be waiting around for the next mole that needs to be whacked. The wait won’t be long, it never is, especially for the folks who actively search for moles.

From what I've followed, AI or ML (or however you prefer to call it) are definitely where part of the solution lies.

Abstraction is obviously another angle but if you are abstracting to compilers (AI enhanced or otherwise) I suppose it could make programmers 'lazier' (like when we write text and expect the corrector to pick up on not only spelling but grammatical errors).

New languages or supersets of existing languages seem to be popping up too. Supposedly making programming itself easier although programmers of a certain generation tell me it makes programmers 'dumber' ha!

Luckily, I'm not a programmer. All I can do is listen to people who do it for a living and observe that there seems to be easy way to bring quality software to market without a disproportionate amount of holes in it.

Apple is trapped on the wheel and no matter what, a new major version of macOS and iOS have to roll out every year. With that in mind, slowing release cycles down would help to a degree.