Since we're in feedback mode, 2.16 has no BitLineBar reference to feed to the comparators. I had to cheese the level by connecting the "capacitor" outputs straight to the outputs, and it worked.
On the capacitor though, the capacitor level is weird as you don't build the capacitor charge system with transistors. Though I definitely get that the simulation engine is for digital stuff, not analog :)
Also a general feedback on the time-based challenges: dial them back. A lot. Most of them are just not interesting and have zero learning value. In fact, the "DRAM refresh" one just made me quit the game (clicking on 8 rows to keep them fresh). Okay, 10s is enough, I got the point. No need to hold up for a whole minute. Kinda same for the hex one. However, some of them are good, and the UI for the binary ones is great, especially for the two's complement one!
Small nitpick on the UI: some blocks don't have their connections aligned with the grid, making the wiring OCD-incompatible. But that's minor. It's a shame since the wire routing algorithm works quite well overall, and I'm impressed an LLM could produce that good of an UI!
Otherwise, quite a fun little game, if slow paced when one already knows some bits of digital logic. Keep up!
Ever tried to uninstall an antivirus on windows? Or any program that does not want to be uninstalled? I've had programs whose uninstall.exe was no different than /bin/true.
On this point, Windows is no better than macOS: the OS relies on the goodwill of the developers to provide working uninstallers. The only protection is a world where the OS provider does the application packaging: Linux repositories, Mac App Store, Windows Store. And even then, apps are still free to litter your filesystem at runtime, unless they're heavily sandboxed. Then FlatPak it is, or iOS apps or Android apps. Not great.
Yes, I have uninstalled antivirus. The uninstaller removed most of the files, except those in memory. I turned off the computer at the end of the day, and after startup the next morning the remaining files were gone.
The only remaining files were the "user space" like custom preferences or files created by the user using the program. The uninstaller rightfully leaves it up to the user to decide what to do with those.
Except actual routers don't handle the traffic on the CPU, they have dedicated hardware to actually handle the packets. The CPU basically runs the OS, configures the hardware router, and does housekeeping tasks (e.g. ARP or FDB expirations, NAT cleanup, etc). The only packets that ever reach it are "trap to CPU" situations that don't require acceleration as those are rare or expensive to implement in hardware (e.g. better suited to a CPU). Those usually include management protocols (ICMP, ARP, NDP, STP, etc) or packets with unknown destination (e.g. the first packet to an IP that requires ARP resolution).
That's how you can have multi-Gbps on a router with a 200MHz MIPS CPU. Or Tbps on a router with a quad-core Xeon.
The TL;DR is to have two vlans on the cable from your switch (called a "trunk"), "lan" and "wan", carrying the respective LAN and WAN networks. Then, on the Pi, create two vlans on the underlying Ethernet interface. Then those two VLAN interfaces can be configured just like the LAN and WAN interfaces of the router. On the switch, you’d dedicate one port to the WAN by adding it to the WAN VLAN without tagging, and the other interfaces do the LAN VLAN, also untagged.
I’ll pick nftables over iptables any day, it’s leagues better (granted, it’s not hard). The nftables wiki is great, as the syntax and modules are documented in a single easy to read page.
As an added bonus, you get atomic updates of all chains for free.
Granted, for simple usecases, ufw or firewalld may be simpler though.
You can still use the iptables interface for nftables rules if you'd like, but I think you miss out on things like atomic application of rulesets, ranges, lists, and variables (not shell variables).
In this very specific case, battery storage would not have helped (in fact, it would have worsened the problem). One of the issues in the failure is renewables, but not because of intermittence. It's because of their ~infinite ramp and them being DC.
Anything that's not a spinning slug of steel produces AC through an inverter: electronics that take some DC, pass it through MOSFETs and coils, and spits out a mathematically pure sine wave on the output. They are perfectly controllable, and have no inertia: tell them tout output a set power and they happily will.
However, this has a few specific issues:
- infinite ramps produce sudden influx of energy or sudden drops in energy, which can trigger oscillations and trip safety of other plants
- the sine wave being electronically generated, physics won't help you to keep it in phase with the network, and more crucially, keep it lagging/ahead of the network
The last point is the most important one, and one that is actually discussed in the report. AC works well because physics is on our side, so spinning slugs or steel will self-correct depending on the power requirements of the grid, and this includes their phase compared to the grid. How out-of-phase you are is what's commonly called the power factor. Spinning slugs have a natural power factor, but inverter don't: you can make any power factor you want.
Here in the spanish blackout, there was an excess of reactive power (that is, a phase shift happening). Spinning slugs will fight this shift of phase to realign with the correct phase. An inverter will happily follow the sine wave measured and contribute to the excess of reactive power. The report outlines this: there was no "market incentive" for inverters to actively correct the grid's power factor (trad: there are no fines).
So really, more storage would not have helped. They would have tripped just like the other generators, and being inverter-based, they would have contributed to the issue. Not because "muh renewable" or "muh battery", but because of an inherent characteristic of how they're connected to the grid.
Can this be fixed? Of course. We've had the technology for years for inverters to better mimic spinning slugs of steel. Will it be? Of course. Spain's TSO will make it a requirement to fix this and energy producers will comply.
A few closing notes:
- this is not an anti-renewables writeup, but an explanation of the tech, and the fact that renewables are part of the issue is a coincidence on the underlying technical details
- inverters are not the reason the grid failed. but they're a part of why it had a runaway behavior
- yes, wind also runs on inverters despite being spinning things. with the wind being so variable, it's much more efficient to have all turbines be not synchronized, convert their AC to DC, aggregate the DC, and convert back to AC when injecting into the grid
I agree with your detailed assessment, but importantly, I argue more battery storage would've allowed for the grid to fail gracefully through rapid fault isolation and recovery (assuming intelligent orchestration of transmission level fault isolation). Parallels to black start capabilities provided by battery storage in Texas (provided by Tesla's Gambit Energy subsidiary). When faults are detected, the faster you can isolate and contain the fault, the faster you can recover before it spreads through the grid system.
The storage gives you operational and resiliency strength you cannot obtain with generators alone, because of how nimble storage is (advanced power controls), both for energy and grid services.
> Can this be fixed? Of course. We've had the technology for years for inverters to better mimic spinning slugs of steel. Will it be? Of course. Spain's TSO will make it a requirement to fix this and energy producers will comply.
This is synthetic inertia, and is a software capability on the latest battery storage systems. "There was no market mechanism to encourage the deployment of this technology in concert with Spain’s rapid deployment of solar and wind." from my top comment. This should be a hard requirement for all future battery storage systems imho.
> Large-scale battery energy storage systems (BESS) already play a major role in ancillary service markets worldwide. Batteries are especially suitable for fast response times and thus focus on applications with relatively short reaction times. While existing markets mostly require reaction times of a couple of seconds, this will most likely change in the future. During the energy transition, many conventional power plants will fade out of the energy system. Thereby, the amount of rotating masses connected to the power grid will decrease, which means removing a component with quasi-instantaneous power supply to balance out frequency deviations the millisecond they occur. In general, batteries are capable of providing power just as fast but the real-world overall system response time of current BESS for future grid services has only little been studied so far. Thus, the response time of individual components such as the inverter and the interaction of the inverter and control components in the context of a BESS are not yet known. We address this issue by measurements of a 6 MW BESS's inverters for mode changes, inverter power gradients and measurements of the runtime of signals of the control system. The measurements have shown that in the analyzed BESS response times of 175 ms to 325 ms without the measurement feedback loop and 450 ms to 715 ms for the round trip with feedback measurements are possible with hardware that is about five years old. The results prove that even this older components can exceed the requirements from current standards. For even faster future grid services like synthetic inertia, hardware upgrades at the measurement device and the inverters may be necessary.
My immediate thought. Except not "vanilla" YAML, but a safer stricter subset (iirc some people published a spec about it): no implicit conversion, no norway problem, etc. If only this gained actual traction.
The JSON in the article is a bit, let's say, heavy on the different objects and does not try to represent anything useful with most keys. All the things like `greaterOf`, `sum`, etc are much better expressed as keys than `{"children": [{"type": "greaterOf", ...}]}`.
Basically something that feels an reads like "freeform" yaml, yet that has an actual spec.
"- yeah I have a macbook" "- what, an air?" "- no a macbook" "- ..?" "- the one in colors, not the one-port 12 inch one from 2015 but you know it just released!"
This already happened in 2015, they probably don't want for it to happen again.
Honestly the 8GB is not really an issue. As opposed to basically every other computer on this price range, Apple puts real storage in their machines, making a well-tuned swap simply transparent. I'd also bet they have very performant hardware engines for memory (de)compression.
A few years ago, my parents asked me for a laptop for my sisters, for university use. We targeted this price range. It's shocking but pretty much all laptops from Dell, HP, etc come with some form of eMMC storage. And I'm not speaking about the other specs like display or build quality. We ended up buying second-hand M1 and M2 macbook airs, and both I and my sisters are very happy about it.
(also, as the "tech support guy" of the family, I'm oh my so happy about them not running windows)
The SSD in the Neo only manages around 1,500 MB/s in sequential benchmarks, it's not an impressive drive.
> It's shocking but pretty much all laptops from Dell, HP, etc come with some form of eMMC storage.
I just went to Dell's website and picked a random $400 laptop and it had an NVME SSD. The $650 Dell 14 Essential also is NVME. Both of which are M.2 so easily upgraded, replaced, or have data recovery done on them. The only eMMC options I'm seeing are the $300 Chromebooks? Which is no where close to "pretty much all laptops." In fact it'd be "pretty much none of the laptops"
> The SSD in the Neo only manages around 1,500 MB/s in sequential benchmarks, it's not an impressive drive.
That's sequential, not what you want for swap, but already a good start. I agree that it's not impressive, but already leagues ahead of a SATA SSD. And for swapping a 8GB machine it's more than enough (when the swap pattern is sequential though): you swapped your whole system memory in 3 seconds, which is impressive.
> The only eMMC options I'm seeing are the $300 Chromebooks? Which is no where close to "pretty much all laptops." In fact it'd be "pretty much none of the laptops"
Then it's good the situation improved, genuinely! Less e-waste being on the store shelves. Pretty sure windows is nigh unusable on eMMC. And yes, those were sold alongside chromebooks, but at a markup of a "real computer" despite having roughly the same internals.
Another thing that could impact, though, is availability in different markets. I am in France, and the offerings are perhaps worse than in the US? (quite likely, in fact). Add to that the usual price markup where US companies tend to do, at best, 1 USD = 1 EUR, and we get worse machines for the equivalent price range.
> you swapped your whole system memory in 3 seconds, which is impressive.
As a user a 3 second hang is unusable. Also, critically, swap consumes the life of the drive. Since the Neo's isn't user-replaceable, a 3-5 year lifespan before death is actually a non-trivial compromise, although time will tell on that one I suppose.
Should be fast enough to swap in a browser page I guess. Overall you're right that it's the wrong device for memory hungry applications, but it's not the target audience.
On the capacitor though, the capacitor level is weird as you don't build the capacitor charge system with transistors. Though I definitely get that the simulation engine is for digital stuff, not analog :)
Also a general feedback on the time-based challenges: dial them back. A lot. Most of them are just not interesting and have zero learning value. In fact, the "DRAM refresh" one just made me quit the game (clicking on 8 rows to keep them fresh). Okay, 10s is enough, I got the point. No need to hold up for a whole minute. Kinda same for the hex one. However, some of them are good, and the UI for the binary ones is great, especially for the two's complement one!
Small nitpick on the UI: some blocks don't have their connections aligned with the grid, making the wiring OCD-incompatible. But that's minor. It's a shame since the wire routing algorithm works quite well overall, and I'm impressed an LLM could produce that good of an UI!
Otherwise, quite a fun little game, if slow paced when one already knows some bits of digital logic. Keep up!
reply