Hacker News Reader

Comment by thought_alarm | Hacker News Reader

How did Disk Utility.app go from being one of the great built-in OS X utilities to the embarrassing amateurish shit show that it is today?

Perhaps the same people responsible for the file system engineering are also responsible for developing this user-facing application. They might excel at low level system engineering, but they are utterly unqualified to develop a high level GUI application.

Spend 5 minutes with the app and you'll find a half dozen bugs and amateurish mistakes. It's baffling, and it's been a problem for two years now.

View on HN

There have been a few cases like this. Presumably the original was created/maintained by just one person, they move on, and then when the next person comes along they decide it's easier to re-write than modify the old code. But they don't have sufficient time and the new version is inferior to the old.

Bear in mind the old version did need to be updated (new CoreStorage features, has to handle Fusion drives, now APFS).

I get the sense there's a lot of shuffling between teams in Apple, and teams are a lot smaller than you'd expect, and this is the inevitable result. The advantage (I'm guessing) is that they get to move quickly, and it reduces bureaucracy/politics, but ... yeah, this isn't great.

At least diskutil is still there, and is as powerful as ever.

1. dont have the same depth of dev talent they used to 2. mgmt that isnt as sensitive-to and focussed-on quality.

(this is 75% speculation on my part and 25% confirmed by conversations with 2 ex-apple engineers.)

I wonder if they just don't have enough power users of the OS left that aren't also just developers using CLI? ANY power user of the OS itself has seen a ton of head-scratching changes over the years, and I figure that the product managers just don't know who the features were for or what they're used for.

Is there a reason that the macOS CLI can't be intended as a general power-user feature, not just a developer feature?

Consider: Terminal.app comes with macOS, not with Xcode. If the BSD environment was just there for developers, would this be true?

Today's Microsoft seems to increasingly think sysadmins would rather use PowerShell than MMC snap-ins; I'm inclined to think that today's Apple is similar. And there's nothing inherently hard about CLI interfaces; "regular people" used MS-DOS PCs for ~two decades.

I would bet Apple just thinks the CLI is the optimal Human-Computer Interface for doing some things.

> And there's nothing inherently hard about CLI interfaces; "regular people" used MS-DOS PCs for ~two decades.

CLIs are opaque by definition. With a GUI you can click around menus until you find what you're looking for; with a CLI you can't even begin unless you already know what you're doing. Man pages are no help to newbies; they're either uselessly terse, impenetrably jargon-packed, or both.

It's probably possible to make a CLI that's relatively easy-to-use and newbie-friendly, but I've never seen anyone attempt it. People used MS-DOS for years because it was the only way to access the large majority of software, and abandoned it as soon as there was a viable alternative (Win9x).

I would argue that small command-line tools "the unix way" combined with a competently written -h help page is quite discoverable. Maybe not for a general computer newbie, but certainly for people used to /other/ cli tools.

This only seems to work in practise for tools that are very small, otherwise exceptional writing is required (which, by definition, will rarely occur). I can't imagine (to pick a particularly extreme example) that anyone has ever learned to use git by reading the man pages.

In contrast, even features in pretty poor GUI apps are by default generally discoverable.

I shudder to think how hard it would be - likely impossible - to use a bad git GUI if I didn't already know many of the git CLI commands.

Even just, say, MS Word. If I don't know a feature exists, clicking around through dozens of menus isn't going to get me anywhere. For both CLI and GUI, Google or official docs are the only reasonable way to discover.

> If I don't know a feature exists, clicking around through dozens of menus isn't going to get me anywhere.

I find that clicking around through menus often teaches me about great features I didn't even know I wanted.

Regardless of the cause, in practice, I find that it's much easier to get basic functionality out of a new-to-me GUI app than a CLI app. That may not be a fundamental properly of CLI, but it certainly is how all significant CLIs are written.

So absolutely with you on this. Exploring visually is best for me as well.

Yep! I have nothing against CLIs, but imagine starting with the CLI in something like CAD. Sure, they have CLIs, but wow would that be hard.

Without google, I'd have never learned any CLI stuff, and even as it is, I have no idea why the flags can't just be words instead of letters.

The ssh man page is truly awful. I managed to read through it multiple times without finding the functionality I wanted, even devoting special attention to a section that turned out, later, to be purportedly "documenting" exactly that functionality.

This is why I usually only use man pages to reference a command-line option or as a quick reference. If you're new to a tool, a quick web search finds a much more informative tutorial which saves you time, despite being more verbose.

Quite. And surely this is how pretty much everyone gets started with things like git?

Conversely, novice use of even complex GUI apps rarely requires looking up a tutorial first, because you generally can just click or tap around and at least figure out minimally how to use it.

Inexpert users (ie. nearly everyone) stop there. Obviously further reading is needed to make more extensive and/or efficient use of any tool. But at that point in my opinion we're beyond the reasonable boundaries of 'discoverability'

For svn and specifically git GUIs with lots of options and insane defaults, I usually do not have a fcuking clue what exact command will yet another cool wrapper execute and how it will report back. Too many times I fought the result of people clicking around and completely messing the repo with no idea what they’ve exactly done. So, our company has a simple but strict rule: you’re allowed to update/pull/commit/push via gui, but nothing more and never touch any checkboxes in there.

If you can’t spend time on one of your main tools docs to grasp what “merge -r 403:480 -c -473 ^/branches/rt0” does and how to command it, then sit there and code, folks will do maintenance for you.

The parent was about discoverability -- you've argued that discoverability isn't necessarily useful for tools where people need to have some idea of what the tool is doing. There are many tasks where the user needs to have an accurate mental model and a grasp of the details. I completely agree with that.

Still, GUI programs are very clearly more discoverable than cli ones. How far and where discoverability is the best approach to educating a user is a separate question.

>where people need to have some idea of what the tool is doing

Not exactly. Wrappers can (and tend to) “enhance” and hide details from those who actually have idea. This kind of breaks discoverability into confusion, that’s what my rant was about.

>I can't imagine...that anyone has ever learned to use git by reading the man pages.

Perhaps not, but they easily could. The Description section at the start of the man page says:

"See gittutorial(7) to get started, then see giteveryday(7) for a useful minimum set of commands."

And if you do `man gittutorial` it has, as you might expect, a tutorial on how to get started with git.

In theory, sure, but I've never seen a competently written -h page.

When MSDOS was in active use computers in general were used by a much smaller section of the population. That could well be because many people didn't get on with a CLI and Macs, at the time, were really expensive.

To counter that with an example of what I consider really good man pages look git.

I've learnt loads about rebasing, etc. from the examples in the git man pages.

Personally I've always loved a good CLI.

I've always thought of Apple as one of those black holes that absorbs devs: people land there, and then—if they can hack the culture—tend to stay for their careers.

Is this not true any more? Where does ex-Apple dev talent tend to go? (Microsoft? Indie app development?)

Honestly all the great apple devs from the early 2ks have either moved into consulting or entrepreneurial activity or, more likely and worryingly, they've been promoted into management roles at apple where they're managing a team of engineers not quite as good as they were. You see this everywhere, at every company. That's my guess.

Are you seriously arguing that engineers were better “back in the day” and engineers now are not as good? Surely I must be misunderstanding you.

The talent pool of engineers capable of propelling a company technologically forward the way Apple was "back in the day" is by definition very shallow. He's not saying engineers are better, it's just a selection bias.

Dunno, but it would make sense. Huge apple success post iPhone + exploding tech scene provide a ton of opportunity/temptation to leave.

Anecdotally, Chris Lattner is a high-profile recent departure. :-)

