5 ms·

I have been told by multiple sources that Apple engineering salaries are not competitive with industry leaders and haven't been for a long time. I wonder if the

by babesh 7y ago

I have been told by multiple sources that Apple engineering salaries are not competitive with industry leaders and haven't been for a long time. I wonder if the dissolution of the Jobs anti compete agreements exacerbated the issue. However Apple seems to be willing to pay for highly sought after skills. I have also been told that they don't have company level hiring standards so you should expect uneven abilities across different teams. I have also been told that things were being rewritten or rather that Apple likes to rewrite. Apple doesn't seem to be very good at limiting regressions caused by these rewrites. That's why there are so many crashes across the board. The crashes are caused by bugs or changes in behavior in common frameworks. This seems to jive with the author saying that Apple doesn't do enough automated testing.

bluejekyll 7y ago
I was just speaking with an acquaintance at Apple this weekend that works in a group in this area at Apple, and they pretty much said exactly what you just said. Also, it doesn’t help that they can’t directly benefit from the general progress the industry is making in virtualization and container areas without rewriting for their own platform.
- xhruso00 7y ago
  This is in contrast to this ex-Apple engineer. He recently quit. https://www.youtube.com/watch?v=dCGg_12gn-s https://www.youtube.com/watch?v=dCGg_12gn-s I also read on twitter that it's the Interns who deal with "fun" bugs -> not professionals! https://twitter.com/meteochu/status/1186701883429273604 https://twitter.com/meteochu/status/1186701883429273604
  - saagarjha 7y ago
    I wouldn't read too much into that tweet.
- arvinsim 7y ago
  > Also, it doesn’t help that they can’t directly benefit from the general progress the industry is making in virtualization and container areas without rewriting for their own platform. Can you expand on this? Are there limitations on MacOS that prevents them from doing so?
  - pmjordan 7y ago
    The macOS kernel (XNU) does not have any kind of containerisation support. I believe "Docker for Mac" is actually a Linux kernel running inside a hyperkit/xhyve VM, and uses Linux's container support. Apple hasn't put much public effort into making macOS work well inside a virtual machine. Recent versions in particular, where the window compositor uses Metal for drawing, don't run well. Apple hasn't opened the API for writing GPU drivers, so there are no drivers for the virtualised GPUs provided by VMWare, Parallels, VirtualBox, or Qemu in their VMs. (The tightening of code signing requirements [see the 'library-validation' flag] even locked out nvidia from providing their own GPU drivers from macOS 10.14 onwards.) The only way to have GPU acceleration in macOS guest VM is to pass through a whole GPU at the PCIe device level. (I don't know if anyone has tried AMD's MXGPU tech, which allows GPU 'slices' to be passed to VMs, with Macs and macOS VMs; the GPUs that support it are a little too expensive for a weekend project.) There are signs that Apple does use virtualisation internally; specifically, they've started adding drivers for virtio devices and one of Qemu's display adapters to macOS.
    - saagarjha 7y ago
      > The tightening of code signing requirements [see the 'library-validation' flag] even locked out nvidia from providing their own GPU drivers from macOS 10.14 onwards. Library validation has nothing to do with drivers.
      - pmjordan 7y ago
        Library validation has nothing to do with drivers. Depends on the type of driver. For GPU drivers, it is indeed a problem. I'm going to assume from your comment that you haven't actually written many (any?) device drivers on macOS, so let me explain roughly how GPU drivers on macOS work: - One or more kexts provide an IOFramebuffer implementation, plus an IOAccelerator object which listens for various types of user clients. The IOFB and IOAccel are typically clients of the GPU's IOPCIDevice object and handle its interrupts and memory. - A variety of user space plugins (essentially dynamic libraries) are loaded into any process wishing to use GPU acceleration, with different plugins for Metal, OpenGL, and so on. The kext communicates directly with the hardware and manages memory, but the user space plugin tends to deal with the higher level tasks such as generating command streams, compiling shaders, etc., and they talk to the kernel driver using the IOKit user client mechanism. The plugins also provide the back-end implementations for the app-facing APIs such as OpenGL, Metal, and OpenCL. In recent macOS versions, WindowServer, the process responsible for drawing your macOS desktop, has had the library-validation codesigning flag enabled. This flag enforces that any code loaded into the process must be signed using a certificate from the same Developer Team ID as the main executable or Apple's own certificate. This means, no third-party plugins can be loaded. This also means third-party GPU drivers can't work with most Apple apps and WindowServer itself, because they require aforementioned user space plugin. For similar reasons, classic Core Audio plugins (not to be confused with Core Audio Server Plugins) are deprecated - they used to be loaded directly into the process using Core Audio, which no longer works on apps with library-validation enabled. Drivers which are implemented entirely as kexts or which are loaded into a "server" user space process are not affected by this, which I guess is what you were talking about.
