5. Remote didn’t work as well for the company.
6. Remote didn’t work as well for any number of people at that company.

3. Tradition.
4. Belief that work-from-home is less efficient.

There was this recent attack to XZ utils, which shows that more attention is needed on the code being merged and compiled.

XZ was made possible largely because there was unaudited binary data. One part as test data in the repo, and the other part within the pre-built releases. Bootstrapping everything from source would have required that these binaries had an auditable source, thus allowing public eyes to review the code and likely stopping the attack. Granted, reproducibility almost certainly would have too, unless the malware wasn’t directly present in the code.

Pulled from here:

Every unauditable binary also leaves us vulnerable to compiler backdoors as described by Ken Thompson in the 1984 paper Reflections on Trusting Trust and beautifully explained by Carl Dong in his Bitcoin Build System Security talk.

It is therefore equally important that we continue towards our final goal: A Full Source bootstrap; removing all unauditable binary seeds.

Sure you might have the code that was input into GCC to create the binary, and sure the code can be absolutely safe, and you can even compile it yourself to see that you arrive at the same bit-for-bit binary as the official release binary. But was GCC safe? Did some other compilation dependency infect the compiled binary? Bootstrapping from an auditable seed can answer this question.

The solution is to have stronger privacy laws.

Many people have the power to make certain privacy attacks impossible right now. I consider making that change better for those people than adding a law which can’t stop the behavior, but just adds a negative incentive.

I wouldn’t wait around for the law to prosecute MITM attacks, I would use end to end encryption.

Choosing an esoteric system for yourself is a good way for a free people to protect their privacy, but it won’t scale.

If this is referencing using a barely-used system as a privacy or security protection, then I would regard that as bad protection.

Everyone using GrapheneOS would be a net security upgrade. All the protections in place wouldn’t just fade away now that Facebook wants to spy on that OS. They’re still in place; Facebook’s job is still harder than it otherwise would be.

There’s some time limit before having to re input it.

Inputting a password multiple times into sudo has downsides too. Larger window for attackers to do something like: add a directory to your path, which has a fake sudo in it, and capture your password.

If by “unused” you mean not actively storing data, then the Linux kernel docs disagree.

vm.min_free_kbytes

Same could’ve once been said about a free OS like Linux. Now it is absolutely possible, with the downsides shrinking bit by bit.

The goal of 100% free is one I support. And these people are working to make it possible.

(DBus-based?)

Yeah. iwd even has this issue where it needs you to run a system dbus (presumably so regular users can configure network and the admin can apply dbus polices) even if you do everything as root. No dbus, no function.

Not good.

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.

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.

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.

You can modify the keybinds in software too. You would need to change your console keymap (TTY) and your desktop environment keybindings. Programmable keyboard is most likely easier though.

I played around with it and changed both to just use F1 = tty1 and so on, without requiring CTRL+ALT.

Your needs must be different than mine.

I press one button combination and have root without ever entering a password. I press a similar combination and go back. Not sure how this is a pain in the ass.

All I do is have agetty --autologin root tty2 linux run as a service. It launches on startup, and I just hit CTRL + ALT + F2 if I ever need a root shell.

All its doing is just auto logging-in as root on TTY2.

From what I’ve read, no. Though it doesn’t solve the fundamental problem of a root process handling untrusted input from a regular user.

The TTY method is IMO better as it ties privileges to a piece of physical hardware, bypassing the complexities of userspace elevation of privileges.

The nosuid mount option disables this behavior per mount. Just be sure you don’t use suid binaries.

Example: sudo or doas. I replaced those with switching to a tty with an already open root account on startup. Generally faster and (for me) more secure (you need physical access to get to the tty).

We’re using the definition differently. There is nothing left to discuss.

Miranda is required by law

Irrelevant to the point. I was pointing out the value proposition. Certain things exist for a minority of people. I view the 'reason why" as valuable, even if only a minority care about it.