>>981557
Ok, I'll take off my shitposting hat for a moment and elevate the discussion back to /tech/ levels. Not only is securing your system an achievable goal, but you can also help the broader community. But it does mean making sacrifices, hard choices, and putting in work. Security and Capability are usually opposed. I also want to point out that my most secure system is one I use the least. It's literally bare-bones and its only job is cryptographic, usually entropy or generating keys.
> The professionals that run the fucking tree can't do it.
They have the hardest job. They have to coordinate all the incoming patches, check for any obvious problems, and then farm out the testing. Rinse. Repeat. They also generally deal with all the bullshit and drama that always comes from any community.
> In requires a team of dozens of people full time.
For largish projects, they might have enough money (or influence) to get dedicated build/test machines. Smaller projects are entirely volunteer driven through mailing lists, IRC, git(hub|lab) issues, and a bunch of others. Ultimately people are taking that hot code, patching their test system, and find regressions or bugs. Any bugs are then sent back to the project coordinator and original patch writer who makes the needed changes. This can go on for a loooong time, but each person is only testing their tiny microcosm.
> There is no human on this planet that can do it.
We call this a system's "Attack Surface" which is a fancy way of saying "here are all the possible open doors a possible bot can walk through." Locking down a system is all about reducing this surface. As such, you start making choices about every program. This means giving up a lot of things if you want a more secure system. DEs are usually the first to go because they are so big, and I can get most of the same functionality from a terminal and a programming language. I can spend weeks without an X session.
Once you make the choice of software and hardware, now you have to do the hard part of reading and understanding the code. This might also mean firing up a VM box or installing on old hardware for interactive testing. This initial read through is the longest part because you have to understand all of the decisions (and flamewars) made before until you are at the HEAD of development. At first you will have a minimal system. A kernel, bootstrapped compiler, maybe a handful of drivers, a shell. That's your base system. http://www.linuxfromscratch.org/ is an excellent way to get started on this path. After that, it's about keeping up with your software's development. In time, you will slowly add more programs.
As you go through this process of testing and understanding, you will be in a position to report any bugs you found and start interacting with the developers. There's honestly never enough testers. All this adds to your credibility in the eyes of the community.
Another component of security is isolation. It doesn't matter how careful I am, software is bound to have bugs and vulnerabilities. That's when you specialize your hardware for it's purpose. This is not new security advice, but it does mean you probably should ditch your "main driver" and opt for a constellation of devices, but that's my opinion talking.
As an aside, not only will you learn a ton from this exercise, you will open your mind to how much your computer can do. You will understand what "bloat" means viscerally and discover how much you *don't* need. You will also understand just how stupid the blackpill'd sound.
I can't make you take control of your own computer, but maybe I can convince you that it's possible.