Teslas "virtual power plant" is only for Tesla Powerwall. There's no V2G capabilities in any Teslas to date, and I don't think there's even hardware support for it. The Tesla Cybertruck has V2L capability, so it might have the necessary hardware to do V2G with some software updates, but I kinda doubt it.
The Tesla "virtual power plant" does reserve some capacity for you, and technically you can charge your car with that. A single Tesla Powerwall is "only" 10kWh, and with inverter losses and such you're likely seeing closer to 8kWh of usable energy if you charge your car with it. You're probably much better off just using it to run your appliances so you mitigate some of the losses with more inverters in the mix.
The battery chemistry used in most EV batteries are not really optimized for a lot of cycles, and they're somewhat expensive to replace, so you're much better off just buying batteries that are made for the purpose. You also have fairly limited inverter capacity in most EVs, as the inverter installed is scaled to run the cars AC and infotainment system, which doesn't really need that much.
You also have to deal with either having beefy automatic/manual transfer switch or separate isolated circuits to prevent back feeding the grid electricity in an outage or during maintenance.
There's a lot of people repurposing used Nissan Leaf-batteries for what you're describing.
The numbers in the post are 2.2 and 3.6 kW. Even 2.2kW would cover virtually all of my use.
I don't want to buy a battery for the purpose because it doesn't make sense economically. If I could get a car with this functionality though for a similar price as cars without it, that would be a big bonus.
I'm not going to pretend that there aren't edge cases and personal situations that would make it viable, but my initial comment was on consumers as a whole.
And we're talking about averages. So sure, if you have gas boiler you probably could get by with a 2,2kW or 3,6kW inverter, but just powering a simple kettle would likely trip a fuse. You can get around it with just being a little conscious about what you power up, and when you power things up, but I'd argue that most people don't want to deal with that.
And remember, if you're grid connected you either have to have a transfer switch or separate circuits if you want to use this as a backup when the grid goes down. It complicates things a whole lot.
> so you're much better off just buying batteries that are made for the purpose
Or even just used EV batteries. I personally don't think that battery recycling is as big of an issue as some people say. But, if I'm wrong, a cheap worn-out EV battery with "only" 50% capacity is still very useful as a home backup.
I don't really see how rootless containers change anything at all. You're still "just" one kernel privilege escalation away from breaking out. The level of isolation is much better in virtual machines, and the performance penalty is comparable these days.
The virtual machine images are a bit heavier, since you need a kernel and whatnot, but it's negligible at best. The memory footprint of virtual machines with memory deduplication and such means that you get very close to the footprint of containers. You have the cold start issue with microvms, but these days they generally start in less than a couple of hundred milliseconds, not that far off your typical container.
Memory de-dup is computationally expensive, and KSM hitrate is generally much worse than people tend to expect - not to mention that it comes with its own security issues. I agree that the security tradeoffs need to be taken seriously but the realworld performance/efficiency considerations are definitely not negligeable at scale.
There are also significant operational concerns. With containers you can just have your CI/CD system spit out a new signed image every N days and do fairly seamless A/B rollouts. With VMs that's a lot harder. You may be able to emulate some of this by building some sort of static microvm, but there's a LOT of complexity you'll need to handle (e.g. networking config, OS updates, debugging access) that is going to be some combination of flaky and hard to manage.
I by no means disagree with the security points but people are overstating the case for replacing containers with VMs in these replies.
And these overheads are even smaller if you use unikernels as per the paper. Eg, cold starts of a few milliseconds depending on the app/size of the image.
I'm struggling a little bit to grasp all the concepts when we start talking about unikernels, wasm and so on. Hopefully that's just a sign of the maturity of it, and not a sign of my mental decline. But on paper (as I understand it) it looks /so cool/.
Unikernels aren't too complicated conceptually. They're more or less a kernel stripped down to the bare minimum required by a single application. The complete bundle of the minimal kernel and application together is called a unikernel. The uni- prefix means one as in the kernel only supports one userspace application, instead of something like linux, which supports many. The benefits, as mentioned in the paper and in this thread are that you can run that as a vm, since it contains it's own operating system, unlike a container which is dependent on the host operating system. Also, they boot very quickly.
Agree with epr's definition of a unikernel (and no, no mental decline on your part, this isn't always well defined).
First off, a unikernel is a virtual machine, albeit a pretty specialized one. They're are often based on modular operating systems (e.g., Unikraft), in order to be able to easily pick the OS modules needed for each application, at compile time. You can think of it as a VM that has a say NGINX-specific distro, all the way down to the OS kernel modules.
VMs provide what's called hardware-level isolation, running on top of a hypervisor like KVM, Xen or Hyper-V. Wasm runs higher up the stack, in user-space, and provides what's called language-level isolation (i.e., you could even create a wasm unikernel, that is, a specialized VM that inside runs wasm (eg, see https://docs.kraft.cloud/guides/wazero/). Generally speaking, the higher you go up the stack, the more code you're running and the higher the chances of a vulnerability.
I think the lines between software and hardware-based are a little blurred these days with accelerator cards and whatnot. It's just a lot harder to come with the same level of guarantees when you're basically running a hypervisor on top of it.
In AWS you don't even do neighbour discovery through ARP. Or that's a lie, you do, you get a arp reply, but it's not from any of your devices on the network. And traffic is authenticated and authorized at both the source and destination, so you can't do fun things like manipulating arp tables. You get a lot of nice features when you have a fully software defined network, but it comes with a couple of caveats, like you mentioned here. I doubt we'll ever see "real multicast support" in the sense that network engineers are used to.
Compared to the amount of oil used for making fossil fuels plastic is almost a rounding error. So he's technically right, but not really if you look at th bigger picture.
Ehh we can go back and forth on semantics all day but I think the point still stands that as long as there is a demand for plastics there will be no phasing out oil.
I've always found that Terraform does it exceptionally well, mostly because of the dependency graph and how good providers map resources so that they don't end up in a dead lock.
Wild guess: They use significantly more electricity than the average customer that does just about anything else with their hardware. The GPU can easily run at hundreds of watts, and when you add in the required cooling you're probably at 1.5-2x that in total power usage.
This is not a proof of work (bitcoin or pre merge ethereum) node and it does not use more electricity. They singled out solana seemingly and I’m unsure why. We moved about 300 services off of dedicated higher end Hetzner nodes within a week.
I don't really see that happening unless they make the C919 much more efficient. There's probably a market for Comac where Boeing and Airbus aren't allowed to sell due to sanctions or whatnot, but that's a separate issue.
The Tesla "virtual power plant" does reserve some capacity for you, and technically you can charge your car with that. A single Tesla Powerwall is "only" 10kWh, and with inverter losses and such you're likely seeing closer to 8kWh of usable energy if you charge your car with it. You're probably much better off just using it to run your appliances so you mitigate some of the losses with more inverters in the mix.