I worked at Apple as a developer. I just went to another company just like everyone else does.

I know lots of people who have spent their entire careers there because the work is challenging and interesting. I also know teams that handle anonymous backend infrastructure e.g. AppleID or ADC where there was higher turnover.

No different to any other company.

From the people I know at Apple, there are lots of HUGELY talented people there. That said, they're bigger than ever, and I'm sure there are plenty who are just hiding out trying to while away their career. And some teams are much, much better and more highly responded than others.

3. It's just a bug.

You know the sort of thing that happens to developers: Every. Single. Day.

I opened the App Store just now to see if a few lack-of-polish bugs were present. The screen flickered a couple times and then was nothing but white and a loading spinner. Waited 30 seconds, never went away.

Force quit, reopen, loads fine.

Go to the Today tab. Scroll through. Notice that sometimes your scroll doesn't get registered. Why? Because if you try to scroll over an "Open" or "Get" button, it steals the event and breaks your scrolling. Amature mistake, and the kind of detail Apple used to always get right.

Watch OS SDK: When the user performs an action on a notification that arrives on the watch, it calls a callback on the application on the phone. What happens if the user's phone is not reachable? The action just gets dropped on the floor, and to the user the app looks buggy. (Maybe/hopefully this is fixed in the latest version of watchOS; I haven't checked.) Flawed, poorly thought out API design.

