6 ms·

> it seems like Apple isn’t taking as much care as required on security and stability on the Mac It's even worse than that according to[0] Mark Gurman[1]: In

by miles 9y ago

> it seems like Apple isn’t taking as much care as required on security and stability on the Mac It's even worse than that according to[0] Mark Gurman[1]: In another sign that the company has prioritized the iPhone, Apple re-organized its software engineering department so there's no longer a dedicated Mac operating system team. There is now just one team, and most of the engineers are iOS first, giving the people working on the iPhone and iPad more power. [0] https://www.bloomberg.com/news/articles/2016-12-20/how-apple-alienated-mac-loyalists https://www.bloomberg.com/news/articles/2016-12-20/how-apple... [1] https://www.recode.net/2016/6/1/11835514/bloomberg-mark-gurman-apple-scoop https://www.recode.net/2016/6/1/11835514/bloomberg-mark-gurm...

derefr 9y ago
Under a different lens, that implies that previously iOS-only engineers now must also become familiar with the macOS codebase, and so more able to contribute to it. Given the large number of those engineers compared to the previous size of the macOS team, this may help more than hurt macOS (as long as you assume the engineering teams are of equivalent quality.)
- 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.
- dmitriid 9y ago
  One woman has a baby in 9 months. In how many months will 9 women have a baby? Also: “Mythical man month” etc. You do not solve your problem by having a bunch of engineers from a different domain and having different priorities.
  - jpttsn 9y ago
    First baby take 9 mo, but with a pipeline you can get the average close to 1 mo.
    - dmitriid 9y ago
      In this case we’re talking about just one baby :)
      - mygo 9y ago
        Just hire a woman who is in her 3rd trimester and you can cut that baby down to 3 months. ...
        astrodust 9y ago
        Visit the maternity ward. Problem solved.
        mygo 9y ago
        Say why don’t you give us a call back when you’re in labor and we can have that job interview?
    - bigiain 9y ago
      And if you'd been speculatively executing the baby making pipelines...
cgb223 9y ago
I heard rumors that Apple is moving towards one unified App development process for both macOS and iOS Is it possible that this is related to that?
- rhizome 9y ago
  Microsoft Cairo...finally!
  - astrodust 9y ago
    You mean Taligent: https://en.wikipedia.org/wiki/Taligent https://en.wikipedia.org/wiki/Taligent
    - rhizome 9y ago
      Taligent was a replacement, not a merge like Cairo was supposed to be.
patkai 9y ago
> "there's no longer a dedicated Mac operating system team" That took some time for me to sink in. I can fully understand the aversion towards dedicated teams á la Jobs, but we are talking about an OS that is used keenly by developers, an ecosystem essential to maintain. I was baffled by Apple not pushing ZFS further, the clear lack of interest in developers by not working on e.g. virtualisation, e.g. containers, a polished OpenSolaris or similar with tools we could make MacOS even greater. Like they couldn't afford it.
newscracker 9y ago
This reassignment and movement of people to the iPhone/iPad side has been happening for a long time. That's why I referred to the organizational structure, because the company is not equipped to handle so many things quite well (which has its advantages and disadvantages). One write up about this topic, which I share somewhat often is on Stratechery. [1]. That's worth a read. [1]: https://stratechery.com/2016/apples-organizational-crossroads/ https://stratechery.com/2016/apples-organizational-crossroad...

by miles 9y ago

derefr 9y ago

Under a different lens, that implies that previously iOS-only engineers now must also become familiar with the macOS codebase, and so more able to contribute to it. Given the large number of those engineers compared to the previous size of the macOS team, this may help more than hurt macOS (as long as you assume the engineering teams are of equivalent quality.)

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.
dmitriid 9y ago
One woman has a baby in 9 months. In how many months will 9 women have a baby? Also: “Mythical man month” etc. You do not solve your problem by having a bunch of engineers from a different domain and having different priorities.
- jpttsn 9y ago
  First baby take 9 mo, but with a pipeline you can get the average close to 1 mo.
  - dmitriid 9y ago
    In this case we’re talking about just one baby :)
    - mygo 9y ago
      Just hire a woman who is in her 3rd trimester and you can cut that baby down to 3 months. ...
      - astrodust 9y ago
        Visit the maternity ward. Problem solved.
        mygo 9y ago
        Say why don’t you give us a call back when you’re in labor and we can have that job interview?
  - bigiain 9y ago
    And if you'd been speculatively executing the baby making pipelines...

cgb223 9y ago

I heard rumors that Apple is moving towards one unified App development process for both macOS and iOS Is it possible that this is related to that?

rhizome 9y ago
Microsoft Cairo...finally!
- astrodust 9y ago
  You mean Taligent: https://en.wikipedia.org/wiki/Taligent https://en.wikipedia.org/wiki/Taligent
  - rhizome 9y ago
    Taligent was a replacement, not a merge like Cairo was supposed to be.

patkai 9y ago

> "there's no longer a dedicated Mac operating system team" That took some time for me to sink in. I can fully understand the aversion towards dedicated teams á la Jobs, but we are talking about an OS that is used keenly by developers, an ecosystem essential to maintain. I was baffled by Apple not pushing ZFS further, the clear lack of interest in developers by not working on e.g. virtualisation, e.g. containers, a polished OpenSolaris or similar with tools we could make MacOS even greater. Like they couldn't afford it.

newscracker 9y ago

This reassignment and movement of people to the iPhone/iPad side has been happening for a long time. That's why I referred to the organizational structure, because the company is not equipped to handle so many things quite well (which has its advantages and disadvantages). One write up about this topic, which I share somewhat often is on Stratechery. [1]. That's worth a read. [1]: https://stratechery.com/2016/apples-organizational-crossroads/ https://stratechery.com/2016/apples-organizational-crossroad...