The irony in this as a European is that in the US people don’t even need national ID in the sense we got in Europe. They travel using driving license or library card. We got mandatory passports with biometric data - refusal to provide that data is practically impossible.

The only short-term solution is more regulation and more EU-centralized solutions, but of course this is only ok until the next chat-control drama.

Long term, in practice we need single European stock market and a way to provide funding to European companies from any member state, so to be competitive globally without being constantly restricted by every member state’s bureaucracy.

Like what for example? They can’t access any chat messages or app data. Even your location is impossible to obtain without your knowledge.

0 - https://en.wikipedia.org/wiki/Akademik_Lomonosov

0 - https://www.neimagazine.com/news/darlington-smr-secures-fina...

While this is true, I think it goes back farther than that. NPEs became rarer since java.util.Optional and people taking the time to use JSR 305 nullability annotations. I do this on regular basis and haven’t seen NPEs in my work for ages now.

Because I’ve taken on projects with large Java codebases often written by people with poor code-design skills, I can say the single most frequent NPE offender I’ve seen was method bodies wrapped in: try { } catch {} return null.

Modern language features like Kotlin’s non-null fields are nice, but I hold self-discipline just as important.

What do you think is invasive in an MDM profile? It's just a channel to push data to your phone. Your information outside the work container stays private. Even inside the work container nobody can actually fetch any data from those apps.

I do agree with you though - a company must provide phones to their employees, not force them to enroll into their MDM services. The latter should be only for exceptional cases, e.g., gain temporarily access to corporate VPN, WiFi, etc., on your private device.

0 - https://world-nuclear.org/information-library/nuclear-power-...

This is a horrible argument. Yeah, let’s not spend money improving technology. We wouldn’t have increased Solar panel efficiency if we followed such ill advice.

I wouldn’t be concerned, because this is obviously false.

Customers may build the software they need entirely in-house or via prompt-engineer consultants, without the need to buy software tools like today. It could be a very very different world.

Go‘s github discussions on the other hand, give me live-view of the latest state of the experiment. I find both useful and don‘t prefer either.

Interestingly enough, I see the trend of people with decades of experience using AI more and more often. I'm in the 20 years club myself, and I do AI-assisted coding every day. It does help, and I'm grateful to have a tool like this to quickly try new ideas and throw them away if they suck. Shaming the author for using AI to help with the CI stuff is baffling to me. Are we witnessing just another ideology-driven tribal reaction on the rise?