6 ms·

While it's tolerable to have engineers jumping between projects in, say, web frontend, I'd imagine that operating system security work is incredibly sensitive t

by btown 9y ago

While it's tolerable to have engineers jumping between projects in, say, web frontend, I'd imagine that operating system security work is incredibly sensitive to programmer context-switching - you can't dive deep into the security model of a desktop system in your 20% time when you're working with an entirely different system (with a different CPU architecture) in your 80% time. Of course there will be some specialization on this team, but it doesn't seem to be nearly enough. Unfortunately, it will take something like a botched release (not just a security problem) and heads rolling to reverse this trend.

derefr 9y ago
Most of the codebases of both iOS and macOS are fundamentally the same kind of (low-level but architecture-independent C and Objective-C) code, and encouraging team unification will make that even more true—if the same people are working on both AppKit and UIKit, for example, it's a no-brainer to unify them rather than maintaining that duplication. The exception is the kernels and drivers of each OS, which have to consider things like architecture, but I would expect that it'll still be the same individual engineers working on these who always have, no matter what their team structure looks like now. Whether or not Apple has a formal "macOS kernel team" or "iOS kernel team", those groups definitely exist and have rather static membership. (In fact, one main benefit you might see from this is that Apple has hardware hires—many from Intel[1]—who have stepped up to apply their knowledge of formal verification methods to the iOS kernel and drivers, but haven't necessarily had the flexibility to spread that love to macOS. That can change now.) [1] https://danluu.com/cpu-bugs/ https://danluu.com/cpu-bugs/ (search for "Apple")
- msie 9y ago
  Duplication of effort is something that a small company may worry about but Apple has boatloads of money.
  - saurik 9y ago
    It isn't just "we coded it twice" (which I would still argue is bad from a security perspective with respect to making sure both are actually correct), but "we both designed an API to solve the same kind of problem... different... so now the world has two APIs to learn on these weirdly different platforms when, by all rights, we should have just designed one".
real_estate 9y ago
Look, who is in charge? It is either Ive or Cook, or both, right? Do either of them have any experience with software design? One is good at making physical things look pretty, the other at large quantities of physical things to the proper location. I miss Steve.
threeseed 9y ago
Not sure if you're familiar with how iOS/OSX works. For the Darwin team which is the actual core OS they would have to deal a lot with CPU architectures. But they again they have always dealt with this since back in the NeXT days. ARM and x86 isn't a big deal to manage and there isn't much evidence that something is wrong in that area. For the UI teams i.e. System Frameworks, Cocoa, WindowServer etc. They are abstracted away from worrying about CPU architectures and they are the ones responsible for all the bugs we are seeing today. You can argue context switching is an issue here but again we don't have much visibility that iOS/OSX engineers are jumping back and forth every day.
- djsumdog 9y ago
  So which team might have screwed up here? Is this a UI issue or a backend/system library issue? What about the previous root account unlock issue?
  - threeseed 9y ago
    I actually put the blame on Agile. A few years ago there was a noticeable increase in the frequency of point updates at the expense of quality. In agile, testing either (a) relies heavily on automation or (b) only tests that particular story. In highly complex systems that's often not sufficient and rarely do security teams for example involve themselves on a per story basis. Personally I think the industry as a whole needs to sit back and realise that Agile wasn't the panacea it was made out to be.
    - ams6110 9y ago
      Well, more specifically the issue is that unit-testing alone is not enough. At some point you have to test the entire system as a whole.
      - h_r 9y ago
        I don't think agile practices preclude running regression suites throughout the development cycle.

by btown 9y ago

derefr 9y ago

Most of the codebases of both iOS and macOS are fundamentally the same kind of (low-level but architecture-independent C and Objective-C) code, and encouraging team unification will make that even more true—if the same people are working on both AppKit and UIKit, for example, it's a no-brainer to unify them rather than maintaining that duplication. The exception is the kernels and drivers of each OS, which have to consider things like architecture, but I would expect that it'll still be the same individual engineers working on these who always have, no matter what their team structure looks like now. Whether or not Apple has a formal "macOS kernel team" or "iOS kernel team", those groups definitely exist and have rather static membership. (In fact, one main benefit you might see from this is that Apple has hardware hires—many from Intel[1]—who have stepped up to apply their knowledge of formal verification methods to the iOS kernel and drivers, but haven't necessarily had the flexibility to spread that love to macOS. That can change now.) [1] https://danluu.com/cpu-bugs/ https://danluu.com/cpu-bugs/ (search for "Apple")

msie 9y ago
Duplication of effort is something that a small company may worry about but Apple has boatloads of money.
- saurik 9y ago
  It isn't just "we coded it twice" (which I would still argue is bad from a security perspective with respect to making sure both are actually correct), but "we both designed an API to solve the same kind of problem... different... so now the world has two APIs to learn on these weirdly different platforms when, by all rights, we should have just designed one".

real_estate 9y ago

Look, who is in charge? It is either Ive or Cook, or both, right? Do either of them have any experience with software design? One is good at making physical things look pretty, the other at large quantities of physical things to the proper location. I miss Steve.

threeseed 9y ago

Not sure if you're familiar with how iOS/OSX works. For the Darwin team which is the actual core OS they would have to deal a lot with CPU architectures. But they again they have always dealt with this since back in the NeXT days. ARM and x86 isn't a big deal to manage and there isn't much evidence that something is wrong in that area. For the UI teams i.e. System Frameworks, Cocoa, WindowServer etc. They are abstracted away from worrying about CPU architectures and they are the ones responsible for all the bugs we are seeing today. You can argue context switching is an issue here but again we don't have much visibility that iOS/OSX engineers are jumping back and forth every day.

djsumdog 9y ago
So which team might have screwed up here? Is this a UI issue or a backend/system library issue? What about the previous root account unlock issue?
- threeseed 9y ago
  I actually put the blame on Agile. A few years ago there was a noticeable increase in the frequency of point updates at the expense of quality. In agile, testing either (a) relies heavily on automation or (b) only tests that particular story. In highly complex systems that's often not sufficient and rarely do security teams for example involve themselves on a per story basis. Personally I think the industry as a whole needs to sit back and realise that Agile wasn't the panacea it was made out to be.
  - ams6110 9y ago
    Well, more specifically the issue is that unit-testing alone is not enough. At some point you have to test the entire system as a whole.
    - h_r 9y ago
      I don't think agile practices preclude running regression suites throughout the development cycle.