Go to the updates tab on the App Store app. Pull down to refresh. No updates, but the "Available" headline disappears and then weirdly reveal-animates back into place, an overall feeling of flicker.

Huge issues? No, but a very real drop-off in quality and polish from what Apple used to put out.

(The password bug is a little different -- obviously bugs can and do happen. But not having a testing procedure in place for the core paths through a piece of software is a huge process failure, especially for something critical like security. Every release of the software should have testers going through a plan like, "enter password hint. attempt to access volume. verify password hint is correctly shown." &c.)

(Also, to be fair, I think after taking a huge dive the quality of Apple software seems to be slowly ticking up again.)

Nah. It’s a bug in a critical security system that made it to release. It should have been caught by automated testing—can you grep for the password, or decrypted volume encryption key, in an encrypted filesystem? When you change the password, does anything change other than the encrypted VEK? It shouldn’t!

These are in the first page of tests I’d write. NIST SP 800-111 asks for forensic pre-release testing—can you really believe such happened here?

This isn’t a failure of the engineer who wrote out the wrong buffer. Everyone makes mistakes like that. It’s a failure of the Engineering culture and engineering management that shipped without reasonable testing, or manual pre-release examination. It’s a failure of the culture that accepted bugs like this, rather than asking (appropriately, for an Apple FDE product): let’s assume that it will cost someone $1B or a thousand lives if this fails. What should we do to assure its correctness?

You shouldn't accept mediocrity instead of correct software. They are worlds apart.

There is a significant difference between a bug and a severe security error regarding basics.

You'll find that ex-anything engineers tend to find their former workplace degraded in quality and talent.

I was just reading about something similar in the "Ask HN: What essay/blogpost do you keep going back to reread?" post

Joel Spolsky's point: They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

https://news.ycombinator.com/item?id=15407114

I reject that comparison. This is not rewriting a core product with tens of millions of lines of code. This is a small utility program. It's very often no problem to just make a new utility program. Especially one that's in the single digits on how many coder-months it costs.

There are no rules in soft dev

Yeah, I can see how a rewrite makes sense. It's not rewriting diskutil itself, it's adding a new UI, that presumably uses newer APIs that will be easier to maintain in the future.

The problem really is that the new Disk Utility is a minimal viable product, rather than an app that can actually do everything the diskutil command line utility can do.

And then you have terrible bugs like this, which is presumably a non-security engineer writing a bit of UI code that they shouldn't be. I doubt this bug actually came from the APFS encryption itself.

Yeah, I think the problem is that they rewrote everything but the disk utility.

I don't know if a rewrite is about whether it's large or small, it's about the years of hardening many scenarios.

A simple utility doesn't need that much hardening against corner cases, and in this instance the bug is a main use case.

> They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

Statements like that, while powerful are dangerous as they turn into baseball bats for people to hit each other with.

And they become an excuse for ignoring things and becoming an absolutist religious zealot.

There are legitimate cases where rewriting the code from scratch can be the single BEST strategic decision.

(And of course, vice versa)

If I have strong rational reasons to believe that a rewrite is warranted quoting Joel Spolsky or anyone else is not going to change my mind.

>...as they turn into baseball bats for people to hit each other with

I will quote you a lot from this time on. It is such a true and widely applicable judgement.

> Statements like that, while powerful are dangerous as they turn into baseball bats for people to hit each other with.

I love that analogy.

