unhrpetby

Simple solution is to use cryptsetup to encrypt it, forget the key, and optionally overwrite the first megabyte or so of the disk (where the LUKS header is).

If such a project were to become compromised (the way XZ-Utils was), it would eventually spread to Ventoy.

What a lot of people don't know is that the XZ attack entirely relied on binary blobs: Partially in the repo as binary test files, and partially in only the github release (binary).

If someone actually built it from source, they weren't vulnerable. So contrary to some, it wasn't a vulnerability that was in plain view that somehow passed volunteer review.

This is why allowing binary data in open-source repos should be heavily frowned upon.

It's like a silly clown language that can't make K sounds.

K is a part of the Russian alphabet.

It's not about features...it's about ease of use.

Its absolutely about both features and ease of use. If your program doesn't do what people want from it, then good luck.

Its also irrelevant to talk about considering I have used IRC and highly doubt that people are going to consider it easier to use than discord.

For instance, Discord shouldn't be a thing since IRC exists, but Discord exists and is very successful.

IRC lacks a massive amount of features that discord users typically want. Screensharing, VCs with group and camera support, built-in history (don't need to use a bouncer like on IRC), built-in online GIF searcher and sender with one click, huge community of bots that use discord's API to do anything from games to moderation.

It isn't even close.

Really Linux distros just didn’t work with it right out of the box...

From what I've read, this is misleading. Default secureboot within Windows will only boot a bootloader signed with Microsoft's key. Although Microsoft does seem to provide a signing service for signing with their keys, this is at their mercy. Windows made a change that broke booting alternative operating systems unless they use a service that Windows provides to fix it, or disable secureboot.

The “I hate change.” Mindset.

Or maybe it's extra complexity that often leads to the first recommendation to fixing Linux not booting being "disable secureboot" and how this is an extra hurdle to jump through for new users. As well as increased likelihood of problems, due to secureboot.

Until we end tipping culture, tip your servers.

If everyone continues to tip by default, then I believe this will delay or prevent an end to the culture. If servers don't have an issue with tipping (because everyone does so), then there is less reason to support change.

If one person doesn't tip:

You're just an asshole.

If a large majority doesn't tip:

Maybe there is a problem with tipping by default?

All religions are just lies and fiction...

Religions as we know them lack any evidence for the supernatural bits. But this doesn't mean one can safely say there is no possibility of any religion being correct.

It falls into Not Even Wrong. Nothing more than a what-if question. There is nothing to discuss until evidence is brought to the table.

Sounds like flatpaks/appimages with extra steps.

I'm fairly sure the complexity of flatpak/appimage solutions are far more than the static linking of a binary (at least on non-glibc systems). Its often a single flag (Ex: -static) that builds the DLLs into the binary, not a whole container and namespace.

The question should by why you'd want to.

Because the application working is more important than the downsides in my case. Its quite useful for an application which hasn't been updated in a long time, will never receive updates again, or doesn't work in my nonstandard environment.

I have had older applications fail to function due to DLL hell.