12 ms·

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 alon

by Osmium 9y ago

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.

dilap 9y ago
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.)
- abakker 9y ago
  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.
  - derefr 9y ago
    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.
    - PhasmaFelis 9y ago
      > 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).
      - davrosthedalek 9y ago
        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.
        crispinb 9y ago
        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.
        kemitche 9y ago
        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.
        9y ago
- derefr 9y ago
  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?)
  - BlindMidget 9y ago
    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.
    - deleted 9y ago
      [deleted]
    - girvo 9y ago
      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.
      - not_kurt_godel 9y ago
        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.
  - dilap 9y ago
    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. :-)
  - threeseed 9y ago
    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.
- rconti 9y ago
  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.
- threeseed 9y ago
  3. It's just a bug. You know the sort of thing that happens to developers: Every. Single. Day.
  - dilap 9y ago
    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.)
  - brians 9y ago
    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?
- atdt 9y ago
  You'll find that ex-anything engineers tend to find their former workplace degraded in quality and talent.
davidkuhta 9y ago
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 https://news.ycombinator.com/item?id=15407114
- Dylan16807 9y ago
  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.
  - eradicatethots 9y ago
    There are no rules in soft dev
  - Osmium 9y ago
    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.
  - DonHopkins 9y ago
    Yeah, I think the problem is that they rewrote everything but the disk utility.
  - j45 9y ago
    I don't know if a rewrite is about whether it's large or small, it's about the years of hardening many scenarios.

by Osmium 9y ago

dilap 9y ago

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.)

abakker 9y ago
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.
- derefr 9y ago
  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.
  - PhasmaFelis 9y ago
    > 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).
    - davrosthedalek 9y ago
      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.
      - crispinb 9y ago
        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.
        kemitche 9y ago
        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.
        9y ago
derefr 9y ago
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?)
- BlindMidget 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - girvo 9y ago
    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.
    - not_kurt_godel 9y ago
      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.
- dilap 9y ago
  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. :-)
- threeseed 9y ago
  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.
rconti 9y ago
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.
threeseed 9y ago
3. It's just a bug. You know the sort of thing that happens to developers: Every. Single. Day.
- dilap 9y ago
  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.)
- brians 9y ago
  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?
atdt 9y ago
You'll find that ex-anything engineers tend to find their former workplace degraded in quality and talent.

davidkuhta 9y ago

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 https://news.ycombinator.com/item?id=15407114

Dylan16807 9y ago
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.
- eradicatethots 9y ago
  There are no rules in soft dev
- Osmium 9y ago
  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.
- DonHopkins 9y ago
  Yeah, I think the problem is that they rewrote everything but the disk utility.
- j45 9y ago
  I don't know if a rewrite is about whether it's large or small, it's about the years of hardening many scenarios.