While hinting is disabled for most fonts, there are some fonts that require hinting to render correctly. We have to support hinting for those fonts, and it was easier to make it secure by rewriting hinting in Swift than it would have been to comprehensively identify every font created by those foundries.
Knowledge of Swift not required. If you know your way around OS software, can reason about the security of the code you write, and are excited about writing exhaustively tested software, we’d love to talk to you.
We’re hiring for roles in kernel/systems and userspace. Like the Platforms SOTU mentioned, we’re using Swift at all layers of the software stack now. https://www.youtube.com/live/yl2jsIoMfDU
I had the pleasure of leading the effort to ship Swift in the Secure Enclave back in 2022. Now I have multiple teams working on accelerating the transition to memory safe languages. We’re showing that with good planning and a relentless focus on testing, we can improve security, performance, and functionality. And we get to have a ton of fun working with some amazing colleagues. It’s the most enjoyable and impactful work I’ve ever done in my career.
Apple (like most large tech companies) is indeed a resumé black hole, and knowing people helps, so definitely network if possible. However, applying to the right position, with a good resumé that highlights experience/skills/projects/open source contributions/education/etc. that are directly related to the position, also matters. I am aware of several people who simply applied online and got interviews.
I may be wrong about this, but I don't think Apple bans you from applying to multiple positions within the same year the way some companies do.
There also seems to be a decent pipeline for new graduates (though I think highlighting relevant academic, research, and open source projects can still help.) Internships can also be a path if you are currently in school.
I don't know if Apple recruits on linkedin, but that might also be an option.
Of course connecting right here on HN seems like a great idea as well.
I was hoping to get some sort of a more direct contact from GP since he advertised the position. Not sure why would you mention it on HN otherwise.
> However, applying to the right position, with a good resumé that highlights experience/skills/projects/open source contributions/education/etc. that are directly related to the position, also matters.
I assume that Apple is even more competitive, than my current place. But even here it is not realistic: I heard we’re getting 500+ applications/position/day and _nobody_ looks at them unless there’s a lead/recommendation.
Great to see this happening. Personally I want an OS where everything is memory-safe by default.
Of course in an alternate universe where macOS (and iOS etc.) was based on Multics rather than Unix, it would have had essentially zero buffer overflows - which are hard to create in PL/I but hard to avoid in C. Even Apple's Pascal compilers from the 1980s had range checking...
But legacy C code can/should absolutely use things like clang's -fbounds-safety (has been in clang on macOS for years) etc. Fil-C is another option.
For low-level system security, I'm a fan of https://llsoftsec.github.io/llsoftsecbook/LLSoftSecBook.pdf as an overview for any systems developer, not just compiler devs. It might not be the most approachable, but it's got great info on everything memory corruption.
The names of some birds still reflect this. For example, the ring-necked duck has a ring around its neck that’s almost impossible to see a on a live bird.
We’re the team that designs and develops the operating system for the Secure Enclave used in iOS, tvOS, watchOS, and macOS devices. We develop the full software stack, including the L4 microkernel, runtime libraries, hardware drivers, and more. We work very closely with Apple’s Silicon Engineering Group to help design the Secure Enclave hardware.
This is a great place to work if you’re into some combination of embedded, operating systems, and security.
We’re the team that designs and develops the operating system for the Secure Enclave used in iOS, tvOS, watchOS, and macOS devices. We develop the full software stack, including the L4 microkernel, runtime libraries, hardware drivers, and more. We work very closely with Apple’s Silicon Engineering Group to help design the Secure Enclave hardware.
This is a great place to work if you’re into some combination of embedded, operating systems, and security.
Well, the position advertised is embedded programming in C/C++. Very much hardware-oriented. It's an area I'd love to get into but my career has evolved to be mostly automation-related Python coding. I don't routinely write enough C to claim expertise any more. Positions like this (especially at big well-known companies like Apple) also require a lot of domain experience, which can be difficult to get without pushing reset on your career and starting at the bottom again.
We’re the team that designs and develops the operating system for the Secure Enclave used in iOS, tvOS, watchOS, and macOS devices. We develop the full software stack, including the L4 microkernel, runtime libraries, hardware drivers, and more. We work very closely with Apple’s Silicon Engineering Group to help design the Secure Enclave hardware.
This is a great place to work if you’re into some combination of embedded, operating systems, and security.
Part of the issue may have been that the plane had slowed down so much that the stall warning stopped (it disengages below a certain airspeed apparently). When he stopped pulling up, the plane sped up and the stall warning started again. Pull up again, plane slows down, stall warning stops.
I wonder if something about this system was changed after that incident - why not keep sounding the stall alarm if the plane ends up outside the flight/sensor envelope? Can’t you assume that it didn’t magically cross the stall zone back into normal flight?
AF 447 wasn’t all that different from this situation. One of the co-pilots was trying to pitch the nose down to recover from the stall. The other was panicking and trying to pitch up. The plane averaged their inputs, without giving feedback via the stick that this was happening. It wasn’t until very late in the flight that they figured out what was happening, and then it was too late to recover.
Obviously there was some significant pilot error in this case, but a big contributor mag have been that the pilot who was trying to correct the stall didn’t understand that the plane was ignoring his input because of the averaging.
In April 2012 in The Daily Telegraph, British journalist Nick Ross published a comparison of Airbus and Boeing flight controls; unlike the control yoke used on Boeing flight decks, the Airbus side stick controls give little visual feedback and no sensory or tactile feedback to the second pilot.
Ross reasoned that this might in part explain why the pilot flying's fatal nose-up inputs were not countermanded by his two colleagues.
In a July 2012 CBS report, Sullenberger suggested the design of the Airbus cockpit might have been a factor in the accident. The flight controls are not mechanically linked between the two pilot seats, and Robert, the left-seat pilot who believed he had taken over control of the aircraft, was not aware that Bonin continued to hold the stick back, which overrode Robert's own control.
That suggest there was only ever one pilot flying and the way that pilot reacted to the situation had a big part to play in the final crash.
> That suggest there was only ever one pilot flying
"Pilot flying" is a human-factors title, not a software function-lock. It just indicates who has control responsibility at that moment but it is not enforced by technical means.
It is intended to eliminate ambiguity in crew functions; the PF can be a newbie copilot even if the commander of the aircraft is a 30-year-service Captain who would become the PNF at that point. Its all part of Crew Resource Management theory.
There should only be one PF in a cockpit at any one time, precisely to avoid the situation that arose with the Air France flight where the computer was receiving inputs from two pilots.
I was responding to the claim the flight control was averaging the two pilot inputs, because if that was the case then two pilots would have been flying the plane.
Might point was I doubt that this was in fact happening and there was only ever one pilot in charge.
> the Air France flight where the computer was receiving inputs from two pilots.
The link and quotes I posted suggest that was not happening.
The system was just ignoring the other pilot (and that was the designed fault) because it also failed to tell that other pilot he was being ignored.
Thanks for the link. It is a very interesting read.
In particular it also says this:
To avoid both signals being added by the system, a priority P/B is provided on each stick. By pressing this button, a pilot may cancel the inputs of the other pilot.
Yes, indeed, I have not found any reliable source for the claim that both pilots were making significant stick inputs simultaneously for any extended period of time.
You may be right about the averaging. From rereading the accident report, the Pilot Flying took back control of the plane after the Pilot Not Flying engaged his controls and tried to pitch down.
But, it’s the same basic idea. The PNF thought he’d gotten control of the plane, and didn’t understand why his input wasn’t having an effect. He didn’t get feedback from the stick telling him a different input was being honored. And neither pilot appears to have been fully aware that they were in a flight control mode where there was a risk of stalling. The PF especially never seemed to have made that connection, and the PNF took a fairly long time to call it out. As a result, the PF may not have been aware that he needed to actively keep the angle of attack inside the flight envelope.
So, PNF tries to pitch down, but isn’t aware the plane got put back into a mode where he isn’t in control. PF is pitching up, but isn’t aware the plane switched to a mode where this could lead to a stall. That’s the similarity I was getting at.
From the reported control traces, there was no prolonged period of dual input. There were 3 or so brief moments of dual control input (1 - 2 seconds), during which a warning was sounded. The pilots never spoke out loud about it, but we can infer that they heard the dual input warning and were aware when it happened because the sequence of events was the same each time; inputs from both joysticks received -> aural dual input warning -> input from one joystick stops.
Something about the idea of two pilots inadvertently fighting each other for control of the aircraft has definitely caught peoples’ imagination. But it didn’t happen.
I used to work in the industrial controls industry. The systems are often designed by application engineers working for the industrial control equipment’s manufacturer or distributor. In the case of distributors, the engineering work is often provided for “free” and paid for with the markup the distributor applies over their cost to purchase the components direct from the manufacturer. Those same application engineers will be involved with helping to make the sale. If a customer asks “can I connect this to the Internet?”, any response other than “of course!” is liable to result in a talking to from the sales manager for that account.
