Wednesday, April 29, 2020

Not Dogfooding DriverKit

Phil Dennis-Jordan:

I’ve spent a fair bit of the last 2 weeks with DriverKit, i.e. macOS 10.15’s device-drivers-in-userspace tech. I really wanted to like it, but so far I’m not impressed at all. It’s yet another one of those things where Apple clearly has no intention of using it themselves.

[…]

The code signing situation is more awkward than it was for iPhone app development back in the iPhoneOS 2.0 SDK days. You have to disable Xcode’s own code signing step and run the codesign command yourself to even get anything to build and load.

Error messages are cryptic, non-specific, and hidden inside the firehose of the unified system log.

[…]

I don’t know whether that’s an exhaustive list of services for which to watch the ‘log stream’ because of course documentation is skeletal at best.

[…]

WWDC 2019 Session 702 claims that DriverKit makes developing drivers easier compared to kexts. Obviously I’m new to DriverKit, so I’m expecting a learning curve, but even once I get something working, I end up rebooting more often than with kexts.

Previously:

8 Comments RSS · Twitter

Sören Nils Kuklau

Note that the not dogfooding part turned out to be not entirely true:

Thanks to @tclementdev for pointing out that Catalina DOES ship with some dexts for some types of USB->serial and USB->ethernet adapters.

(It doesn’t excuse that Apple shipped an API in what feels like beta, while already discouraging users from tolerating apps that use the previous, more stable API. It does, however, mitigate the worry that Apple doesn’t even care about the new one.)

When a platform vendor ships a steaming pile, we shouldn't be reduced to arguing whether it's worse if they didn't test it or if they did. Craig is a brilliant guy but he has tolerated the dismantling and decay of the quality org that used to prevent this sort of thing. The inevitability of this dumpster fire was blatantly obvious to insiders years ago. But the stock price kept skyrocketing, so nobody cared.

Could anyone point to some decent quality software engineering from Apple over the past 5 years or so? I kept thinking about all the bad stuff and couldn't think of anything good.

@Ed They’re doing a good job with Swift.

Hasn't Swift been riddled with compiler bugs, poor code generation/tooling, byzantine/shifting syntax, and design-by-committee non-direction?

Sören Nils Kuklau

When a platform vendor ships a steaming pile

The inevitability of this dumpster fire was blatantly obvious to insiders years ago.

Hasn’t Swift been riddled with compiler bugs, poor code generation/tooling, byzantine/shifting syntax, and design-by-committee non-direction?

These don’t seem very… nuanced takes to me.

Apple software engineering can have massive quality control issues (I’m increasingly leaning towards: yup, that’s the case, and that’s on Craig) and solid success stories. Both can be true. APFS, Swift, Continuity, etc. all seem like good pieces of engineering if you can ignore quality issues.

As for complaining about the shifting syntax and design by committee: hard to find the right compromise between iron-fist development and an open-source community feel.

But the stock price kept skyrocketing, so nobody cared.

Finances may be one aspect of it, but I think the cause is, more generally, that success hides problems.

APFS, Swift, Continuity, etc. all seem like good pieces of engineering if you can ignore quality issues.

That's a pretty big caveat, and even then I don't agree. APFS and Swift feel like NIH attempts from dilettantes who think they're smarter than established experts.

Are either APFS or Swift universally faster or more stable than HFS+ or Objective-C, respectively? Do their designs/features match the state of the art competitors in their fields (BtrFS, Rust, Go, etc)? What filesystems other than APFS can't accurately report how much space is free? Is Swift achieving its goals of becoming widely adopted as both a high level general scripting language and high performance systems/server language?

Leave a Comment