Even 95% is on the low side. Most residential-grade PV grid-tie inverters are listed as something like 97.5%. Higher voltage versions tend to do better.

Yeah, filters essentially store power during one part of the cycle and release it during another. Net power lost is fairly minimal, though not zero. DC needs filtering too: all those switchmode power supplies are very choppy.

I’m not sure there are any power grids past the tens-of-megawatt range that aren’t just a 2/3/4 terminal HVDC link.

Railway DC supplies usually just have fat rectifiers and transformers from the AC mains to supply fault current/clearing and stability.

Ships are where I would expect to start seeing them arrive, or aircraft.

Almost all land-based standalone DC networks (again, not few-terminal HVDC links) are heavily battery backed and run at battery voltage - that’s not practical once you leave one property.

I’m sure there are some pretty detailed reports and simulations, though. A reduction in cost of multi-kV converters and DC circuit breakers is essential.

PV inverters often have around 1-2% losses. This is not very significant. You also need to convert the voltage anyway because PV output voltage varies with light level.

Buck/boost converters work by converting the DC current to (messy) AC, then back to DC. If you want an isolating converter (necessary for most applications for safety reasons) that converter needs to handle the full power. If it’s non isolating, then it’s proportional to the voltage step.

Frequency provides a somewhat convenient method for all parties to know whether the grid is over- or under- supplied on a sub-second basis. Operating solely on voltage is more prone to oscillation and requires compensation for voltage drop, plus the information is typically lost at buck/boost sites. A DC grid would likely require much more robust and faster real-time comms.

The AC grid relies on significant (>10x overcurrent) short-term (<5s) overload capability. Inrush and motor starting requires small/short overloads (though still significant). Faults are detected and cleared primarily through the excess current drawn. Fuses/breakers in series will all see the same current from the same fault, but we want only the device closest to the fault to operate to minimise disruption. That’s achieved (called discrimination, coordination, or selectivity) by having each device take progressively more time to trip on a fault of a given size, and progressively higher fault current so that the devices upstream still rapidly detect a fault.

RCDs/GFCIs don’t coordinate well because there isn’t enough room between the smallest fault required to be detected and the maximum disconnection time to fit increasingly less sensitive devices.

Generators are perfectly able to provide this extra fault current through short term temperature rise and inertia. Inverters cannot provide 5-fold overcurrent without being significantly oversized. We even install synchronous condensers (a generator without any actual energy source) in areas far from actual generators to provide local inertia.

AC arcs inherently self-extinguish in most cases. DC arcs do not.

This means that breakers and expulsion type fuses have to be significantly, significantly larger and more expensive. It also means more protection is needed against arcs caused by poor connection, cable clashes, and insulation damage.

Solid state breakers alleviate this somewhat, but it’s going to take 20+ years to improve cost, size, and power loss to acceptable levels.

I expect that any ‘next generation’ system is likely to demand a step increase in safety, not merely matching the existing performance. I suspect that’s going to require a 100% coverage fibre comms network parallel to the power conductors, and in accessible areas possibly fully screened cable and isolated supply.

EVs and PV arrays get away with DC networks because they’re willing to shut down the whole system in the event of a fault. You don’t want a whole neighborhood to go dark because your neighbour’s cat gnawed on a laptop charger.

There should be no need for tuning, tweaking, or optimizing on functionality this basic.

If you ask the processor, it will spit out a graph like this telling you what threads/cores share resources, all the way up to (on large or server platforms) some RAM or PCIe slots being closer to certain groups of cores.

Acorn/ARM apparently did much the same thing.

It was a few years back, but after it hit ChromeOS EOL I’m pretty sure it just got some KDE distro; I don’t think I even used LXDE. Didn’t need to do much.

I was mostly using it for web browsing, forums, spreadsheets, documentation etc. Nothing particularly strenuous.

I did have one really fun time of modifying PDF engineering drawings by opening them in Libre Office Draw which it handled kinda OK.

It did get a 240GB SSD but everything else was soldered.

I got a surprising amount of use out of a similarly configured C720 as a general purpose portable machine.

Essentially no processors follow a standard. There are some that have become a de facto standard and had both backwards compatibility and clones produced like x86. But it is certainly not an open standard, and many lawsuits have been filed to limit the ability of other companies to produce compatible replacement chips.

RISC-V is an attempt to make an open instruction set that any manufacturer can make a compatible chip for, and any software developer can code for.

I’ll take ‘Violations of the Magnuson-Moss Warranty Act’.

With software that misuses /tmp, I’m more worried about burning out my SSD endurance than running out of RAM.

Indeed, the US has a major lack of fixed-line competition and lack of regulation. Starlink doesn’t really help with that, at least in urban areas.

I’m not familiar with the wireless situation. You’re saying that there are significant coverage discrepancies to the point where many if not most consumers are choosing a carrier based on coverage, not pricing/plans? There’s always areas with unequal coverage but I didn’t think they were that common.

Here in NZ, the state funding for very rural 4G broadband (Rural Broadband Initiative 2 / RBI-2) went to the Rural Connectivity Group, setting up sites used and owned equally by all three providers, to reduce costs where capacity isn’t the constraint.

Starlink plugs the rural coverage gaps, but in urban areas it’s still more expensive than either conventional fixed-line connections or wireless (4G/5G) broadband. Even in rural areas, while it’s the best option, it’s rarely the cheapest, at least in the NZ market I’m familiar with.

It also doesn’t have the bandwidth per square kilometre/mile to serve urban areas well, and it’s probably never going to work in apartment buildings.

This is a funding/subsidisation issue, not so much a technical one. I imagine Starlink connections are eligible for the current subsidy, but in most cases it’s probably going to conventional DSL/cable/fibre/4G connections.

The screen turning off when it automatically locks is an added bonus; the priority is to be able to command the system to simultaneously lock and turn off the screen. You’re correct that the setting at zero seconds safely achieves that.

I’ve had other, more stupid uses for running commands, though I don’t think any are actively in use.

Taking actions on network reconfiguration, charge completion, and SMART failure are all things that spring to mind. It’s nice to be able to set those kinds of things in a GUI rather than putting them in /etc/something.d

What I want is not (just) that the screen turns off when the lock timer times out, but that I can push ‘lock’ or a key combination and have the system lock and the screen turn off immediately.

The new ‘when locked, turn off screen’ setting should help with this, but setting it too low will presumably make it hard to unlock.

For running backups, ‘after a period of inactivity’ could help.

It still seems like the removal of a useful feature.

I use it for turning off the screen when the screen is locked, allowing background tasks to continue.

It’s also useful to run things like backups when the system is more likely to be idle.

Aggregate bandwidth now rivals or slightly exceeds gigabit wired connections.

Where that aggregate bandwidth is shared amongst large numbers of users, bandwidth per user can suffer dramatically.

Low density areas may be fine, but cube farms are an issue especially when staff are doing data intensive or latency sensitive tasks.

If you’re giving employees docking stations for their laptops, running ethernet to those docking stations is a no-brainer.

Moving most of the traffic to wired connections frees up spectrum/bandwidth for situations that do need to be wireless.

Swifts and Mirages can be under 900kg.

Boeing and Microsoft: same shit, different cloud.

Yeah, YT’s current anti-adblock crusade means you need a proper ad blocker built into the browser or a third party client.

There are AdBlock options for Android that can work on apps. Generally you need to route all internet traffic via the AdBlock app which requires root, a faux-VPN, or a PiHole type solution.

It can usually only do host-level blocking but that’s generally enough.