1. It's extraordinarily complex.

The reality is that security is not just technical implementation, but also actually getting people to use the solutions. "Stop disabling SELinux" is not a real answer to when people disable it, like we have one person in this thread.

Another problem with complex security solutions is they are hard to get right. Even if you enable them and configure them, without being an expert, it's possible you left a gap here or there, and holes and gaps in these solutions.*

2. Like so many other complex linux security solutions, it is lacking effectiveness due to still sharing the same kernel.

There is a good, but bit dated writeup here about the problems with Linux security, from an architecturual perspective: https://madaidans-insecurities.github.io/linux.html . But, the short version is that the Linux kernel is large and complex, and has a lot of attack surface. And it's a frequent source of vulnerabilities because attackers can hit it as long as they access to the kernel, even if they are in a container/sandbox. Like, copyfail and dirtyfrag would punch through containers, but also punch through SELinux.

For example, just earlier on lemmy someone dropped a zero day that punches through SELinux: https://programming.dev/post/51103657

Now, SELinux can be used to restrict what a root shell could do after escalating... but that's further complexity you have to learn to configure, and configure it correctly as well.

Ultimately, none of the Linux security solutions come anywhere near the isolation of simply running something in a virtual machine. Which, also happens to be a lot simpler and actually possible to get people to use.

*(putting this at the bottom because it veers off topic) I have a greater argument and problem with mentalities like this. I have noticed a pattern, where many of the more effortfull and toil intensive security solutions are recommended by people who have the time, energy, and skills to execute them. They have a bias/blindspot to the realities, which is that not everyone is in the same situation as them.

For example, updating/patching software. Linux distros like RHEL or Debian, have a policy where they only do security updates, and don't do feature updates or bugfixes. This enables them to ship automatic updates, so that security issues are automatically handled.

On the other hand software like Windows, likes to bundle in breaking changes along with security updates. So automatic updates get disabled because "They might break something". And then, people don't update them, and environments get horrifically out of date, because not enough money/time/people is put into regular IT people who are in charge of maintaining them.

But some environments, have heroes, people who go around patching everything and keeping everything up to date and secure. And when they see these environments that don't have everything patched, they usually give the advice of "You should patch everything" (while simultaneously advising against auto updates), not understanding that these environments are lacking a key ingredient: Themselves.

Sure, I could be a hero. I could "patch" everything manually. I could deploy SELinux. But that would only last until I get burnt out, or leave. Once I'm gone, SELinux, the patches, any similar security solutions are gone. I've met so many people, even in cybersecurity, that are apathetic about security, even though they might have cared once upon a time.

On kubernetes it's pretty much the same amount of work. Every possible storage option exposes a generalized, abstracted "storageclass", from which storage can be provisioned and mounted into containers.

https://kubernetes.io/docs/concepts/storage/storage-classes/

Thank you so much!

Sorry for no transcript :(

I use KDE as my desktop. KDE is installable on any distro, although you probably want a distro with a newer version of it like Fedora or Opensuse. On KDE, these two shortcuts do what you would expect them to do.

Win + V opens up a clipboard manager by default:

I actually like this clipboard manager better than the Windows default clipboard manager, because it lets me search, edit, or star items so they can be found quickly from the "starred only tab". The amount of items kept is also configurable, and it keeps way more items than the Windows clipboard manager.

Windows + Shift + S opens Spectacle (KDE's screenshot utility) by default. It has some basic editing features, but one feature about it I like is there is an option to upload the screenshot directly to imgur for easy sharing.

For RDP, I recommend using Remmina to connect to machines via RDP. It supports shared clipboard, but also shared filesystem and some other nice stuff. You can save connections and their options to easily connect again later.

Remmina is a mature program that is available in the repositories of most Linux distros.

Well, I run a one node cluster...

But yes, I did use ceph via rook-ceph, because Openstack (a locally hosted AWS alternative), at least the Kubernetes version, wanted a ceph "cluster" to store stuff on.

Longhorn is much easier. Although again, my "cluster" was one node. I deployed it because I wanted snapshots.

I like to use more uncommon tools (it often bites me afterward but it’s funnier this way

I know the feeling.

How about this: https://docs.xcp-ng.org/installation/install-xcp-ng/#9-networking

Try setting a static ip address on xcp-ng itself, during the install phase. (this was how devices got onto networks before dhcp). You'll have to make sure it doesn't conflict with anything else on the network.

Kubernetes makes distributed storage easy.

Basically, all the components get deployed for you, since that's part of what kubernetes is good at.

And then, services/containers can provision storage by requesting storage via making a "claim" and whatever distributed storage providee you have gives it to you.

https://sso.tax/

It's unfortunately common, even though it probably shouldn't be.

Proxmox is also making their own: https://www.proxmox.com/en/products/proxmox-datacenter-manager/overview

source code: https://github.com/proxmox/proxmox-datacenter-manager

Two more that I have found:

https://docs.pegaprox.com/

And: https://github.com/xdkaine/uma-proxmox-wrapper-public

~~Multiple options:~~

~~Use flake-utils: https://github.com/numtide/flake-utils#example~~

~~Create a helper function: https://ayats.org/blog/no-flake-utils (what I do)~~

~~flake-parts: https://ayats.org/blog/no-flake-utils#option-a-flake-just-for-yourself , https://github.com/hercules-ci/flake-parts~~

~~But this is one of the things I find annoying af about nix flakes. Reproducibility is a spectrum, and I think focusing on "purity" over being able to easily ship it to multiple architectures, or not being able to use the GPU is a step too far on that spectrum for the vast majority of usecases. I can understand why scientific computing or anything that needs absolute precision might want it, but most people only just want the same versions of packages installed in their development environment.~~

EDIT: whoops forget everything I said, you are asking for cross compiliation of a dev env to Windows. Nix doesn't support Windows. It only supports linux. You can't make a nix dev shell that works on windows.

No. Telegram is not end to end encrypted, by default. Their encryption is only in certain versions of the app. And finally, it's a custom protocol that has never been seriously audited.

Signal doesn't claim they don't share, they claim they can't share the private messages, which is true because it's open source and we can see how the encryption works, and we also know that signa's encryption is always on.

Edit: well, I guess is private messages refers only to "secret" chats encrypted by telegrams end to end encryption, and assuming that their custom encryption isn't backdoored then yes, I guess this claim is true.

But telegram chats are not "secret" by default. It must be explicitly enabled per chat.