The insurance company-driven model for industry specific safety improvement that worked so well for fire safety and auto safety has proven impossible because of three factors:
1. Cryptocurrency allows for unimaginably huge untraceable ransom payments that Amazon gift cards did not support,
2. No liability in tort for insecure software, and
3. Lack of computer security regulation (e.g., your car must have a seatbelt and ABS but your software can be arbitrarily bad without being prohibited).
Not hands on but I've been paying attention. IMHO several things world mentioning:
- Compose desktop is for now dependent on the JVM. That is despite Kotlin now having a stable native compiler. Reason for this is that the library eco system is still lagging. That being said, you can build some nice things with it pretty quickly.
- IOS support is not stable yet. It kind of works but you'd be an early adopter.
- On web, there are two compose variants. Compose HTML is a bit of side show but uses a traditional DOM based approach. Compose web exists in wasm and js variants and renders its own components in a canvas either way. Compose web mainly makes sense for people wishing to target the web with their mobile Android/IOS code base.
- Google just announced a recommended status for KMP on mobile at Google IO. So, this is significant in light of the recent layoff rounds affecting e.g. the Flutter and Dart teams.
If you feel adventurous it's worth checking out now but you probably have to wait something like a year plus for this to stabilize on IOS. I'm personally curious to see how the whole wasm/web part evolves. The wasm compiler is currently alpha. My prediction is that compose multi-platform will stabilize over 2025 and will start going mainstream the year after. At that point it could become a serious alternative to flutter and react-native.
> That is despite Kotlin now having a stable native compiler.
K/N for desktop platforms exists basically in name only. The runtime is too slow, the ecosystem simply doesn't exist, and you have to go through the C interop layer (which was marked entirely unstable in a point release, breaking everything!!!!) to do things such as I/O which lacks any sort of resource management (making it trivial to e.g. leak sockets everywhere).
This could get better over time. Most of the native community seems focused on mobile. But if this is ever addressed, Kotlin could emerge as an alternative to things like Go and other statically compiled languages. It's early days for native. There are similar challenges with wasm support; particularly the wasmWasi target.
I also think that in the longer term Google's embrace of KMP does not bode well for Dart and Flutter, especially in light of recent cost-cutting measures.
But for now Flutter seems like a much more mature stack, at least on desktop.
That is a fork, or rather, extension to Jetpack Compose, Google's declarative UI framework for Android. It uses Skia for rendering but has an the identical API to Jetpack Compose, hence from the point of view of a framework user, there is nothing new about it (other than that it works on Android, iOS, desktop OSs and web).
It's inspired by React, but way more purist about it. So there's no CSS or equivalent, it's all done using contexts, there's no HTML, it's all React-style function components the whole way down.
There are some advantages to doing things that way, but I found there were also disadvantages. How much you like it will depend on how much you like ReactJS.
Not an American. I do believe sustainability is important. However if the market failed to provide a solution, then a wee-bit of incentive is needed. Probably in 20 years those networks will be privatized so idk why they're complaining.
Additionally, US could very well force the sharing of infrastructure to get the market working better and force the market players to only discriminate its prices by region, not just where there is competition.
TL;DR: market failed, they can't cry because they didn't do the effort.
Well guys (and ladies), if civilization collapses from a Carrington-like event, I must preemptively say, it has been mostly a pleasure reading you all :)
I saw that stat on their chart. My question with it is 100 or so storms per cycle that just burp out into space period, or is it 100 or so per cycle that interact with Earth?
I've just been poking around at the Dropbox APIs recently when I got so frustrated by the fact that the Fastmail "attach from Dropbox" feature has been loading directly into my personal files space rather than showing the shared team folders since we switched over to using those last year - and I now have to download and re-upload files from those folders.
It's more than a glorified FTP. FTP does some heinous things with a separate control channel and stuff (let me tell you about adding encryption support to the Perl FTP server some other day), but this is next level!
It's not even as simple as just sending a fixed string in the "Dropbox-API-Path-Root" header for every API request (and they're all path based, so you have to make sure you always send that header or the paths won't parse right) - you have to get an ID for the real root, with a separate request, with a scope that we weren't requesting on refresh tokens.
So I hacked together something that worked on my testbed on the train ride home, but making it good is going to include adding a caching layer to the token refresh code, and suddenly it's not just a casual project. I'm still going to do it though, because dammit I have a file to attach to an email on Friday and I'm happy to spend hours on this to save myself 30 seconds.
I never thought of ProtonMail as a secure-from-state-surveillance provider. Only as a secure-from-civil-surveillance-aparatus provider. A replacement for Gmail, no more than that.
If I wanted to conduct illegal activities I would not use my main account on it, at minimum.
Protonmail is a step up from Gmail/Outlook, but no more than that. You need more layers on top of it.
Are we trying to get a free working market or what??
reply