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.
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.
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.
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.
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.
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.
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.
I'm not seeing how it's unpredictable and inconvenient. It's predictable if the stack address can be leaked (via a frame pointer leak, for example). It doesn't seem that inconvenient. Instead of including the address of a gadget in the chain, include the gadget xor the leaked stack address. What's the unpredictable and inconvenient part that I'm not seeing?
I feel like I’m missing something here. An infoleak is required to successfully ROP against ASLR (otherwise the attacker doesn’t know what to overwrite the return address with). Once an infoleak is available, the address of the stack can be leaked. I’m not really sure this does much beyond requiring attackers to modify their existing exploits.
I believe they're Zigbee Home Automation, not ZLL. Either that or they're improperly reporting that they support ZHA instead of ZLL, which causes issues for 3rd party bridges like Philips Hue. https://developers.meethue.com/comment/2686#comment-2686
If you find yourself starting a comment with “not to sound rude”, you might consider whether skipping the comment altogether is the best way to not be rude.
Their theory is spelled out pretty clearly in the article. There are 1800 taxicabs permitted to operate in the city and many more Ubers/Lyfts.
The fact that people who use Uber and Lyft have to wait less is nice for them, but not so nice if the extra cars for hire circling for fares results in slower commutes for public transit users.
Yes, the treatment of their employees in the workplace is very much Google's business. Accomodating LGBT employees is not only the right thing to do, it's also supported by many of the binary/cisgender/straight/non-queer/what have you employees at workplaces like Google.
> In particular, I’m still conflicted about whether all those type system extensions were warranted. Certainly immutability helped with things far beyond safe concurrency. And so did the side-effect annotations, as they commonly helped to root out bugs caused by unintended side-effects. The future for our industry is a massively distributed one, however, where you want simple individual components composed into a larger fabric. In this world, individual nodes are less “precious”, and arguably the correctness of the overall orchestration will become far more important. I do think this points to a more Go-like approach, with a focus on the RPC mechanisms connecting disparate pieces.
The proposal was to allow for as-of-right development if the development adhered to local zoning ordinances. That means no variances. As soon as a developer wanted a variance, they'd be back under the current system.