Other people can start manufacturing the parts if the demand is big enough and the designs are available or can be reverse engineered.
Not familiar with this world, but they could use relatively standard, widely used parts to build the tractor. For example, Yanmar engines are widely used in the marine world. The engine choice is abstracted away from the boat (for certain types of boats) and you don’t rely on the boat manufacturer sticking around. Everything can be retrofitted.
I think subscriptions are not going to last for serious users. Great to use them while we can, but AI does not fit the “power user subsidizes free/cheap users” model, nor the “support tens of thousands of customers from a small number of cheap servers” model. Everyone is a power user, and everything is computationally expensive.
I somewhat disagree, there was a major, major shift in developer sentiment towards agentic development starting with Opus 4.5 in October. Many teams started finding a lot more real value in Anthropic than they used to very recently. Things like OpenClaw are not a part of serious enterprises yet due to the security risk.
I’m not sure how anyone believes that per-seat pricing is halfway viable for AI, and I’m fairly sure the organizations I’m familiar with only REALLY started committing to spend after the shift to API pricing, due to the value they thought they were getting anyways.
Apple wants everything to be consistent. I have mixed feelings on it, because I do greatly despise windows, partly because of how inconsistent everything is. It’s chock full of half finished “migrations”. Like, programs still installing to “Programs Files (x86)” Which doesn’t matter but adds the tiniest bit of friction.
I think only 32bit apps install there. Ideally there is a 64bit version that continues forward. This is mostly an issue for me with enterprise/etc software I support at work. A key system I just moved to Server 2022 (on prem and Azure VMs) is 32-bit and still uses 32bit ODBC. It's a great app for our need. Just, still 32bit...
The intent is only 32 bit apps get installed there, but there are a few problems in practice. Dunno why you're currently downvoted about it though.
The first is needing to know whether the app was 32 bit or not is sort of the main annoyance with that itself.
The second is not every app follows this rule correctly, for whatever reason.
The third is there isn't a clear path for mixed apps, e.g. Steam. On Windows, Steam is still a mix of 32 bit and 64 bit components, so there isn't really a "clean place for it to go. You could have one option of putting Steam in one or the other and then mixing 32/64 bit apps in that folder & you have the other option of duplicating things, moving the initial problem an extra directory level deeper. 3b is that Steam installs the games under its folder, and the games you can install can be 32 bit, 64 bit, or a mix - duplicating the problem yet again. Until the start of this year, Steam still supported 32 bit Windows and, therefore, you could also have 16 bit games be installed.
There were reasons to do the split in the early 2000s but holding on to each decision like this for decades after seems to cause more pain than it ends up avoiding.
I’m not convinced they actually do, because GHE on the cloud tends to have the same problems as the main outages. Probably costs extra to be “single tenant” or whatever
I'd argue that it's directly related. If intuitive use of a library/framework/pattern commonly causes issues, you have to keep forcing yourself to do use non-intuitive approaches to prevent them.
It’s intuitive in the same way Ruby is intuitive, or C, yes, C, is intuitive.
They try to give you the vocabulary to be expressive, then get the hell out of your way. You can still shoot yourself in the foot with them, of course.
I think that has more to do with the design goals of the language. C was designed to be raw and simple, and it does that well. Ruby was designed to read almost like English prose, and it does that well. Rust was specifically designed to make it hard to shoot yourself in the foot, and it does that well too.
I don’t think that was ever a major React design goal. PropTypes helped a bit, but these days TypeScript carries most of the burden of saving developers from themselves.
Anyway, React is far from perfect. But JSX was a neat invention that alleviated the tension between
`<div>something</div>` and
let el = document.createElement(‘div’);
el.innerHTML(‘something’);
Not familiar with this world, but they could use relatively standard, widely used parts to build the tractor. For example, Yanmar engines are widely used in the marine world. The engine choice is abstracted away from the boat (for certain types of boats) and you don’t rely on the boat manufacturer sticking around. Everything can be retrofitted.
reply