It’s an environment variable…
Does this warrant and entire novel about it if you’re working within external source builds? No.
In fact, I think you’d be better off writing a deep dive into what/how environment variables work at build time, and also invoking commands on the CLI.
Try disabling hardware acceleration on whatever browser she’s using, or switch to using a different YT frontend: https://github.com/mendel5/alternative-front-ends?tab=readme-ov-file#youtube
No, it actually hasn’t. It’s also not any better than any other battery tech out there right now. Longer term but less volume storage is a trade off.
What happened to these Graphene batteries and capacitors we were supposed to have by now?
If you’re this familiar with all the moving bits of this, why are you asking?
I’m only saying this because this is obviously someone who read a bunch of stuff about various things that are beyond their technical expertise but have no idea why they would even need such a stack.
Kind of a crazy thing to ask about here.
If you’re running the exact same version, just do an apt update and then see if upgrade packages show up.
You can send entire folders from Android/iOS just fine with a normal file browser.
Downloads for all platforms: https://kdeconnect.kde.org/download.html
KDEConnect is honestly going to be better. It’s runs on everything (yes, Gnome and Cinnamon), has transport and device security, and offers more than just file transfer.
There’s a few things at play here, but the main thing is that whatever Bluetooth daemon is running is likely running in userspace. Switch users, get a different PID and Bluetooth daemon.
It looks like Arch uses Bluez as root by default though, so is it possible you have another BT manager in the mix somewhere?
It depends. The fishing industry and seafood isn’t exactly my are of expertise in this arena, but there’s a reason why fishing boats with freezers are more sought after than just “catch of the day” types. The latter has variances in time to market which may impact the freshnwss and taste, even if only by a difference of a day.
Seems lots of seafood just spoils really fast, which makes sense if you take into account the density of the meat. Things like Tuna or Salmon steaks are dense, and therefore would spoil slower than something like a whitefish or shrimp perhaps.
Two things:
If you buy seafood that you expect was cought that day, versus a day before. They will taste wildly different.
A shrimp caught on Monday will taste sweeter by Thursday in most people’s cases.
If you are high on the Litmus scale though, you may taste more sugars than Alkaloids, making things taste sweeter.
It’s a good lesson to learn if you’re working with Samba frequently. Just always that there are two auth systems at work: SMB local to the server and filesystem, and the SMB protocol auth that does network access.
👍
It’s not just a config thing, you need the local guest user and an smbpasswd entry to match: https://serverfault.com/questions/630631/how-to-make-samba-share-to-not-ask-for-password#632296
If you just want to remotely interact with LUKS to unlock it, I think dropbear-initramfs module is your only option.
Clevis+Tang is essentially the same thing but automatic, and yes it does require a separate machine and network access to that machine.
This post is phrased in an incredibly confusing way that doesn’t make parsing the problem possible.
Please rephrase in steps to illustrate the issue you have, such as:
Clevis with TPM+Tang is the most secure you’re going to get as far as automated unlocking goes.
Dropbear is still a thing, but going to be more problematic.
This is absolutely insane. It’s so top heavy there is no way this will do anything but spectacularly fail, and take the entire economy with it.
I mean…if you just want a text-based working environment, there are plenty, but nothing as a full DE that I’m aware for a number of reasons.
I think VTM is the one that is most like what you posted, but there are also other terminal environments that act similar to eDEX, but I would lump more in the IDE category.
This is a great talk, but it’s ignoring the real issue in that it would need to be “in-line”, which is not anywhere near possible. They sort of address that, but are talking about the cyphers themselves mostly.
I think we’ve reached the cusp where we can exchange new derivative keys on the fly per request without making too much of a dent in speed, but that comes with all kinds of tradeoffs on session length and convenience I suppose.
Edit: I guess there is another eventuality where governments just go and farm public keys and use them against targeted traffic. Not a good way to beat that right now.