c0l0

I guess it is, but solar can only be part of the answer: You need a solid plan (and all the infrastructure that implementing this plan involves) for when the sun does not shine, because in the more northern parts of Europe especially, energy consumption is highest during seasons in which sunlight is (relatively) scarce.

Also, "the grid" cannot absorb any amount of solar energy - so if you choose to address (at least parts) of the above challenge with a photovoltaic build-out that results in massive excess capacity during summer, there needs to be a plan (and again, its implementation) to handle that.

Long-term, that's the smart and also necessary move. But it can't be done overnight, and the transition has its significant challenges. I hope they don't mess it up it and will address these problems rationally - but given how most EU leaders have acted over these past few years, I remain painfully unconvinced that they will.

Netgear GS308T, Netgear GS108T v3, and HPE JG925A.

With the 25.12 release, the luci app to use ASU for upgrades became installed by default in OpenWrt's "vanilla" images the project builds and provides for supported hardware and devices.

Previous OpenWrt releases at least as far back as 21.02 could be equipped with the same degree of ASU support by installing a single package (luci-app-attendedsysupgrade) and its dependencies.

Your OpenWrt ecosystem knowledge seems oudated; upgrades are a solved problem since the advent of "Attended Sysupgrade": https://openwrt.org/docs/guide-user/installation/attended.sy...

It's been included in all suitable default image configurations starting with OpenWrt release 25.12.

I do run OpenWrt on my x86-based router, on my AP, and even on my managed switches, and have no regrets.

Windows actually needs to be laid to rest forever. Win32 may live on as a legacy/stable API (via WINE) on superior free and open platforms.

Living in a city in Europe in a very decent apartment in a building that was erected in the 1880s (sic), this article made me chuckle - but also feel bad about how the throwaway society of the 21st century has extended even to things that are supposed to last.

We use this technique in our team to distribute passphrases for our secondary secret stores (that contain instructions on how to access our primary secret stores) in a "democratically secure and safe" manner.

https://packages.debian.org/trixie/ssss is a nice and rather straightforward implementation.

I recommend https://johannes.truschnigg.info/writing/2025-02-simple_effe... as an (imo) better approach than fail2ban parsing your logs to deal with the problem.

One of my most esteemed former co-workers used to say that whenever you succeed in making something idiot-proof, the universe will create a better idiot, undoing any progress you made.

