Breaking changes (https://vitejs.dev/guide/migration.html) are minimal and unlikely to affect most applications, and when they do the issues should be trivial to fix.

Apple will probably try to deal with requirement to not require developers to use WebKit by allowing alternate web browser engines in European Union only - a developer would be required to provide WebKit version of an application or else it would be only available in European Union. That wouldn't violate Digital Markets Act, as Digital Markets Act only applies to European Union.

- Web browsers with ad-blocking and plug-ins (Apple currently requires all web browsers to use system Webkit with very limited APIs).

- Game cloud streaming services (xCloud, Stadia, GeForce Now).

- Unofficial clients for websites such as YouTube that add features that official client doesn't have.

- Tools to disable advertisements in applications.

- Programs licensed under GPL as Apple App Store bans those.

> Unofficial clients for websites such as YouTube that add features that official client doesn't have.

I'm sure Google can send a cease-and-desist to all sorts of other stores instead of just Apple.

> Tools to disable advertisements in applications.

This would be breaking the sandbox model of the system, I don't think the regulation requires dismantling system security

> Programs licensed under GPL as Apple App Store bans those.

No such rule. VLC on App Store is the first example that comes to mind. There are also GPLv2 components (such as WebKit) shipping in iOS itself.

The FSF has said there are (IMHO bureaucratic) issues with GPL on an App Store, specifically that e.g. Apple takes on certain responsibilities, rather than the developer.

For that reason, it's possible a contributor may shoot down publication, which IIRC caused VLC to have to rewrite certain components before launch.

> I'm sure Google can send a cease-and-desist to all sorts of other stores instead of just Apple.

Google may dislike those applications and refuse to host them on Google Play, but they aren't doing anything illegal, so they cannot do anything about programs like https://f-droid.org/en/packages/org.schabi.newpipe/ on other stores.

> This would be breaking the sandbox model of the system, I don't think the regulation requires dismantling system security

I don't think it is breaking the sandbox, it could be implemented using NEAppProxyProvider, however this particular API is not available for App Store applications.

> Programs licensed under GPL as Apple App Store bans those.

iPhone version of VLC is licensed under MPL2 specifically for that reason. WebKit is LGPL2.1.

Also, torrent clients, anything that could perhaps be used for piracy, anything even just very slightly pornographic or considered that by Apple.

This is an issue with Ruby's YAML implementation. YAML 1.2 processors should interpret documents without YAML directive as if they were YAML 1.2 documents - see https://yaml.org/spec/1.2.2/#681-yaml-directives.

See the last section -- a parser that interprets YAML as v1.2 by default will break for YAML v1.1 documents.

There's no way to determine whether a `.yaml` file is YAML v1.1 or v1.2 without a version directive, and most YAML documents are v1.1 because most YAML parsers default to v1.1 semantics.

I used Ruby as an example since it's easily available on most platforms, but you could also use Python or C++ or Swift or whatever language[1] you prefer. The underlying issue -- YAML not being a subset of JSON -- is universal.

[1] Note that some libraries, such as go-yaml, do their own thing and don't conform to either v1.1 or v1.2 semantics.

Nintendo's Lot Check doesn't really establish anything. Nintendo Switch's game store is flooded with games that don't really work as the testing was minimized.

I don't think using String::intern makes sense, especially now that Java's garbage collector is capable of deduplicating strings (https://openjdk.org/jeps/192). In the past it could have been used to reduce memory usage when a given string was used a lot, but now there are better ways of dealing with that issue.

G1's deduplication is nice, but note that G1's deduplication is a lot weaker than what String.intern does. G1 deduplicates the underlying byte array, but leaves separate strings (so s1 == s2 will evaluate false). So you still have an extra object header.

If you have (like one our applications did) millions of copies of the string "USA" in memory, that's many megabytes of memory that explicit deduplication can save that the garbage collector can't.

String.intern isn't the way, for all the reasons this post outlines, but just using G1 isn't the right approach either.

IIRC all of the concurrent GCs can dedupe now. Not just G1.

Hopefully soon object headers will be negligible with progress from Lilliput though.

Strings have an object header, an int for the hashcode and a pointer to the array. Assuming a < 32 GB heap (so 4 byte pointers), that's 24 bytes for the string, even once the array is deduped. Lilliput is awesome, but an 8 byte header would only reduce that to 16 bytes.

`process.stdout.write` is different to PHP's `echo` and Python's `print` in that it pushes a write to an event queue without waiting for the result which could result in filling event queue with writes. Instead, you can consider `await`-ing `write` so that it would write before pushing another `write` to an event queue.

    node -e '
        const stdoutWrite = util.promisify(process.stdout.write).bind(process.stdout);
        (async () => {
            while (true) {
                await stdoutWrite("1");
            }
        })();
    ' | pv > /dev/null

Additionally, they do in fact have a timeout for build process in the Go playground. I tried running https://go.dev/play/p/mwyBUjcKvAo, and it says "timeout running go build".

According to README:

> There will likely only be one git commit per driver release.