Most nations who are affected don't have a blue-water navy or similar means to pose a serious threat to Iran. They have to either back the USA or deal with the toll and the uncertainty that comes with it.
> what has already started, is already started -- I agree on Trump being dick, but does that make iran's "making new enemies" a wise move?
There is no downside on making the Gulf states enemies. Quite to the contrary: they might lobby the USA to end this madness. It's a serious damage to the importance of the USA in the region if it can't or doesn't want to open the strait again, either by force or by making a deal.
The Gulf states are not any more willing than the USA at invading Iran with ground troops. The only thing that changes by making them angry is that slightly more missiles fly into Iran. Which is already accounted for and won't magically reopen the strait.
Did that involve boot on the grounds or just shelling via cruise missiles or from air? Also, Yemen is poorer, but has more or less the same population as Saudi Arabia.
Their military is a paper tiger like Saddam’s was during the Iraq invasion. Modern gear but without the doctrine or officer corps to effectively use it.
My experience while working there years ago was that their armed forces were a weird mix of coup proofing and a nepotistic dumping ground for family members who couldn’t be trusted to help run the family business.
The really valuable CRUD monkeys are already domain experts as well. The threatened ones are junior developers whose output is barely better than AI slop.
> The really valuable CRUD monkeys are already domain experts as well
Sure but that’s a minority I’d argue. There wouldn’t be such a volume of shitty business software otherwise.
I will be interested to see if there are any economic effects of ending one of the last well paid, low barrier to entry careers in which some level of meritocracy was permitted.
It's an unfair fear since architecturally Wine sits at the same position as the Win32 API on Windows, which also in the end merely uses the underlying native system calls. The only difference is that Linux aims to keep its system call interface stable.
If you're utilizing undocumented APIs that aren't meant for public use, sure... but the core Win32 APIs have been pretty stable for going on 3+ decades now. You can take a lot of win32 apps from the early 90's and they'll run without modification in windows today... though, they'll probably run in Wine and likely a better chance there... but still.
I fully agree with that. Sadly there is always the odd application out there that uses the lower level stuff and is therefore tricky to get to run on Wine. Or more recent Windows versions for that matter.
win32 dates back to 1993. OP doesn't know Windows history. Maintaining backwards compatibility was always a huge priority for Microsoft, even if it couldn't be perfect.
If a program didn't work on a newer version of Windows, there's a good chance it was doing something unsupported.
Any appliance with strong motors should be more efficient with AC supply. But almost anything else can be regarded as a heater that doesn't care much as long as it is fed with the correct voltage. Which is actually the core issue.
A DC household would have to choose a trade-off between multiple lines with different voltages or fewer voltages that need to be adapted to the appliances. And we're right back at the AC situation, but worse since DC voltages are more difficult to change.
But consumers like datacenters can very well plan ahead and standardize on a single DC voltage. They already need beefy equipment to deal with interruptions, power sourges, non-sinus components, and brownouts, which already involves transformers, condensators, and DC conversion for battery storage. Therefore almost no additional equipment is required.
What qualifies as a strong motor here? Are you comparing to a brushed DC motor? Do you think a washer/dryer would have worse overall efficiency with a BLDC in a DC home compared to what we have today? If so, that’s news to me. Where can I learn more about that?
The trade-off between, say, one (relatively) high voltage DC bus throughout the home vs many branches with lower discrete voltages is indeed a problem. With AC, we took the bus approach, running 120v everywhere (in the U.S., higher elsewhere). I’m inclined to say we should keep doing that for flexibility and predictability. But it’s a trade off, like you said. It would obviously help if regulatory and standards bodies came out with official recommendations.
Things like washing machines, dryers, dishwashers, air conditioners, or fridges spend a lot of energy by running powerful electrical motors, which should benefit from AC.
Everything else I can think of in a typical household is basically a mere heater that in principle works equally well with AC and DC of the correct voltage. Even computers can be said to mostly care about the correct voltage since AC->DC conversion is vastly easier than voltage conversion.
>Things like washing machines, dryers, dishwashers, air conditioners, or fridges spend a lot of energy by running powerful electrical motors, which should benefit from AC.
No, they don't, not at all.
Most modern appliances have variable-speed motors these days. You can't do that by just connecting AC to a motor; you need a control board to generate the waveforms necessary to make the motor turn at the speed and direction you want. That control board has to be fed with DC power. (Source: I used to design BLDC motor control systems)
Only really simple appliances, like old-fashioned horribly-inefficient clothes dryers, still use AC induction motors, and those are mostly being phased out. (Bathroom fans also need AC; they're usually cheap synchronous reluctance motors.)
So it really doesn't matter much whether the incoming power is AC or DC these days, unless you have a bunch of ancient appliances that still use induction motors. If it's AC, it's going to be rectified and fed into a DC-to-DC converter to create the lower DC voltages needed. If it's a higher DC voltage, we can skip the rectification step and not worry much about ripple.
Probably 90% of my devices run 5V DC or similar, but you can't run that through a home so you're back to needing AC. If you're going to have AC and DC then you might as well just have AC.
> Probably 90% of my devices run 5V DC or similar,
Indeed. And that’s quite normal. Our electrical system should serve our modern needs.
> but you can't run that through a home
5V might be too low for that length of wire. But you could most definitely have a low voltage line in your house that we could design around, maybe 12V. Electric vehicles are moving towards 48V for accessories. It seems like lack of a standard is holding us back more than anything else.
Or we could just keep doing 120V in the walls, with a DC supply. Modern DC-to-DC voltage converters are very efficient and small. But maybe I’m wrong. A lot of people seem to believe they are still not good enough yet for such a change to make sense.
> If you're going to have AC and DC then you might as well just have AC.
I arrive at the opposite conclusion. Most things are natively DC. So therefore, power in the walls should be DC and we should covert it to AC near the endpoint where necessary.
It might also be illegal. Don't know about the US but forcing a bankruptcy to avoid regulations is usually frowned upon by the court system here. So putting a product in a child-dummycorp to go poof when you want and let the parent stay afloat usually puts the parent in the line of fire directly and you are screwed either way.
It is possible to require escrow accounts for cover costs of fixing future security issues) - these survive bankruptcy. They need to be big enough to cover the costs though - insurance can calculate this but it isn't cheap.
The obvious problem with that is the detriment to smaller companies, but it makes a good alternative to releasing the code.
Then if you're a five person shop making routers and you publish the firmware source under a license that allows anyone to make and distribute modifications you're all set. And if you're Apple or Microsoft and you want to make a router without publishing the source code, you post the enormous bond which you have no trouble doing because you're an enormous company and you're all set.
The typical IoT company not surviving the typical lifecycle of their products shows that IoT is a seriously dorked up idea. Anybody deploying them who values security should choose products that can be updated even after the vendor is gone.
> How are you going to use a warranty from a company that no longer exists to get a security update for a product a million consumers still have?
> The typical IoT company not surviving the typical lifecycle of their products shows that IoT is a seriously dorked up idea. Anybody deploying them who values security should choose products that can be updated even after the vendor is gone.
But then many consumers value cost or other things over security, which is why you need all the devices to be able to be updated even after the vendor is gone.
> I was not talking about using warranty for this.
Then why are you talking about a warranty to begin with?
> But then many consumers value cost or other things over security, which is why you need all the devices to be able to be updated even after the vendor is gone.
This is only possible if the firmware is replaceable. Along with a practical update mechanism it also requires the possibility to create an update package. That can be achieved by using open source components, but there might be other mechanisms. For example making provisions in case of bankruptcy.
> Then why are you talking about a warranty to begin with?
I was making a comparison with warranty law, which exists to ensure a certain minimum bar for quality and longevity of products. Which is usually desired, therefore legal provisions for updateability of hardware should also be required. Note that a firmware update might well become required within the warranty period.
This is by no means a new concern. IP cams, home routers, robot vacuums, and internet-enabled fridges exist for a long time already. The warranty period was never intended to cover "smart" devices. Maybe forcing an extension of the warranty period for such devices is enough to take care of the problem.
reply