Does Windows on ARM use VBS/Virtualization Based Security, and does ARM support nested virtualization to do so in a VM, too? Does it employ costly CPU vulnerability mitigation techniques that might hit two times in a VM (unless the Hypervisor is adequately set up, which I'd hope is the default for Hyper-V)? Those two things account for most of the common performance problems observed when putting modern Windows in a VM. I'd love to know more about it, but the article does not seem to mention either.

I'd say it's either because they're just having fun, or because they're dumb.

Thanks for this (and I actually learned about PS1's handy Unblock-File this very moment! :)), but I am aware of the "mark of the web"-stuff MSFT had introduced after realizing that an "attacker-controlled" filename extension alone is a poor safeguard against making a file executable ;)

For my specific problem/situation, the executable in question gets transferred to the target machine on a read-only UDF file system burnt onto a USB thumb drive. Other Golang executables from FOSS projects on the same filesystem execute just fine (I guess they have better "reputation", due to their hashes being registered with MSFT somewhere).

"works just fine on Windows as it always has" is just not true. These days, I cannot even run my own cross-compiled Go executables of a cross-platform tool that I am developing in private on Windows 10 or 11, because some blue popup from Windows Defender/"SmartScreen" prevents me from doing so, and tells me to contact the software publisher if I'd like to be able to do something about it. Outright disabling Defender/SmartScreen works around the problem (but the popup doesn't tell me that), and, presumably, signing these executables with a "trusted" developer certificate would make this outcome less probable - that is at least what people online have been telling me.

In my book (I started using computers during ther Windows 3.0 era), this clearly does not qualify as "working just fine on Windows as it always has", no matter how you spin it.

As a wireguard user myself (even on the lone Windows machine that I still begrundingly have), I am happy that this problem could have been resolved. I am just wondering - if there had not been this kind of public outcry and outrage that Mr. Donenfeld discounts in his announcement message, would the issue have been fixed by now?

What are individual developers of "lesser" (less important, less visible, less used) software with a Windows presence to do? Wait and pray for Goliath to make the first benevolent move, like all the folks who got locked out forever from their Google accounts on a whim? Ha!

The fact of the matter is, the code signing requirements on Windows are a serious threat to Free and Open Source Software on the platform. Code signing requirements are a threat to FOSS on all platforms that support this technique, and infinitely more so where it's effectively mandatory. I firmly believe that these days, THIS is the preferred angle/vector for Microsoft to kill the software variety their C-levels once publicly bad-mouthed as "cancer", and zx2c4 is one of the poor frogs being slowly boiled alive. Just not this time - yet.

I am already donating the rough equivalent of the cheapest Microsoft 365 subscription to The Document Foundation each year, and won't stop now just because they're increasing the visibility of their donation-based funding model. I hope they succeed, and many more people start contributing financially as a result.

Thanks, but no thanks. The only winning move, long-term, is to excise everything this wretched company makes from your life as vigorously as possible. It's been true 20 years ago, and it's even more true today.

None of the missing ones have proper, official, upstream LineageOS support. If you install LineageOS on these, you install somebody's own, personal fork of LineageOS. Which might be totally fine, of course. But because of the necessarily different signing keys alone, it's a (potentially) very different thing.

A true hero and legend. RIP.

I disagree. If LineageOS builds were actually unsigned, I would have no way of verifying that release N was signed by the same private-key-bearing entity that signed release N-1, which I happen to have installed. It could be construed as the effective difference between a Trust On First Use (TOFU) vs. a Certificate Authority (CA) style ecosystem. I hope you can agree that TOFU is worth MUCH more than having no assurance about (continued) authorship at all.

LineageOS isn't unsigned, it just happens to be signed by keys that are not "trusted" (i.e., allowed - thanks for the correction!) by the phone's bootloaders.

No.

Yeah, they can fuck right off with that kind of shit idea.

Yeah, I can see why that is a show-stopper for people. However, the thingino project has people among them who care deeply about ease of installation - so with these security issues discovered in the TP-Link device, chances are an installation method that relies on a vulnerable stock firmware will be provided in time :)

I came here to post this, too :) What the thingino community managed to do with their firmware for these cameras is nothing short of amazing - if you happen to have a compatible camera, you really, really should give it a whirl!

I realize this is mostly tangential to the article, but a word of warning for those who are about to mess with overcommit for the first time: In my experience, the extreme stance of "always do [thing] with overcommit" is just not defensible, because most (yes, also "server") software is just not written under the assumption that being able to deal with allocation failures in a meaningful way is a necessity. At best, there's an "malloc() or die"-like stanza in the source, and that's that.

You can and maybe even should disable overcommit this way when running postgres on the server (and only a minimum of what you would these days call sidecar processes (monitoring and backup agents, etc.) on the same host/kernel), but once you have a typical zoo of stuff using dynamic languages living there, you WILL blow someone's leg off.

In fact, it is not a problem at all.

Let new generations of Free Software orgs come along and supplant GNU with a GBIR (GNU But In Rust), but don't insist on existing, established things that are perfectly good for who and what they are to change into whatever you prefer at any given moment.

I wrote https://johannes.truschnigg.info/writing/2024-07-impending_g... in response to the CrowdStrike fallout, and was tempted to repost it for the recent CloudFlare whoopsie. It's just too bad that publishing rants won't change the darned status quo! :')

That's one cute lil' fella :)

Yeah that would have been great, but it's not available on our existing core switches (Dell PowerSwitch S5200 series).