So it's not native anymore. One of the coolest things Audacity had, at least for me, was the fact it was built using wxWidgets.
I also wonder how is the Muse group perceived nowadays? I remember them acquiring Audacity was a huge mess when it happened due to them introducing telemetry. Never used Audacity since then.
Adaptive reasoning is known to be an extremely hard problem to solve, though. It requires you to predict whether a certain LLM, with a certain effort level, with a certain prompt, will give you the right answer.
If diskutil actually did everything OP looks for that was available in hdiutil, that's correct. If you read the post though, you'll see that diskutil has many limitations compared to its predecessor.
There's friction to doing it this way right now, though. You lose out quickly on accessibility, SEO, performance and developer experience (you need developers that are more experienced).
Unfortunately, thinking about it in terms of game theory [0], I believe this is a good thing: I don't want most websites migrating to canvas-like APIs for rendering. My web browser is my agent and I'd like it to mostly render DOM-rendered pages with CSS styling and, perhaps, funny JavaScript that doesn't track me around.
Also, I wish Figma and Google Docs were just offline-usable desktop applications. Both are great _products_ and I use them, but using them on a browser tab makes me unhappy.
You can have programmatic apis for accessibility, SEO pages can be dom based, performance of figma is better than if implemented via the dom api, developer experience? you just get the best and stop pretending you have capable people that spend a day on discussing effects in react.
> My web browser is my agent
It's very likely not anymore, otherwise Chrome wouldn't have pushed for manifest v3
> I wish Figma and Google Docs were just offline-usable desktop applications.
I wish this too, but since we have decided app distribution to be web based, we need serious tools for making serious apps
> stop pretending you have capable people that spend a day on discussing effects in react.
Figma uses React for the UI panels. Google Docs uses the DOM extensively too.
> have pushed for manifest v3
I don't use Google Chrome.
> since we have decided app distribution to be web based
No one has decided this, it just happened because web browsers were in the right place at the right time. It's not set in stone and developer tooling for the desktop could easily revert this trend in a decade or so.
> Figma uses React for the UI panels. Google Docs uses the DOM extensively too.
Tangential uses of the dom, the core app is on the canvas
> I don't use Google Chrome.
Who cares? They have an almost monopoly and they dictate what to implement on the web, it's already happening that many sites don't work on firefox because they've been only optimized for Chrome. And btw Firefox will implement manifest v3 as well. If you're not using Firefox or Safari you're still using chromium. We don't even have the capability anymore of developing alternative browser engines, the spec is a monster and the various attempts are still very far away.
> No one has decided this, it just happened because web browsers were in the right place at the right time
Exactly and since this is the current reality I don't see why we couldn't have better browser tooling for rendering near native stuff like we do on desktop frameworks. Developer tooling for the desktop already exists since ages but web folks have injected desktop apps as well with bloated stuff like electron
I'd argue that S3-compatible isn't exactly what you'd need though. You'd need S3-compatible with similar latency characteristics for read and write, with four nines of availability and 10+ nines for durability. [0]. Their metrics are, quite honestly, absolutely impossible for most engineering teams and companies to ever achieve, no matter how hard they work at it. In essence, what I mean is Cursor could migrate Origin out of Amazon's S3, but they'd lose a lot of reliability and/or performance in the process.
Wow. I've been waiting years for this, ever since Modular first announced Mojo. To be entirely honest, I thought they would walk back on this promise and so I never really gave the language a chance. With this and the 1.0 release, it looks like a better time than ever to start taking a look into it.
I've made a huge critic towards Flutter in another comment of mine, but adoption isn't it: the biggest bank in Brazil, with 135 million clients, is a digital bank whose sole interface is their Flutter app. They are different regarding tech choices (they use Clojure on the backend too), but I think it's a huge testament of how far along Flutter adoption has come.
I really don't understand how/why people deny reality so hard when it comes to Flutter. Reminds me a bit of years ago when people were still scoffing at the idea of anyone actually adopting JavaScript to write web servers with while Node.js was very obviously eating up the market.
It eats the market indeed, and also presents business opportunities for folks like myself, jumping in writing C++ addons, or completely replacing it with Java, .NET, Go, Rust,....
All the more reason why it's important to have an accurate read on the market! I for one also know a few people who've made a pretty penny writing native integrations for React Native and now Flutter apps.
While I've used Flutter since Alpha, I've been away for a few years. A few things have shocked me in these release notes: how come Impeller still wasn't the default engine for all platforms? Also, why are they migrating to WASM if one of the core features of Dart is compiling to JavaScript? Finally, how come multi window support only get viable now, after four years having desktop support?
Honestly, Flutter is an extremely enjoyable development experience I would recommend anyone I care for to stay away from. The fact it's developed by Google doesn't help: it's a matter of time before they kill it like they did with so many UI libraries and frameworks already, specially with JetBrains developing Compose Multiplatform and the Android team going all-in in the Compose strategy.
Flutter operates more like a 2D game engine. It renders its own views, which involves a lot of arithmetic operations, making WASM a more efficient option than JS.
WASM or JS doesn’t matter. The reason is Canvas instead of DOM. Flutter apps render to the canvas element, because this is the only option for the 2D game engine you mentioned.
> how come Impeller still wasn't the default engine for all platforms
Because Impeller has had quite a bumpy ride. Even as recently as June I reported a bug/regression with basic stuff (lines with partial transparency on desktop). All my Android apps are still built with --no-enable-impeller because I've had many instances where the app just shows a blank screen due to driver conflicts.
It may be getting close to stable now, but it wasn't a smooth transition at all.
Unless it is a trivial app, it would still require quite some effort to port (and test), which has a cost. What do you gain by using Flutter that compensates for that risk?
We've been hearing that Flutter is going to be killed any day now for almost a decade. And yet here we are, it's a stable platform that's quietly chugging along with massive 3rd party buy in. Honestly, Google could abandon it at this point and it would have enough momentum to keep going just fine. Where is Compose Multiplatform? Does anyone actually use that, is it even stable yet?
The fact is, more and more companies are actually picking Flutter. :) Sony praises Flutter on embedded. LG has added extension to allow Flutter apps on its WebOS. Toyota is developing a Flutter game engine, which is already used in some of its cars.
Some do use CMP but yes it's quite immature compared to Flutter and they'll spend a lot of time fixing the same bugs with rendering that Flutter fixed a while ago. We'll see how it goes though, if CMP becomes the blessed route for Android cross platform development it'll attract more people and attention.
Whenever a website offers to create a passkey, it could end up in any of these:
- Samsung's Password Manager (if using a Samsung phone)
- Apple's Keychain (if using an iPhone)
- Google Password Manager
- Your operating system's keychain
- A bespoke password manager (e.g., Bitwarden or LastPass)
- Your hardware key
Most users do not have a security key fob. Instead, the proposal being mostly pushed is the idea that users can store keys on their own smartphones, making use of the modern TPM and chip security. Most of the discussion here revolves around that idea: "What if I lose my phone? What if I switch phones?" and that's why the problems seem so obvious to you.
I absolutely agree the best solution is to use hardware keys, but I'll admit it's cumbersome if I need them for hundreds of accounts (which I do have), having to register both for every website and praying that I never lose both at the same time in the case there's no viable recovery flow for some of the accounts. Also, most of these hardware keys are limited to 25 or 100 resident keys, which again makes them unable to substitute passwords. Observe the usage of the term resident keys: passkeys do rely on the private key being stored on the hardware key, as that allows discovery.
I was talking about the non-resident FIDO keys. “Passkey” term is meaningless unfortunately because FIDO Alliance did not define it initially, it was a marketing term invented by Apple and then re-introduced (or shoved down the throat) by the FIDO alliance.
In non-resident keys scenario you don’t store anything and from what I see there is no security downside of using non-resident keys.
Loosing both (or multiple) security keys is like loosing all your car or home keys. Very inconvenient, agreed.
Anyway, I think we can agree that FIDO authentication protocol implementation is a mess. Apple and Google made it messy because they wanted to lock down users to their platforms and then password managers followed. As a result, the current implementation is not more secure than “login with Apple” or “login with Google”.
Indeed, the only advantage to Resident Keys (i.e., Passkeys) is the discoverabillity of them, so you can login without even using a username. It's a shame all of the terminology around WebAuthn/FIDO2 and Passkeys is so loose and badly defined.
Honestly, I think OAuth logins are still an ok option for the average user, unfortunately, as I would never recommend someone I love to use Passkeys and put them through the burden of having to understand and deal with all of this mess.
I have deployed FIDO authenticators at a ~2000 employees organization as the second factor. It was great for a while - when early versions of macOS and iOS respected the “platform” claim and created non-exportable private keys backed by Secure Enclave. Windows was never a problem, keys were created in TPM. We mandated 2 FIDO credentials - typically the laptop and either a phone or Yubikey (or both). People were encouraged to use the later but as soon as the keys were not exportable, phones were acceptable.
Then, Chrome got an update and started hijacking the enrolment process from the operating system and created keys synced to Google Account. This resulted worse UX because authentication now required pulling the Android phone (for those unlucky ones who have it) and confirming the login there instead of doing it right on the computer, uninterrupted.
Then, Apple followed with cloud-only key pairs and then so did the password managers (including Bitwarden Enterprise we were using) and everything become a mess.
The only solution would be to use the key attestation and to only allow specific security keys. Both Chrome and Apple have config knobs to simplify enterprise attestation (a strong assurance, which FIDO authenticator has been used), but neither Windows nor macOS support key attestation for hardware-backed keys (and macOS ignores “platform” claim altogether).
I have to think people aren't doing any research. Both Android and Apple sync your passkeys to your account. You can toss all your devices in a wood chipper, buy a replacement and still have access to all your passkeys.
Yeah, they do. But what if you want to move from Android to iPhone or vice versa? That's the big problem regarding these keychains/password managers. Some of them didn't even allow you to export your Passkeys until a few months ago, meaning you were literally locked into their platform.
Remember that your average user has no idea what a passkey is, doesn't remember half of their passwords and has no idea what a password manager is.
If you want to change it maybe tough. It doesn't have to be. Bitwarden has an open source self hosted option(you can also use their service), that can be set as provider in Android and Windows 11. KeepassXC is an option everything is in your kdbx file. Passkeys are so much more convenient and secure. If you do get stuck having to migrate, you can use your password (I would actually prefer just using multiple passkeys.) You don't need to do them all at once. Your average user is probably using whatever their device offers or nothing at all. I'd argue anyone that is tech savvy shouldn't be using either Google or Apple. If your account is disabled, you probably just lost anyway to retrieve your account unless you use a separate email address. I recently discovered cross device auth when a device I had a passkey was able to open my account on my pc that didn't have a passkey. TLDR ther are simple solutions that solve the 'lock in' issue.
So the use of Passkeys is contingent on allowing a major tech firm to spy on you?
I actually do have a Google account, but do not link my (Android) phone to it. I don't have WhatsApp or any other spyware on the device. I do use Telegram, Ankidroid, and a few other apps that I trust. I'm not a fanatic, but I won't enable and abet anybody to follow me around and report all that I do. How my position is considered an extreme position today eludes me, and frightens me as well.
I also wonder how is the Muse group perceived nowadays? I remember them acquiring Audacity was a huge mess when it happened due to them introducing telemetry. Never used Audacity since then.
reply