Resignation. As you've already pointed out, we're past the point where we could have stopped it. While I continue to try to keep my environmental footprint small, I recognize that the battle is lost.
The event that sealed it for me, was after decades of hearing about how we need to reduce our energy consumption to save our species, someone made an infinite energy pit that financially rewards people for throwing as much energy into the pit as possible. Bitcoin could not have come at a worse time. The modern LLM craze is not helping either but at least that isn't a literal infinite energy pit.
To quote the philosopher Robert Burnham:
> You say the ocean's rising like I give a shit
> You say the whole world's ending, honey, it already did
> You're not gonna slow it, Heaven knows you tried
> Got it? Good, now get inside
That's how I manage all of my virtual machines: building an ISO from a NixOS config and booting it as a virtual machine. I'm going to take some time to see what bits of this I can copy to slim down my ISOs.
One additional benefit: I build all my software from source (by disabling the nix cache) so stripping out these extra programs will not only slim down my ISOs but it will also reduce the build time.
Curious bout your use case for building all software from source, is it because you're worried about the supply chain since nixpkgs builds don't have reproducibility guarantee?
Not at all. At this point, I don't see improvement in the future; I'm just hoping I'll be able to maintain my standard of living. We are hurtling towards an economic collapse, an unemployment crisis, and the risk of major war. I thought I was safely beyond conscription age, but the war in Ukraine has shown that when push comes to shove the max conscription age is mutable.
> I'm just hoping I'll be able to maintain my standard of living.
I used to expect that I wouldn't experience homeless retirement.
But with the shift toward a 4-income economy (and the shift among the powerful, from social good to austerity), it is increasingly unclear how my geriatric self will stay housed.
If you want to really save energy, then they've already made the ideal product: caffeine pills. It's all the wonderful drugs without any of the bullshit. You can have it at any temperature, with any drink or even without a drink at all. It doesn't get cold or give you coffee breath. They're ultra compact and don't require rituals or specialty restaurants. They're also incredibly cheap.
As much as I hate to say it, the Qubes OS people were right. The solution is aggressively isolating apps into virtual machines. Anyone know how much my battery life is going to suffer if I bite the bullet and switch?
> The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing
Simply reviewing the PKGBUILD is not enough for the same reason reviewing a Makefile is not enough: You need to review the source code for _everything_ that is being downloaded and executed on your machine. For AUR packages, that means not just the PKGBUILD but the full source code for the program it is building and the full source code for any of its dependencies.
Hypothetical example: you wouldn't have caught the xzutils exploit by reading the PKGBUILD.
No it wasn't? It ran npm install from post install script in another file. If they named it better people probably wouldn't have even noticed so quickly.
True, but looking at a compromised PKGBUILD[0], it looks like it is installing "atomic-lockfile" and "figures". I think 99% of people reading the PKGBUILD would assume those are legit dependencies needed by the program. It's not like it was running "npm install 1337hax0r". Which is why you need to read the source for both "atomic-lockfile" and "figures" (and literally everything else).
in /tmp?! in post_install()??! With a new random contributor email????
Archlinux is focused on enabling a specific type of user, and certainly ones that can read bash scripts, and understand reasonable depedencies vs unreasonable ones. And even then - this is specifically in the AUR and not a package the distro directly offers.
Programs often invoke other programs through the exec* family of syscalls. For example, git is written in C but it ships with perl dependencies. It is not unreasonable to assume pass-cli added a runtime dependency on a program written in javascript. Regardless, we're talking hundreds of AUR packages have been compromised, I'd be shocked if none of them were javascript-based programs. Perhaps pass-cli was simply a bad example for me to choose.
> It changes the contributor email?
I think this is the 2nd most sus change, but even so, I have changed email addresses over the years so it isn't completely unreasonable.
I'm not sure if you're trying to strawman or are inexperienced.
No, this in no way or shape looks like installing a legitimate dependency to the target audience (expert users). This is a package manager, you don't install dependencies via post_install.
Probably didn't even bother to diagnose the issue. It's hard to tell if it was even wayland related without logs and some digging. But lets just blindly blame wayland cause new thing bad!
Log in using wayland -> no desktop. Log in using x11 -> desktop. Clearly it's "wayland related" even if whatever root cause it is is something you wouldn't consider directly attributable to it. Logging into a graphical session is something that has just worked out of the box each other install on whatever random hardware I've used for many years. How is that classified as some nitpicky "new thing bad" complaint?
Well, it's like new car doesn't start but you have forgotten to put fuel into it, and now blame the car.
This is Linux desktop, like if you have never had a black screen before then I'm not sure what you expect. One culprit could actually be the home .config/.cache folders that have all kind of sh*t accumulated (like why do we still do it this way? It's horrible), so I usually rename them and try again to see if this is the problem behind the scenes.
Well, if I never had to put fuel into my old car then this would be a step back, no? I'm not a stranger to troubleshooting, and do a lot of it already, which occupies my energy and time for troubleshooting. I use Debian stable for a reason. It's mostly that if I didn't go looking for a new thing, it doesn't provide anything new that I want, it removes old things that I want, and it doesn't work without troubleshooting, why do I want this thing?
This specifically isn't the biggest issue for me right now because I use this machine mainly over ssh, but if I eventually can't do x-forwarding, RDP, or log in manually without finding some fix, that's a lot of extra work and lost functionality.
I've seen claims that the wifi 6E spec mandated that 6ghz networks required WPA3, so you would need to have a separate WPA2 ssid for legacy devices which therefore couldn't include 6ghz. A lot of access points now support a single SSID with all 3 bands using both WPA2 and WPA3, but I don't know if that is due to a change in the spec or if access points are violating the spec by offering that.
Can’t one SSID support different WPA versions across APs? I’m pretty sure all my devices just shrugged and connected when I downgraded my (single AP) SSID from WPA3/2 to 2 only and back up to 3/2.
Which is a bit sad, but also seems like it would allow this use case perfectly (assuming this was done on purpose and not just an oversight).
> Can’t one SSID support different WPA versions across APs?
I think so, yes. My OG Nintendo Switch connects to the PSK SSID on my two OpenWRT Ones that's using what OpenWRT calls 'sae-mixed' encryption mode. My PCs (using ath9k and rtw88_8822be drivers) and my Pixel 5a connect just fine to my EAP SSID that's using the 'wpa3-mixed' encryption mode.
wpa_supplicant says that the PSK SSID has "SAE" in two out of three of its supported operating modes, and the EAP one has "EAP-SHA256-CCMP-preauth" in one of the two. [0] I assume that means that they support WPA3 operation, but I don't know for certain. I'm somewhat ignorant about WPA3, and am profoundly ignorant about WPA3-EAP.
[0] I'm assuming that the "/"-separated list that comes after the "WPA2-" bit in wpa_supplicant's scan results is a list of what I'm calling supported operating modes.
> iPhones, iPads and MacBooks would not switch to another AP
About a decode ago when debugging networking issues in an office, we had the observation that Apple hardware holds onto access points for dear life. Everything else would roam fine, but Apple would stay connected to distant access points with awful signal as if Steve Jobs' life depended on it.
That behavior has changed a lot in the past decade. Apple actually documents their roaming thresholds.
The signal has to drop below -70dbm for ios and -75 dbm for macos for the devices to consider roaming. Additionally, the difference between the two AP has to be 8db for ios and 12 db for macos.
IMHO, these are good defaults. Apple devices are optimizing for stability over the “best” possible signal.
What you might consider awful signal difference between the two APs might not be. (e.g. a mac device at -75dbm need to find another AP with -63dbm or better.)
Wouldn't excluding apartments therefore exclude Ken Griffin's 238 million dollar penthouse? That seems like exactly the kind of 2nd home that this should be targeting.
Yeah I hear you but I want to incentivize dense housing like that. If you live in Texas or Florida, it’s easy to see how second homes can entirely overtake acres and acres of land.
The event that sealed it for me, was after decades of hearing about how we need to reduce our energy consumption to save our species, someone made an infinite energy pit that financially rewards people for throwing as much energy into the pit as possible. Bitcoin could not have come at a worse time. The modern LLM craze is not helping either but at least that isn't a literal infinite energy pit.
To quote the philosopher Robert Burnham:
reply