I see it again and again with so many of the "classics" - phrases like "premature optimization is the root of all evil" and "adding manpower to a late software project only makes it later". Sure, these statements are right more often than not, but the zealousness with which they are often applied leads to an enormous amount of mistakes.

There ARE cases in which optimizations aren't premature. System architecture is all about designing a system for optimal performance in some area or another. And in some cases, bringing in more people to a late project can speed things up.

I really don't get why they have allowed this crippled GUI for so long. I understand that they want to make it simple for low level users, but that seems like a bad excuse in this case as low level users aren't even going to use Disk Utility, just like they aren't going to use Automater. It shows a blindness to their market, i think. Anybody who is on my "free IT" list for the last few years has been receiving a Mac when it's time to upgrade. The tech support is night and day, and problems are easy to fix thanks to built in, easy to use screen sharing, a robust OS, and well rounded modern hardware. At the same time I'm not a unix guru, I don't know Bash that well and when I'm forced to use it I spend a lot of time reading. I hate that they keep hiding more and more commands behind Bash precisely because it makes it significantly more difficult to do what I'll call "prosumer IT". One of the things that really sold me on Macs was when Disk Utility managed to repair a USB that was completely bricked on my windows machine. As of MacOS Sierra, I now have use bash to fix corrupted drives as they aren't displayed in the GUI. Such a pain and such a step backwards.

There are times that installing macOS requires a trip through Disk Utility, is why. Disk Utility.app is basically made for the single use case of "modify the system to make macOS installable."

The thing to understand, is that everyone inside Apple uses diskutil(8), not Disk Utility.app. diskutil(8) is the "canonical" way to do almost everything related to Disk management on macOS, the same way diskmgmt.msc is on Windows. Everything else is a secondary "convenience" view to just allow certain workflows (like installing macOS without overwriting things, or unlocking a FileVault volume with a master password to install macOS on it) to be accomplished more easily—like the Properties view of a disk drive in Windows.

If there are other "convenience views" of disk management that you think would be helpful, why not make them into an app and sell it? One my favourite macOS programs, DaisyDisk, is basically just such a convenience view. People are willing to buy these—especially as a gift for their "prosumer" friends. Apple can't predict every use-case that a prosumer might want an accelerator for, but the free market probably can.

diskutil(8) is not that great either. Like reading passwords from the terminal without bothering to turn off echo.

> I really don't get why they have allowed this crippled GUI for so long.

You explain it perfectly yourself:

> Anybody who is on my "free IT" list for the last few years has been receiving a Mac when it's time to upgrade.

As long as you still prefer Macs over anything else, Apple has no incentive whatsoever to be any better. They merely have to be just good enough for you not to switch and keep using macOS/iOS/etc.

The old version of Disk Utility must have been pretty nasty to justify a full rewrite. I remember it getting quite unreliable at some point around 10.7 when with reading/writing disk images. Partly because the UI relied on non-obvious drag & drop / modifier key mashing to do certain things and it didn't have much error handling to clearly explain what went wrong. It wasn't even that good at explaining what operation you were about to perform. The new version (supplemented by using diskutil for advanced stuff) is an improvement in my opinion.

> low level users aren't even going to use Disk Utility,

Strong disagree. One of the first troubleshooting steps for 'My Mac is slow/unstable/pinwheeling etc is - Run Disk Utility and check/repair your disk.

One of the most-common complaints that I see about Apple is that they have allowed macOS' quality to steadily decline and the most-common speculation has been that this declination in quality is because macOS makes Apple less money than iOS.

The iOS-using products are Apple's cash cow. It does make sense that they'd prioritize working on iOS. However, what doesn't make sense is that Apple certainly has enough resources to work on both OSes. It's not like they don't have enough money to hire good developers.

That is the complaint, however. It makes some sense, except that Apple could easily afford to invest in both macOS and iOS.

Manglement seems to have collectively forgotten that iOS app quality is dependent on macOS and tooling quality. Improve macOS, you put a lightness in devs' steps everywhere and iOS apps get even better.

It seems that macOS has gotten completely bogged down (like really, really bogged down) and mired in bureaucracy.

