

Why don’t they bundle the browser itself in the Flatpak and update it via the default Flatpak update mechanism?
Why don’t they bundle the browser itself in the Flatpak and update it via the default Flatpak update mechanism?
Fabric with some performance-enhancing mods is a great choice as well, yes! I’ve been wanting to test it on my server for a while now, just haven’t got around to it yet.
Paper changes some of the more quirky vanilla redstone behavior, although - again - it’s very configurable so some of that original behavior can be restored.
I’d mostly base it on which plugin/mod ecosystem you prefer/require.
World simulation (ticks) is single-threaded, but things like world generation are multithreaded. I’d recommend Paper as server software as it’s more performant out of the box (vs. vanilla) and configurable (ex. how many threads world generation is allowed to use).
If you host multiple worlds I recommend spinning up a Paper instance for each world separately and connect them with Velocity.
Ryzen 7000 should have better single-threaded performance than your i5-9500 but as it’s a VM ymmv depending on whether Sparked Host overprovisions their machines.
Couple of years, yeah.
They run their own registry at lscr.io
. You can essentially prefix all your existing linuxserver image names with lscr.io/
to pull them from there instead.
I just can’t really resell a disk I’ve drilled through (at the very least it’d lose most of its remaining value). And while I can try to post a sign in front of my door stating that I’d like to physically destroy my disks before they get stolen, I doubt most thieves would respect that.
That’s one of the reasons why I encrypt pretty much all my disks, even those in stationary computers. It protects data from physical theft, but also gives peace of mind when reselling or even when a disk dies in a way that won’t let you overwrite it with zeroes/random data after the fact.
Until it starts breaking, like it did for me upgrading from Fedora 39 to 40 for example.
Or until you try to bind mount a volume of a container and need to use z
or Z
flags.
The “advantage” compared to a simple Linux USB is that it saves the exact state of the VM I guess.
Meh, I’d rather open the applications I need again (or let my DE restore them) than running a VM just for that reason.
Pretty much every Secure Boot device trusts Microsoft by default, which is why I think it’s pretty much useless (in its default state anyway).
Does this happen with the network cable unplugged?
The user still has to login to their user account. The assumption is that the Windows login is secure so BitLocker can decrypt using TPM and an attacker still won’t have access to the data without being able to log in.
This article obviously shows a method how an attacker can potentially still get access to the data without logging in.
A lot of BitLocker setups unlock using just TPM though, which was my point. No password/PIN needs to be entered at boot time to unlock it, it uses the TPM to unlock. This is the default setup that many companies use. Password/PIN unlock is completely optional.
I’m not misreading that.
It doesn’t already have to be running. BitLocker retrieves its keys from TPM by default, so just booting a device will place the keys in memory.
To minimize downtime, abruptly restart the target system during the Windows boot process, specifically before the login screen appears, as this approach has proven effective in scenarios involving the retrieval of Full Volume Encryption Keys (FVEKs).
By kernel-level debugging with WinDbg, the researcher observed BitLocker operations during the Windows boot process, which revealed that while Microsoft attempts to erase encryption keys using functions like SymCryptSessionDestroy, some keys persist on the heap, potentially due to incomplete key destruction mechanisms.
Is this really a BitLocker issue or more an issue inherent in the hardware design?
EDIT: Okay, looks like Microsoft could do better:
By kernel-level debugging with WinDbg, the researcher observed BitLocker operations during the Windows boot process, which revealed that while Microsoft attempts to erase encryption keys using functions like SymCryptSessionDestroy, some keys persist on the heap, potentially due to incomplete key destruction mechanisms.
But maybe the hardware/UEFI should immediately wipe memory upon restarting anyway…?
That’s what I’d suggest as well. Should work.
What does the go.mod
file look like? Go 1.23.4 is relatively new so maybe binaries for your platform aren’t available yet? What does go version
output?
Unsupported platform probably (android/arm64
)?
YouTube is by far the slowest website I visit, it’s so bloated.
The best Windows is Wine ;)