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.
I have a VAG ICE vehicle and had a problem with the navigation system not working. When I brought it in to get it fixed, they apparently put a completely new version of the software on the hardware.
Suddenly everything was fast. No slow lags anymore. System is ready even before I start the engine. Navigation now zooms smoothly. Voice recognition is finally working 95% of the time and only tripping up on hard words.
I don't know how many different software versions are out there but apparently they are working on system speed without changing the hardware. Maybe I got an early access version and they are waiting for data before they push it to all vehicles.
Counterpoint from me: I've been using Jetbrains tools for over 10 years as well. Mostly Webstorm and Rider and it's all working well. Sometimes there are bugs, yes, but I had plenty those in VSCode and Visual Studio as well.
Aside from their initial AI plugin rollout fiasco it has been smooth sailing for me.
