dwaite

Only Google was willing to do what Apple wanted for a reasonable price.

They licensed Gemini and Google infrastructure not just for use, but to accelerate the creation of the three independent Apple Foundation Models announced today:

- AFM Core

- AFM Core Advanced

- AFM Cloud

Google also worked to be able to host AFM Cloud on their infrastructure per Apple's private cloud compute architecture, including some form of independent third party review/audit.

I suspect the only two organizations with both the model and the infrastructure needed for Apple were Google and xAI - and I'm not sure Apple would touch Grok with a ten foot pole, even if xAI were willing to let it be used for training.

The cookie popup also more often than not doesn't satisfy GDPR, since the option to remove consent disappears with the popup. These dark patterns emerged because the GDPR was used selectively as a club rather than properly enforced. That led to what another comment refers to as "compliance theatre" rather than actual corporate compliance.

> Or that they wouldn't let you set default maps app outside of the EU

They were mandated to create a scheme in isolation on a deadline, without having input either from navigation apps or from consumers, and without any requirement that web browsers or other operating systems would need to support the same scheme.

As another comment pointed out - it doesn't work. Websites and apps still integrate with a navigation product directly, rather than use this scheme. And why wouldn't they? Even if it was launched worldwide on iOS, it still is just a defined subset of any particular navigation product functionality. It also is just yet another navigation option to integrate into your platform, since the feature still wouldn't be available on desktops/Android.

Until everyone is sitting at the table wanting to work towards interoperability, the feature simply can't work. So why perpetuate a broken chooser into other markets?

> It’s not clear how it is significantly different from allowing apps access to your contacts, calendar, photos, and so on

Those are allowed via contextual consent prompts, several of which are for specific contacts, specific photos you wish to share, and so on.

Examples of the level of access an AI agent has include:

1. To read all indexed personal data from every app installed on the device

2. To perform actions in every supporting app on the device on the user's behalf

3. To read the current displayed apps for additional context as well as sensor data like current location

If you were regulated such that you had to allow any organization this level of access, and if you were hand-tied in how much you could convey the seriousness of accepting that consent prompt to an ordinary end user, and felt that it would be you, not any legal authority, who would ultimately suffer the reputational and legal consequences for the results - what would your yes/no decision be on shipping the feature in that jurisdiction?

> The code is still fully open source, but the project that produces the code isn't.

I think your thought was cut off. What is the project no longer?

"The Cathedral and Bazaar" is orthogonal to open source. Its argument is that open source is most valuable when paired with the bazaar model, not that the cathedral model cannot be considered open.

The open source definition was created in that mind. It does not state or imply open development or a community are requirements.

> I think they're moving in the WebKit/Safari direction: open for you to look at, but not really an open source project.

Webkit absolutely takes third party submissions. https://webkit.org/contributing-code/ .

I believe this is an external PR merged a few hours ago at the time of this writing. https://github.com/WebKit/WebKit/pull/66507

Safari does not accept third party submissions, but the chrome has never been open (even before Google Chrome recycled the term).

Your prior message could be taken that this was an elitist move, and not a move that is being taken by many different projects for survival with limited review capacity.

LLMs in general change the balance of how much effort generating content takes, sometimes by orders of magnitude. They unfortunately do not significantly change how much effort it takes to understand and evaluate the quality of that content. The result is that the base value of a piece of content (including code) is plummeting.

The open source definition does not mention community at all - it is a set of licensing requirements that certain rights to modify code must be maintained, not that upstream will accept your change or (for that matter) that you need to package it up and hand it to them.

And submitting a PR is almost wholly dissimilar from a conversation between friends over dinner or drinks. If you want to have a community around an open source project, it always has taken more than just accepting patches.

Not really - it changes how the lines are drawn between components, rather than removing any of them.

The EXT4 filesystem driver as an example contains most of the same code whether it is part of the kernel process or is a user process. A virtual filesystem abstraction is needed between the two in either case as well.

The kernel also already has a module system to support loading externally maintained code. You won't necessarily see a benefit from separately maintained drivers that wouldn't already be present.

Trying to bridge this a bit since I'm closer to a layperson in this area.

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.

It's not considered fully RESTful, but it sounds like you are describing IPP, which came out in 1997.

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.

Apple A17 Pro / A18 include AV1 hardware decode.

> Is C++ more performant than C? I find this hard to believe.

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.

> This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5

IMHO, both are a mode of progressively penalizing developers as a mode of API obsoletion. It doesn't feel like the opportunity to fix a degradation of user experience really motivated app developers in either case.

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.

Windows and macOS both got ASLR in 2007.

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

Valve hasn't committed to making a mixed reality computing platform, and Apple hasn't come out with a gaming VR headset. Neither company wants to directly compete.

No , at least not yet.

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.

I disagree as well, and wonder if the OP meant an emotional or ideological stance instead.

I have never got into macros, so missing a row of function keys didn't impact me. A row of system integration actions (like dynamic volume and brightness controls) was nice.

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.

ML-related improvements to accessibility has been the trend for a couple of years now.

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.

IMHO - extremely little.

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.

I'm curious why I would want to dual boot Windows when there's a perfectly good hypervisor and paravirtualization built into macOS?

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.

"slop" and "vibe coding" are derogatory terms about the level of effort - e.g. little to no human review of quality or accuracy, or accountability/concern related to the output.

That really depends. A zero knowledge system would show to the verifier that the person is authorized for access _right now_, but thats just the answer to a particular challenge. Outside of the verifier who knows they came up with a random challenge without bias or influence, the response would mean nothing.

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.

If the pattern continues, they'll announce deprecation this fall and remove the feature in 2039.

The AFP protocol was deprecated in 2013. The AFP server was removed in Big Sur, so over five years ago. This is removal of AFP client support.

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.

My estimate is that your lower count of people who could still be using Time Capsule is off by a factor of 20, but we'll continue with the idea that Apple could justify hiring a single engineer to be assigned full-time on the TimeCapsule, starting today.

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.

> Linux, which is free software, isn't dropping features because nobody wants to support them, but because nobody's using them.

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.