Symmetric encryption does not need a quantum computer alternative, nor do we need a post quantum hashing algorithm. We may need larger keys and larger outputs from the existing algorithms, but that really depends on the level of paranoia.

It is the asymmetric keys that need post quantum replacement.

So I'm guessing the change to your proposed pseudocode you would have two derivation algorithms based on two input asymmetric keys - one post quantum and one classical. You would get from these two separate symmetric keys. You would then layer encryption using each of them, encrypting the cipher text output from the first with the second.

You can however just combine the two derived symmetric keys together to create a single symmetric key, and encrypt once. That is what hybrid algorithms propose.

Compatibility marks/certifications like AirPrint (2010) define how to advertise your IPP printer and its features, such as whether you can directly send a PDF. IPP Everywhere is perhaps the most notable open alternative to AirPrint.

At the compiler level, no. But as you write projects, you will for instance run into things you can do with templates which are infeasible to attempt with macros.

One example might be qsort() - a C compiler _could_ catch cases where it could create an intrinsic qsort based on the data type and function pointer being passed. However, in C++ you have the facilities to create a type safe, genericized sort that will be inlined based on the data structure.

The difference is Apple is much more likely to progressively make these legacy feature compatibility more difficult for users to configure over time, and to remove them eventually.

For another example: macOS integrated antivirus in 2009, while Windows did so in 2012.

On macOS, it is ultimately the app developer who is responsible for persisting and using state for windows, such as size and position. Think several terminal sessions - the terminal app needs to be the one to determine if it is representing the same 'session' as before after a restart.

If you are talking about remote display in a 3D space, the application would need to understand how to track and reopen a window in a particular location, and also there would need to be policy on how say a resize on the Vision Pro relates to the native window size once the Vision Pro is turned off.

This puts a lot of responsibility in the app developer's hands, where it is most likely not going to be accepted. So I would expect the experience to be sub-par.

There could be interesting workarounds for full-screen windows, since there are already the concepts of multiple heterogenous displays and display resolution changes on macOS. So you might have a screen, but the 'full screen' button is replaced by one which breaks the window out. The challenge would be making these persistent across connections to the Mac in a way that apps work well by default without picking up odd heuristics.

However, a capacitive touch surface should not be so close to tactile buttons. This made it way more likely to falsely register actions.

Move it a half key width farther up and make it taller to have greater flexibility on how it uses the space and I think it would have been a much better feature.

IMHO the big problem is that the five year hardware cycle of the MBP is not conducive for revolutionary improvements. They had the MacBook back then, which would have been a great platform for faster design iterations.

Changes which might not meet the quality bar to be a default user experience have a different calculus when they can be packaged up to be opt-in, and life-changing for certain people.

Global Accessibility Awareness Day also leads WWDC by a few weeks, so it serves as a taste of what Apple has been working on for the last year.

In terms of changes being led by a smaller feature, my favorite was night shift (which adjusted blue lighting at night) - which provided API months leading the first device with adaptive color adjustments from ambient light sensors.

It is too inefficient to design a machine which _might_ have two GPU and a flock of additional drives installed into it. It just makes sense to instead design around having independent hardware in its own case, which can meet its own power/cooling needs. This has been a design goal since the trashcan Mac.

Having a PCIe bus increases bandwidth and reduces latency, but once you account for eGPU and for people who would be happy building custom solutions on platforms other than macOS, there's likely not enough identified market for a modular design.

Arm-based windows support via Parallels does work, but AFAICT there's no official way to buy a Windows license due to a Microsoft/Qualcomm partnership.

I think a lot of age verification systems are the solution to the real core of legislation - to make companies liable for underage viewing of content. To put such legislation in place without providing a feasible way to accomplish age verification would be argued as discriminatory.

In that sense, a zero knowledge system which doesn't give a company non-repudiation so that they can defend themselves in court may very well be insufficient. And that will require tracking identity long-term, although it could be done with a third-party auditor under break-the-glass situations with proper transparency.

Apple's source is not public, but the protocol is still fully documented if someone wanted to create a new client and server. https://developer.apple.com/library/archive/documentation/Ne...

However, they'd be better off just creating a driver and server around the open source Netatalk implementation.

This hypothetical employee would:

- update the TimeCapsule firmware from using AFP to using a brand new SMBv3 implementation, including both porting and making it "fit" within the constraints of 2013 hardware.

- be designing and implementing a migration system for both the TimeCapsule and the Mac to move to using the new implementation

- be responsible for all security analysis, QA, and documentation for the firmware and migration system

They also need to get it done by the first macOS version that has AFP removed, which will land in developer preview in six weeks and need to be feature complete in about 17 weeks.

If Apple hires a new developer capable of doing that, I don't want them to relegate them to supporting 13 year old hardware. I want them improving things that the majority of users actually need.

And that is the core problem with this sort of argument. Even with infinite money or the infinite possibilities of open source contributions, the availability of talent is still _always_ finite.

I disagree. They are dropping support because nobody is maintaining them. There may very well be people still using these features, but they haven't been motivated or aren't properly skilled to offer to maintain them going forward, and haven't motivated some other skilled person via payments.

Rather, the core difference is that Apple does not offer a way to have external people take over providing support.