What I just described is a "little thing" that's very very hard to quantify to non-engineers, sadly.

(I recently learned (I have no exposure to Apple, I'd like to but their stuff is expensive!!) that you can't just "go ahead and upgrade Xcode", but that you have to do it in a very specific/esoteric way or you break absolutely everything, and that it's not unreasonable sometimes to just nuke macOS from orbit and green-field reinstall everything.)

That last paragraph will seem familiar to anyone running prior versions of Windows... What an ironic turn of events!

Xcode is just an app (minus some bits shared with iTunes). What problems are you having updating it?

MacOS is a dead end, iOS is clearly where Apple is converging and you'll shortly see ARM laptops from Apple shipping iOS. It's only a matter of time before their flagship productivity-oriented products are running iOS.

iOS' stability and quality have declined as well. I've encountered a number of glitches and bugs on the iPhone that I don't usually expect from Apple.

Some of them are sloppy glitches in functionality or display, others have to do with poor stability (force closing more often). Never encountered any of these issues on iOS a few years ago.

Desperation creates grasping feature creep.

Does anyone remember the MacTCP control panel?

It looked like an eager bright eyed bushy tailed summer intern did it in their spare time to impress their manager who had never heard of this Internet thing before, but who then couldn't get the rest of the company to buy into this weird TCP/IP thing, because it was distracting customers from using LocalTalk like they were meant to. But then they shipped it anyway, but never updated it after the intern left at the end of summer.

http://www.simonstl.com/projects/tcpip/mac/mactcp.html

I get the same vibe from the current Terminal Preferences Profiles dialog, whose window you aren't allowed to resize, and which has the fixed size scrolling list of configurations, fixed width run command input field that doesn't let you see the whole command and makes it hard to edit, and many other cramped fields, whose labels are all clipped and scrolled, even when you click on them to edit the labels.

Why the FUCK does anyone (ESPECIALLY Apple) use tiny fixed sized windows jam packed full of cramped tabbed and sub-tabbed dialogs with nested vertically scrolling lists of horizontally scrolling text fields, in these days of gigantic screens?

Lights are on but nobody's home!

Yup. Same deal with the side panel in service preferences. The only way to even see the full name of a service beyond "[Thunder...thernet]", if it's longer than about 10 characters, is in the title bar of the Advanced settings pane.

It's the iOSification of OS X. Sadly the whole OS is going in that wrong direction. I would like to know how many folks are working on MacOS vs iOS. Would put things into perspective.

Hard to imagine that anyone at Apple sees MacOS (or the Mac in general) as a promising career path. All the 'A' players are either working on the iOS platform and devices, or have cashed out completely.

Especially with the move toward forced open-plan workspaces in the new campus, I suspect Apple is going to have serious problems attracting and retaining key talent in the years ahead. They are reaching the point where stock options will no longer be a strong incentive due to lack of upside potential.

That’s funny. Disk Utility is the successor to Disk First Aid, which has been available since the mid-80s. It’s not the iOSification; it’s deep Mac tradition.

Some genius decided they had to rewrite it. The current iteration looks like an intern shitshow rewrite, this bug included.

More evidence supporting this: the new Disk Utility.app seemingly has absolutely no way to recover from a fusion drive being split up into an HDD and SSD (made a mistake partitioning it) -- you have to do it from the command line.

On the contrary, I booted the exact same machine into internet recovery (which gave me the Mavericks-era Disk Utility.app) and it literally had a huge warning that the fusion drive was partitioned incorrectly, and a repair button.

Why remove important features that still (have to) exist in the underlying utility? Like this is literally an operating system designed to run on only a handful of hardware, which is why people like it.

But it looks very sleek now, with big graphs and fonts for the crucial information.

Idono. HFS+ is pretty terrible, too. The people who wrote it surely could've written Disk Utility.

That fucking pie chart partition allocation bullshit. Christ almighty.

The pain it inflicts upon me... Ever since that thing appeared it's been horrible. It errors if you look at it wrong, and who knows what it's really doing?

Sounds like it was built by people who couldn't make the cut for the Windows iTunes team.

Reply on news.ycombinator.com