> I agree of course, Europe should not be using US services for critical infrastructure. But more importantly I think that we are private citizens.
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.
Clearly it isn’t. This is what techies forget: The mass amount of Europeans don’t give 2 shits about digital sovereignty or open source. Christ, people go to mobile operator shops and give their unlocked phones to consultants to install or remove software for them. You want them to install GrapheneOS or manage a rooted device? That ain’t even funny.
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.
SMRs have their use. Depending on the model and design you can build them or even bring them [0] to a remote place where you want to build industry but the infrastructure and access to electrical grid is lacking. I'd argue nowadays they are even more important with the huge rise in electricity demand.
To my surprise Canada are actually quite ahead with the Darlington New Nuclear Project. There is a construction site [0] with work taking place. Not sure how Kairos Power are progressing in the USA. Nice job, Canada.
Not that deep into Go, but I also wondered why passing by value is not the preference here. It’s already non-nil. I get it - copying large structs is bad, but are large structs the common case? I think not, also the GC will love the copy instead of pointer escape-analysis.
> NPEs in Java have become rarer and rarer recently with the introduction of records
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.
Not only that, but the landscape of SMRs research and development is becoming very rich [0]. I think we are going to see a renaissance of reactor technology in the coming decade, and it will be well deserved.
> For the cost of the R&D of one next generation nuclear reactor design, how many next generation battery and solar panels technologies can you develop
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 made a Safari extension with Swift that automatically suggests using Fastmail masked email addresses on login forms. Never published it, instead just using an xcode dev build on my phone. Works flawlessly.
Why would it stop with just developer layoffs? When software companies rely on LLM providers to run their business, I’d argue we‘ll see a massive bust of these companies around the world - from on-prem products to SaaS.
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.
Exactly. I recently found out I can use Atlassian‘s ROVO to ask questions against our Wiki and Jira. I now forward consultants to ROVO first and only if they can’t find an answer then I’d look at their questions. Saves me a good chunk of time. They never read my docs otherwise.