There's a trade-off to be made, and it's not necessarily clear where the trade-off sits for any particular company, or even team within the company.
One product person described it as eating vs breathing. Availability is like breathing: if you stop being available (including, but not limited to, because your software is a big ball of mud) then you're going to die pretty quickly. Product is like eating: you might not die so quickly but if no-one's buying what you're selling then you're still not going to survive.
The team I'm part of is a platform team, so we're closer to being lungs than being stomach. We can (and I appreciate being able to) focus more on stability than feature development.
The thing is: I could produce 2-3 times as much code as before _without_ an LLM, if I didn't care about my colleagues' ability to review my output properly.
Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality.
A huge part of the job of Software Engineering is producing the right amount of code at the right time.
I have a Pixel Watch 2, it seems that only certain carriers (typically not MVNOs) can set it up with an eSIM that will present as having the same number, but any MVNO that provides eSIM setup via QR code should work to provision via the connected phone.
I can imagine Apple being less inclined to allow arbitrary eSIMs on their watches, preferring to only support the case where the eSIM is guaranteed to support the "correct" presentation.
The people requiring adherence to a specific standard are not the people who then need to pay to see what they're supposed to be adhering to :(.
Strictly, just because the standard costs money doesn't mean that the information within it is otherwise unavailable. The C++ spec is an amusing example of this: the actual spec costs $$$, but the final draft is freely available. I can't imagine they sell many copies. I know that back when I was employed to work on a C++ compiler I only had access to the draft.
If demonstrating conformance is important, I suspect that the cost of access to specifications is only going to be a small fraction of the cost of certification. And as I understand things, it's certification that's the target of charging for specifications.
I'll second the recommendation for `mise`, and add: I typically use Homebrew for things I want everywhere, and if I want something everywhere then the latest version is _probably_ OK. I typically use mise en place for versions which are project-specific.
So I have a system Python (largely unused), a Homebrew python (pulled in as a dependency, I won't use it), and as many different mise/uv Pythons as I need for different projects. Similarly NodeJS and Java. I'd given up on nvm a while back, no longer use pyenv, and mise and uv work together really nicely.
Fair -- but I was more meaning that when I browse an arbitrary untrusted website I almost always allow the site owner to run arbitrary untrusted code on my machine. They might not send me any JS, but if they do then my browser will happily execute it.
Running arbitrary untrusted code safely is pretty easy nowadays, so long as the code is written in Javascript and you want to run it in a browser. It's only a little harder if the code is written in another language but targets WASM and browser APIs, or if you want to run your WASM inside of NodeJS, and there's even good support for running Python in a browser or Node.
Once you get away from running in a JS environment or away from code that's written with the intention of running in a WASM sandbox, if you don't want to have to modify the code for your environment then you're going to start having problems. This looks like a good step for anyone wanting to run arbitrary Python outside of a browser environment.
The Unifi range is quite definitely optional cloud. Don't turn it on (and don't use a cloud-based controller!), and it won't have any mechanism for control.
You can even use the mobile apps over direct connection, with local auth and no cloudy relay required.
This does depend somewhat on your risk profile. For many folk it's pretty decent: you need to guard against online attacks, so keeping your passwords offline gives them excellent security. If you need to protect yourself against family members, it's not so good — and it also doesn't provide the level of phishing protection that an online password manager offers.
One of types of services Cloudflare provides goes by the name "Warp". Calling it a VPN is only wrong in ways that don't really matter — it has the effect of causing client traffic to appear to originate from a different IP address to the one they're notionally connected to the Internet via.
The problem with asking an LLM for "its reasoning" after the fact, is that any justification it might give is a post-hoc rationalisation rather than a pre-meditated reason.
You probably don't want to be setting up Maps on either a touch screen or a with keys while driving. But navigation and media selection are the two functions I'm generally happy to interact with via voice.
I have a pre-facelift MB A-class, and I think it's the best car I've driven for controls. You don't have to touch the screen ever if you don't want to: there's a trackpad on the centre console that just works even (most of the time) with Android Auto (and the back/home/map/media/phone buttons will still save you even if Android Auto won't always let you move the cursor to the back arrow in YouTube Music). The steering wheel has two touch-sensitive buttons, one for each screen (duplicating the trackpad, which itself duplicates the media touchscreen). I can't even easily reach either screen when driving, so I don't.
Driving controls are all available on the stalks and wheel, volume is adjustable from the wheel or the centre console, all physical buttons, levers, or scroll inputs, unless you need to change a setting using the trackpad. The only thing that's missing is wheel control for skipping tracks :P.
If you want to email, my email address reads like my name.