For quite a long time there will be a greater advantage to local processing for STT than for TTT chat, or even OCR. Being able to do STT on the device that owns the microphone means that the bandwidth off that device can be dramatically reduced, if it's even necessary for the task at hand.
The OS distro model is actually the right one here. Upstream authors hate it, but having a layer that's responsible for picking versions out of the ecosystem and compiling an internally consistent grouping of known mutually-compatible versions that you can subscribe to means that a lot of the random churn just falls away. Once you've got that layer, you only need to be aware of security problems in the specific versions you care about, you can specifically patch only them, and you've got a distribution channel for the fixes where it's far more feasible to say "just auto-apply anything that comes via this route".
That model effectively becomes your ring 1. Ring 0 is the stdlib and the package manager itself, and - because you would always need to be able to step outside the distribution for either freshness or "that's not been picked up by the distro yet" reasons - the ecosystem package repositories are the wild west ring 2.
In the language ecosystems I'm only aware of Quicklisp/Ultralisp and Haskell's Stackage that work like this. Everything else is effectively a rolling distro that hasn't realised that's what it is yet.
On the one hand it's clearly suboptimal for any change, even ones that nothing depends on, to trigger a recompute. But also it feels like there's something a bit broken with spreadsheet dependency resolution in the first place. I've never been able to nail down a test case, but models seem to go over a performance cliff at a certain point. Ordinarily I'd put it down to something being unavoidably quadratic, but I've had cases where I'm certain that the same model is radically slower after being reloaded off disk.
There are situations I can think of where selection does seem broken by design. It's fairly easy to get into a situation in the 3d view where you want to select a vertex but because of the draw order it's very hard to find an orientation of the model that lets you put it "in front". So you spend ages selecting the lines around it, spinning the model, trying again from all sorts of angles. Heaven help you if you're trying to select a bunch of points that have this problem, it's frustrating as hell. The second is in sketches, where the constraint icons aren't selectable when they're grouped but will block the selection of a component underneath them anyway. That's just obnoxious. I think in both cases the UI is working as designed, but it makes for an unusable outcome.
Oh, and if the selection point isn't at the pointer point? That's just a bug, and needs to be fixed. I can't see any defending that.
I think it's fair. I use FreeCAD a lot, and the word I would use last to describe the UI is "discoverable". Ignoring whether a workflow is possible - whether the functionality exists at all - there's a whole lot of it that you have to Just Know, or equally as often Just Know That It's Not Actually Broken. The very fact that you started your comment with "If you <do X thing that you have to be told to do>" is precisely part of that.
Similarly one of our biggest causes of power outages when I worked with a DC was the UPSes. And the biggest causes of data loss were the hardware RAID controllers. Feels like there's a fundamental law lurking under this stuff.
As the complexity of a system increases, the number of single points of failure also tends to increase. Sometimes you can make sure that several subsystems need to fail before the whole system fails. Often, the best you can do is swap one SPoF (e.g. unreliable power grid) for another, more robust SPoF (unreliable UPS).
Security is the entire reason I want tools like this. Specifically for emulating IAM: if you've got a hard organisational "least privilege" mandate then you start with virtually nothing allowed and have to enable permissions for the explicit set of API calls you're using. You're not doing `Allow :` but you're also not using AWS-managed roles. That combined with the fact that - certainly with terraform - there's no mapping between "I need to manage this resource" and "these are the permissions needed to do so" means that every time you do something new in your infrastructure you're going into a game of permissions whack-a-mole where the deploy/fix/deploy cycle can easily take a multiple of the time it took to develop the feature you want to deploy, because one trip round the loop is a full attempted deployment. Whereas if there's an accurate local emulator not just of the feature but of the permissions attached to it, you can shortcut the slow bit.
Localstack does have IAM emulation as part of the paid product. I'm intrigued to see how well this does at the same thing.
This would be what I'd worry about. How many of us do any metrology on our printed artefacts? It's really easy to get a subtly warped print and without having some sort of calibration of the process I wouldn't want to make any accuracy claims whatsoever.
In a market with perfect price discovery, sure. However, over the years I have learned that even the best products for the job can (and will) lose without the right marketing, sales, distribution, etc.
Sometimes the entrenched default that collects an inertial premium doesn't get disrupted...
But, yes, anyone without a moat who operates with a presumption of retention runs the risk of being knocked off of their perch; their fate left to others.
reply