kodebach

Data didn't just describe the situation, he accurately assessed what is at stake for himself and what the consequences might be. He recognised his life and his entire being may be in real danger. Recognising that requires understanding of the "self", as in Data demonstrated he knows and understands the difference between himself and other beings/things. He is aware that he is a separate being with autonomy, and that this being of self may end. That goes far beyond just describing the situation.

No it doesn't, but it also doesn't need it. Whereas in Java you write:

  if (obj instanceof Point(double x, double y)) {
      foo(x,y)
  }

Kotlin with its smart cast feature lets you do

  if (obj is Point) {
    foo(obj.x, obj.y);
  }

Spring is slow because it scans the classpath, uses reflection and generates proxy classes all at startup. You can avoid some of that using the Spring AOT feature in newer versions.

Or you can just use a different framework like Micronaut which does none of that and uses an annotation processor at compile time instead. (Similar to Spring AOT, with fewer limitations)

What wasn't "good enough" for you in Kotlin?

Sure, Java is slowly getting most of the features and sometimes even in a better form because they control the runtime (virtual threads arguably just work). But IMO Java is still incredibly verbose, Kotlin's type system is just better and I've genuinely never come across anything that would be easier to do in Java. Even virtual threads can be used from Kotlin.

Most importantly IMO the JVM ecosystem has lots of solid, battle-tested, enterprise-grade frameworks like Spring and Quarkus, which do all the heavy lifting for those kinds of applications. The code can still be verbose, but that is solved by LLMs, as you said.

Rust has all the individual bits you need as libraries (web server, database access, etc.) but you have to wire it all together yourself. Sure LLMs can do that too, but how do you know the LLM did it correctly? There could be complex interactions between the individual libraries.

Using a complete framework solves that, you know its bits will work together correctly. It also makes the code structure of different applications look more similar, which probably helps LLMs understand it better too.

I'm no expert, but wouldn't a basic hardware firewall that allows incoming, but not outgoing connections solve the issue? Wouldn't even basic VLAN isolation achieve the same? The humans can still open a TCP connection, SSH tunnel, etc. from the outside to remotely get data out of the training environment. But the agents cannot reach anything outside their isolated network.

I can't prove it, but I still think this is (partly) due to a recent EU regulation majorly backfiring. I can't remember which one it was, but one of the recent regulations mandates that devices get updates for a certain period. Within that period a manufacturer must provide each update for all their devices in a short timeframe. The intention was to prevent flagships getting updates immediately and lower end devices having to wait months. However, due to some (also well intentioned) wording about open source, the release of the source code is counted as the first release of an update and starts the timer. I'm pretty sure Google is delaying public AOSP updates to give their partners (mainly Samsung I suppose) more time to finish building their updates on top of AOSP.

Who says inserting those NOPs didn't break other behaviour that OP isn't using. And then there's also Hyrum's law. This whole thing could be very non-trivial.

Fixing a bug for everyone is very different from fixing the bug just for yourself

And Apple platforms will use Swift until Apple invents a new language, Android still uses Kotlin, C++ will stick around for decades in automotive and aerospace where you need loads of expensive certifications and who knows if we'll ever be rid of COBOL (even with AI rewrites execs might not wanna risk the switch).

Do you have an example of where "the ideas don't combine well"? Or where an imperative approach is truly better?

In my experience the solution is often to use the appropriate architecture underneath your UI layer. Basically you build a data structure that represents your UI and always hand this entire structure to the declarative UI layer. Underneath the UI layer, you can still use imperative code to manipulate the data structures. The benefit of the reactive/declarative approach is that you don't have to think about how changes in the data need to be reflected in the UI. That's the framework's job.

Note: With "data structure" I don't mean "build a shadow DOM". I mean something specialized to your use case.

The goal of the reactive/declarative approach was never to be more performant than imperative code. The goal is to more easily build UI that is performant enough and functions correctly. With imperative UI code it is incredibly easy to forget an edge case in your update logic.

Well if the cookie comes from a third party it implicitly allows tracking.

Also AFAIK the Google Fonts question (is the IP alone already PII, if Google has no way of tying the IP to a person) has not been decided by the ECJ yet. There've only been decisions by lower level German courts that are still in dispute.

Based on my understanding of the GPDR, this scheme wouldn't be anonymous, if the salt is stored anywhere. Using the salt(s) and the full list of all your users emails, you could find out which one matches the hash, thereby linking the analytics to the original PII. Of course that's a rather ridiculous idea, but AFAIK the GDPR doesn't put any qualifiers or limits on "it's not anonymous if the PII can be recovered with extra data".

Google already announced the "Advanced Flow" that lets users override the verification. Yes, it's quite complicated, but it shows Google isn't trying to completely close down Android (yet). All this outcry is just lead to a boy who cried wolf situation. ADV is gonna become active, 90% people won't notice the rest will (begrudgingly) use the Advanced Flow. If Google then changes their mind actually does what F-Droid claims right now, nobody's gonna listen.

IMHO F-Droid is just mad because their store model of "developer publishes source code, F-Droid builds and signs the APK" would put immense liability on F-Droid. After all with that model F-Droid owns the private signing keys and now has to register them with Google. If they let a single malware app slide through, Google might designate F-Droid as a malware provider and block everything ever published on F-Droid. (Sidenote: Last I checked F-Droid had nothing in their policies that forbids publishing malware, just that it has to be open source) If you ask me this store model was always stupid and completely missed the point of having signed APKs. I think they also have a newer model where they don't own the private keys anymore, but there's still tons of legacy apps.

Of course Google might have been open to talks about some kind of verified app store program allowing F-Droid to operate under different terms. But that's certainly out the window after all the fear mongering, hyperbole and straight up propaganda F-Droid has put out in recent months.