This is typical CDU conservative talk from Merz. He is on a war path with anything Angela Merkel did because she saw him as politically inexperienced and shunned him. So he had to work for Blackrock.
The CSU (the Bavarian equivalent and permanent coalition partner of the CDU) is also demanding to reactivate nuclear power plants but at the same time is not willing to store any spent nuclear fuel. The CSU is also notoriously anti renewables and does not want new power lines in their "beautiful scenery" to get the renewable power from northern Germany to Bavaria.
Hard to understate just how expensive. Here in Montreal where ice storms kill and cause billions in damage, we still don't bury the main transmission lines. We been burying almost everything _in_ the city where having to repair millions of individual connections (again) would be impractical, but it's relatively simple to repair the limited major lines into the city.
From CBC:
> Current estimates are that it would cost five to 10 times more to distribute electricity to a big city via underground cables, and that not all of nature's problems would be alleviated even if that were done.
> Horizontal directional drilling costs $10 to $30 (USD) per linear foot with upfront fixed costs of $30K or so.
Underground power lines are expensive, but not that expensive. As far as I know, you dig a ditch, put the power line into it, and then put the material back in over the top.
To pass under roads, under rivers, avoid digging up tarmac, houses, orchards, crops, things on the surface, etc.
Trenching is straightforward, I mention horizontal directional drilling as that puts a cap on the total cost of going underground Vs pylons and above ground stringing.
I don't know what you are doing but I have my Arch Linux running since about 2013. I needed to intervene a few times, I think 4 times in total but the base installation in from 2013, now nearly 13 years ago.
I share the same sentiment. I've had the same Arch install running since ~2016 and have been using Arch since about 2013 and the number of times I've needed to chroot from a live image is under 10 and were mostly related to systemd breaking things during an update which is pretty much entirely no longer an issue these days.
Compared to Windows-land where nuking and reinstalling the entire OS is a routine maintenance task, checking arch news to see if there's any manual intervention and running `pacman -Syu` is all I really ever think about.
I think this is a very interesting observation, because my experience has been fairly opposite. Disclaimer, I've grown up with windows.
Yet I've never had to reinstall windows on any of my devices ever. I've never had things behave in unusual or unpredictable ways.
Meanwhile, a highly suggested utility (on reddit, SE/SO, and even a few distro forums) for touchpad gestures borked my gnome setup. (Uninstalling it, as you might have guessed from my story and tone, did diddly squat.)
Just today I manually flushed my dnf packages (or clear them? Not sure of the terminology.) In the past, I had to debug manually because apparently the default timeout for Fedora was causing timeout issues with a few 100ms internet latency. That was a fun rabit hole "why can't I install an app that's only available via dnf install" "Oh, because Fedora assumes you have good internet. But don't worry if you have Ubuntu, because that doesn't have these issues!".
...I've never even been made aware what download timeouts windows has. As it should be for a user.
I could go on and on. My windows partition goes nearly months without sleep, typically only rebooting if I run out of battery or want to install an update. Linux... doesn't have hibernate yet. Fortunately it doesn't matter! ...Because some odd memory leak (and gpu driver stuff perhaps?) forces me to shut down ever so often. Oh well.
I'm not sure where you get the idea that Linux doesn't have hibernate - there's both userspace systemd-hibernate bindings and also the kernel swsusp which both work equally well (although you may need to make sure you have a large enough swap partition for it to function)
Also the other issues you're describing do sound frustrating but I think it's a byproduct of an entirely different culture. Exposing user-configurable timeouts and you being made aware of it during troubleshooting is something that enables you to deeply understand your system and how it's configured. In Windows, even if there is defaults for things like that it likely is not exposed to the user or configurable at all. If the default settings are bad you're just stuck with it and you aren't expected or intended to modify anything to better suit your needs.
My experience with Arch is mostly due to having been a fairly proficient Linux user prior to switching over and being very comfortable reading the wiki or bbs and tinkering to find solutions to things. A lot of the prior experiences I had with Debian or other "friendly" distros kind of put me through the ringer too and I've found that having the rolling release with Arch fits my preferred workflow much better than something like Ubuntu or Debian or Fedora or the other "batteries included" distros.
That's pretty good, I'm jealous! The last time I reinstalled my OS (Slackware) from scratch was 2009, but I run into serious problems every couple of years when upgrading it to 'Slackware64-current' pre-release, because Slackware's package manager doesn't track dependencies and you can just install stuff in the wrong order: I usually don't upgrade the whole OS at once... just have to fix any .so link errors (I've got a script to pull old libraries from btrfs snapshots). I've even ended up without a working libc more than once! When you can't run any program it sure is useful that you can upgrade everything aside from the kernel without rebooting!
Sometimes it's not about doing nothing but only being allowed to do the same stuff over and over again to do because there is "no budget" to rewrite the codebase to automate the process.
I expected one person to step up, do the verification, and F-Droid can use that signing key to distribute apps to phones with facism mode enabled. They just need to pick an app ID that isn't already in use, could even be sequential under org.fdroid.*
It's quite scary that there's no such idea being floated in the post. Apparently they're ready for F-Droid to be relegated to the realms of Google-free devices that nobody, outside of a few hardcore privacy activists, is currently willing to use. Maybe that'll change, but I doubt significantly enough for governments to reconsider which OSes and third-party stores they need to support
OpenWISP states in its docs that you should be running at least 20 devices to make it worth it. [1] So it's not supposed to be a easy way to manage a few devices for home users.
> However, OpenWISP may not be the best fit for very small networks (fewer than 20 devices), organizations lacking IT expertise, or enterprises seeking open-source alternatives solely for cost-saving purposes.
It's for exactly that reason I started with OpenSOHO.
It is targeted towards the typical home and small office network with less than 20 OpenWRT devices. (although there is no hard limit).
Initially I fiddled a bit with full Open wisp stack to try to make a smaller edition. But I quickly stopped that. But I know their two daemons well.
The config one is a neat little piece of software. It will merge UCI configs and check the connectivity. You can adjust virtually any file with it (although not always with merging). My main issue with it is that it can't be easily temporary disabled from the central controller (I currently implement it by not sending the config, but that triggers retries on the AP end)
The monitoring one spits out an amazing amount of data, although it needs some post processing to make it actually useful. Unfortunately that one can't be extented to add custom entries. I'm currently missing an easy way to see which MAC address is connected which LAN port since OpenWRT DSA puts everyone one the "br-lan".
The whole thing is polling based. So it is quite chatty on the network since I use lower polling rates to make the updates fast. (I suspect on a setup with 100+ you will have longer polling times). All in all the existence of these daemons saved me a ton of time handling networking corner cases. Kudos to the Openwisp team.
I had a GPT-5 agent help me think through a pull-only controller/agent model for OpenWRT. The controller keeps desired configs in git and serves the current version as a tiny tar/zip over HTTP(S), using the last commit ID as the ETag. Agents poll every ~5s with If-None-Match, so it’s usually a 304 and near-zero overhead; when the version changes they fetch the archive and apply it. The controller location is advertised via DHCP; no long-lived sockets or SSH push.
On the device side, the agent only activates if there’s no WAN (so the main router isn’t a client). A new AP gets a LAN IP via DHCP, discovers the controller, pulls its config, and if none exists the controller can hand back a default Wi-Fi setup to come online immediately. Start with Wi-Fi-only changes (reload instead of reboot), aim for a “plug into LAN + power and it just joins” UX, and avoid OpenWISP complexity. It’s built from boring, reliable primitives: DHCP, HTTPS, git, tar, Lua.
I think I'm going to have an agent start coding this up today and see where it gets.
I do notice quite some people focus the autodiscovery part where for me that's less of an issue (I do agree it would be VERY nice). The OpenWISP configuration on each AP is limited to: set IP address of controller & shared secret and click OK. The rest is all magically done for you by the controller.
I do like the 304 idea, in practice it uses the same conceptual idea as the OpenWISP system: check if the MD5 (instead of SHA1) for the current config and the controller config are still identical and download and apply if not.
An important reason I why chose the OpenWISP is that they "just work", are well tested and included in the OpenWRT package list. My main goal is to keep the OpenSOHO project as small as possible ;)
I've been weighing the pros/cons of using OpenWISP. I considered using DHCP to distribute the controller IP and shared secret.
For now, I like reasoning about /etc config files. I'm more familiar with those than OpenWISP. Adopting an abstraction like that offers some portability and possibly future proofing. But that is just the config format and how it is applied though really.
I think once the router is setup, most SOHO users only ever have to add/replace (provision) APs and manage the WiFi settings. I want to make that kind of provisioning and management automatic. Making the APs as stateless as possible - kind of like a Chromebook. The agent will only have basic dependencies (lua, curl, tar).
For this to really work it'll probably have to grow to support VLAN-backed SSIDs and wireless backhaul links. Wireless links would probably need to be wired for their first time setup. But I'd be happy even if it just solved managing my own APs and SSIDs.
The Openwisp agents running on the AP are surprisingly lightweight (they do use Lua, tar, curl and a bit of shell scripting)
VLAN backed SSIDs are one of main reason I started OpenSOHO (although support is not there yet) I don't want to log into each AP to set it up manually.
I do have a wired back haul, but support for wireless backhaul will probably arrive, since quite some people have one set up.
In case you would find an easy method of bootstrapping the setup via DHCP, certainly let me know! (Maybe that's easier to be discussed on GitHub)
Are you driving fast(er than with a ICE vehicle) in corners? Since EVs have a very low center of mass, drivers tend to take corners a lot faster than they would in ICE vehicles which is very hard on the tires.
A friend got hit by this as well and since readjusting his driving style (read: not flying through corners for the fun of it) he gets more (but still not equal) miles on his EV's tires before he needs new ones.
Because it would have catastrophic consequences on the world order. Normalizing nuking your opponent will invite Russia to nuke Ukraine, China Taiwan, and North Korea South Korea. The USA will not let Israel nuke anybody.
The CSU (the Bavarian equivalent and permanent coalition partner of the CDU) is also demanding to reactivate nuclear power plants but at the same time is not willing to store any spent nuclear fuel. The CSU is also notoriously anti renewables and does not want new power lines in their "beautiful scenery" to get the renewable power from northern Germany to Bavaria.
reply