beachy
Though the most recent big tropical storm we had a few years ago, the power was out for 3 days, it was dark and cloudy obviously so no solar, the local petrol pumps had no power and the roads were blocked with fallen trees so we couldn't even drive anywhere. In that situation it really is candles and cooking on wood fires once the petrol runs dry.
Our first line of defence is the solar system's battery. When power goes out, that will keep things running for some time with the big optional loads switched off - e.g. hot tub, hot water cylinder and pool.
If the sun's shining we can run like this for a long time.
In a solar drought, when the solar battery runs low, the next step is to plug the EV in via V2L and use it as a generator to charge the solar battery. EVs have comparatively huge batteries, so at the cost of losing mobility, which may be important in an emergency, this will keep things going for even longer.
One great feature of using an EV is you can drive to a fast charger, charge up in an hour, and transport all that energy back home.
The final fallback is to plug the 2KW petrol generator in to charge the solar battery. This is enough to keep things going forever assuming a petrol supply. A petrol generator is nicely portable and can be loaned to less prepared neighbours who likely have their own petrol.
The key to it all is the solar battery. That gives you uninterrupted power while mucking around with the alternate sources. It doesn't even have to be all that large if you have an EV.
Esp32 emulation in the browser is an incredible superpower for hardware manufacturers.
You can put your hardware product, with a pixel perfect display and sound, directly into users (virtual) hands so they can try before they buy.
There's no real cost to you, since their web browser and computer provide all the horse power, you just serve it up as a static web page.
In the age of AI, a moat for hardware companies can be network effects through providing an AI friendly base that your users/players can build on.
For us that takes the form of an open source app store where players can extend their device using AI ("Hey Claude, make me a game like this one, except that a giant bowling ball with our company logo embossed on it should drop and roll down an Indiana Jones styled marble run").
It's hard to overstate how powerful it is to have users trying your device, navigating the menus, extending it's functionality themselves with AI, all on their own computer, creating games for others, all without even buying your device.
But nothing quite matches the satisfaction of someone in a far off engineering group reporting a problem that prevented them from committing data that would have corrupted the database - because your referential integrity constraints protected the database.
In the age of AI and a massive explosion of code touching the database, maybe it makes even more sense to embed logic and constraints inside the database where there's no way to get around them.
Back in the mainframe days the power supplies for computers were pretty substantial and it was deemed that special certification was needed.
I guess things have come full circle with water cooled data centres and massive power circuitry though I haven't been under the covers of anything but an x86 machine for some time.
There was a pitched battle over features like row-level locking as competitors like Sybase, Ingress and Oracle scrapped it out. New features arrived on a monthly cadence, with immense engineering effort behind them. The winners (Oracle mostly) won a great moat which led to them to where they are today.
The fact that so many AI companies can produce amazing coding tools so quickly shows there is no moat, supporting your theory.
I think by any measure that OS/360 would be "high craft".
A human would (rightfully) call you out for wasting time and resources. AI slurps up your feedback and dives in again with the same vigour.
As a SaaS vendor, interacting with our customers about SAML usually involves:
a) them knowing what they want because they already have SAML-based SSO and it works for them; and
b) our contact on their side being some unfortunate support dude who got given SAML as their subject area for whatever reason, and who knows very little about it, and who is 4 levels in the org away from anyone empowered to make decisions as significant as moving away from SAML.
Aluminium is often described as "congealed electricity". Ship bauxite to wherever power is cheap and stranded, turn it into metal, and ship the metal out. Here in NZ, Tiwai Point is the textbook case, with London-based Rio Tinto running a smelter on the other side of the world that exists mainly because Manapōuri hydro had nowhere else to go.
AI data centres can be just the same - even more so, since the plant's assets (its chips) are virtually perishables, so there is less concern about assets becoming stranded if the host goes rogue. All the US needs is friendly and stable allied countries with cheap power.
The skills to drive AI are much the same as they were for business analysts in the old days. Domain knowledge, insight into user requirements, knowledge of modern UI paradigms, ability to write detailed, consistent requirements docs/ design docs.
There is a deep bench in the industry of these senior-ish people. Many have left to become baristas, dive instructors or hobby farmers, scarred by the pain of building large complex software systems using human labour and absurd Agile rituals. But they could slot straight back in, it's like riding a bike.
AI development is the new waterfall. Its just that the lower level that the BA hands off to, which used to be roomfuls of devs, is now a superhuman who can implement those designs at lighting speed and come back hungrily for more.
But if by senior you mean someone who is just a junior with more experience, someone who's not really in touch with the business's needs and who just works off stuff fed to them by PMs or the like - then yeah, agreed.
However in the age of AI I don't know if it matters too much that SOAP is the interchange. It is easy enough to build clients against it. It works. It's probably quite secure. Who cares?
So I can certainly understand why someone would want the guardrails gone.
I might be missing something but isn't this all a bit of a no-brainer?
In the old days, buildings were made to impress, to project wealth, to show the generosity of wealthy benefactors to their town or city. Take a look around somewhere like historic Bruges, which benefited from the wealth of local merchants. Incredibly impressive. Not remotely cost effective.
Today, buildings are typically functional, or at least financial considerations are top of mind. And cheaper tends to be uglier. Why would someone invest in an elaborate and expensive design when they could simply throw up a slab of brutalist concrete and punch some windows into it? It's all the same to the workers inside.
And of course for older folks, older buildings are closer to what they grew up with. Even if only a bit. Seems a natural effect for older people to enjoy older architecture.
I'm sure they aren't all, but friends who work in the hospital tell tales of woeful inefficiencies and pointless beauracracy. Of course YMMV and this is a public health system.
The commercial guy I dealt with made it very clear that a primary concern was IBM not being humiliated and shafted like their MS dealings. It colored our commercial arrangements, which had to include "break glass" arrangements for them to gain full access to our source code.
Plenty of apps do this - looking at the first browser tab I have open I see gmail which does exactly this.
For a pure client app like an iphone app, you don't have any real "per user" costs, so there are no concerns about going under from the costs of attempting this. It would be very different if you had to pay for server capacity.