deleted 7y ago
[deleted]
ryan93 7y ago
They need to unionize. The company they work for has 60 Billion in profit!!!
- driverdan 7y ago
  Or they could get a new job at a competitor.

by babesh 7y ago

bluejekyll 7y ago

I was just speaking with an acquaintance at Apple this weekend that works in a group in this area at Apple, and they pretty much said exactly what you just said. Also, it doesn’t help that they can’t directly benefit from the general progress the industry is making in virtualization and container areas without rewriting for their own platform.

xhruso00 7y ago
This is in contrast to this ex-Apple engineer. He recently quit. https://www.youtube.com/watch?v=dCGg_12gn-s https://www.youtube.com/watch?v=dCGg_12gn-s I also read on twitter that it's the Interns who deal with "fun" bugs -> not professionals! https://twitter.com/meteochu/status/1186701883429273604 https://twitter.com/meteochu/status/1186701883429273604
- saagarjha 7y ago
  I wouldn't read too much into that tweet.
arvinsim 7y ago
> Also, it doesn’t help that they can’t directly benefit from the general progress the industry is making in virtualization and container areas without rewriting for their own platform. Can you expand on this? Are there limitations on MacOS that prevents them from doing so?
- pmjordan 7y ago
  The macOS kernel (XNU) does not have any kind of containerisation support. I believe "Docker for Mac" is actually a Linux kernel running inside a hyperkit/xhyve VM, and uses Linux's container support. Apple hasn't put much public effort into making macOS work well inside a virtual machine. Recent versions in particular, where the window compositor uses Metal for drawing, don't run well. Apple hasn't opened the API for writing GPU drivers, so there are no drivers for the virtualised GPUs provided by VMWare, Parallels, VirtualBox, or Qemu in their VMs. (The tightening of code signing requirements [see the 'library-validation' flag] even locked out nvidia from providing their own GPU drivers from macOS 10.14 onwards.) The only way to have GPU acceleration in macOS guest VM is to pass through a whole GPU at the PCIe device level. (I don't know if anyone has tried AMD's MXGPU tech, which allows GPU 'slices' to be passed to VMs, with Macs and macOS VMs; the GPUs that support it are a little too expensive for a weekend project.) There are signs that Apple does use virtualisation internally; specifically, they've started adding drivers for virtio devices and one of Qemu's display adapters to macOS.
  - saagarjha 7y ago
    > The tightening of code signing requirements [see the 'library-validation' flag] even locked out nvidia from providing their own GPU drivers from macOS 10.14 onwards. Library validation has nothing to do with drivers.
    - pmjordan 7y ago
      Library validation has nothing to do with drivers. Depends on the type of driver. For GPU drivers, it is indeed a problem. I'm going to assume from your comment that you haven't actually written many (any?) device drivers on macOS, so let me explain roughly how GPU drivers on macOS work: - One or more kexts provide an IOFramebuffer implementation, plus an IOAccelerator object which listens for various types of user clients. The IOFB and IOAccel are typically clients of the GPU's IOPCIDevice object and handle its interrupts and memory. - A variety of user space plugins (essentially dynamic libraries) are loaded into any process wishing to use GPU acceleration, with different plugins for Metal, OpenGL, and so on. The kext communicates directly with the hardware and manages memory, but the user space plugin tends to deal with the higher level tasks such as generating command streams, compiling shaders, etc., and they talk to the kernel driver using the IOKit user client mechanism. The plugins also provide the back-end implementations for the app-facing APIs such as OpenGL, Metal, and OpenCL. In recent macOS versions, WindowServer, the process responsible for drawing your macOS desktop, has had the library-validation codesigning flag enabled. This flag enforces that any code loaded into the process must be signed using a certificate from the same Developer Team ID as the main executable or Apple's own certificate. This means, no third-party plugins can be loaded. This also means third-party GPU drivers can't work with most Apple apps and WindowServer itself, because they require aforementioned user space plugin. For similar reasons, classic Core Audio plugins (not to be confused with Core Audio Server Plugins) are deprecated - they used to be loaded directly into the process using Core Audio, which no longer works on apps with library-validation enabled. Drivers which are implemented entirely as kexts or which are loaded into a "server" user space process are not affected by this, which I guess is what you were talking about.

deleted 7y ago

[deleted]

ryan93 7y ago

They need to unionize. The company they work for has 60 Billion in profit!!!

driverdan 7y ago
Or they could get a new job at a competitor.