Ralphred

Come back if you get stuck with firmware for wifi/bluetooth etc.

Similar experience, was able to use an SDcard to "put android" on an ancient WinCE device. Bending embedded stuff to your will is not for the faint of heart though.

Just because I like to drop this info for dual booters: Setting GRUB_DEFAULT=saved and GRUB_SAVEDEFAULT=true in grub.cfg (or ideally /etc/default/grub) means grub will remember which OS you used last boot and treat that as the "default", it means you don't have to hand-hold those "I'm going to reboot 12 times" windows updates.

Just because I like to drop this info for dual booters: Setting GRUB_DEFAULT=saved and GRUB_SAVEDEFAULT=true in grub.cfg (or ideally /etc/default/grub) means grub will remember which OS you used last boot and treat that as the "default", it means you don't have to hand-hold those "I'm going to reboot 12 times" windows updates.

It's ability to mix and match stable with testing (and even git sources) means you can have the best of both worlds. Slotted packages means you can keep multiple version of wine floating around for legacy games you "just don't want to let go". And because you have had absolute control over your OS from the very beginning, making sure that memory usage and CPU overhead aren't wasting bits and cycles not making pretty graphics is really easy.
The only thing people really have a problem with is the steep learning curve.
 
The pro of Gentoo: It does exactly what you tell it to, no more.
The con of Gentoo: It does exactly what you tell it to, no more.

The whole recent "lzma library backdoor" requires systemd to work - anyone who didn't see this coming is either a liar or a fool; I don't care which, because your opinion is obviously garbage, built upon a pile of nonsensical hot s**t. If you can't see how this is the case, then your opinion is obviously garbage, built upon a pile of nonsensical hot s**t, and subsequently worthless to me.
 
The paradigm is "One job, do it well!" not "30 jobs, do them all with the lamentable mediocrity of a public sector worker one month from retirement and a comfy pension, if your up for it...", literally SMFH!

The beauty of a rolling release is you only have to do it once, the trick is to know what you want when you start.
Yeah there is the odd glitch; I updated my kernel* the other day and the battery monitor for my gamepad stopped working because the nomenclature surrounding the file that stored the battery level changed, five minutes later it was working again.
 
*the AMD-pstate driver for CPU scheduling is on another level; my CPU now runs faster and cooler during gaming than ever before, because the powersave policy is so low latency to update I don't need to set it to performance to game anymore.

I've always been wary of systemd for two reasons:
"Do one job and do it well" as a paradigm, has always served me exceptionally well. zeroconf and pulseaudio were a fscking sh**show for years before you were able to bridle them and make them dance to your tune. At one point I got to the stage "Well, you are building for a laptop, systemd is supposed to be quicker for boot and such". Soon after setting the system up I realised that because I "sleep, then hibernate after 60 minutes of sleep" the longest part of the boot process was copying 8Gig of SSD disk into 8Gig of ram, so "boot time" was actually pretty moot.
 
After (genuinely) hours trying to reconcile systemd's self contradictory documentation, I gave up trying to make it do what it was told, and created my first "systemd-network-unf**ker.service". As the build evolved (read: added layers of needed software) I had to write 2 more systemd-[system component]-unf**ker.service files and associated fixing scripts.
Some months later, a systemd update was available, and after applying it, it started "booting fresh" from hibernation status. At this point I gave up and switched to OpenRC - it took less time than trying to reconcile systemd's docs, let alone writing 3 "unf**ker" services.
 
Tl;dr, my conclusion from this exercise in pointless ovine mediocrity: Never again, ever; if your "distro of choice" makes it take longer to write an LACP network config than it does switch from systemd to SysVinit, then you chose wrong, because I know I did when thinking "systemd might actually work!".
 
Thanks for reading my blog,
        T. *nix user of 28 years and counting.

It's ability to mix and match stable with testing (and even git sources) means you can have the best of both worlds. Slotted packages means you can keep multiple version of wine floating around for legacy games you "just don't want to let go". And because you have had absolute control over your OS from the very beginning, making sure that memory usage and CPU overhead aren't wasting bits and cycles not making pretty graphics is really easy.
The only thing people really have a problem with is the steep learning curve.
 
The pro of Gentoo: It does exactly what you tell it to, no more.
The con of Gentoo: It does exactly what you tell it to, no more.

Nothing ever is, just another 'layer of frustration'; just keeping closing the doors if bad actors find them and lock the ones we can predict they'll try to open.
I previously posted "I'm sure smarter people than myself have more practicable solutions though.", I should have included effective in that too.
You are being overly broad with the term "binary blob". In this case we are not talking about the output of an entire package build, which yes would require significant controls to produce the same output, but some binary test files which could be reproduced programmatically in a fairly simple controlled environment.
 
The most important thing is though, if a couple of schmoes in a tech forum can have a productive discussion about ways of thwarting similar attempts moving forward, all hope is not lost 😉

The thing he doesn't even brush on is the convergence of configuration choices and system set-up required for the malicious code to even be exploited, so lets list those here:
An ssh daemon running on an open port of a public IP Said sshd using RSA priv/pub key auth Be using systemd Your systemd is built with lzma support Your openssh has been patched to link sshd to libsystemd You have an infected liblzma On point 1, as discussed above with @igormp, there are two types of people who do this; Those who know what they are inviting and are ready to deal with it, and those who "get what they fscking deserve".
Point 2 is pretty much everyone who's ever read a "how to ssh server" tutorial, and it does it by default*.
Point 3 is probably most people, except those who actively avoid it.
Point 4 is going to be distro/personal choice, but again most are probably built with xz compression support.
On point 5 you need to check if your distro does this, I know none I let near open public IP ports do, and neither does Arch.
Point 6 is almost no one as you'd have to be running "bleeding edge" software, most people who do this (who aren't distro testers) chose distro's that allow them to pick and choose which parts should be bleeding edge and which should be stable, based on need.
 
Don't get me wrong, this is serious and will have repercussions for foss moving forward, but not because "half of all linux servers are infected with malware and are security compromised" because they just aren't and, without further developments in this case, aren't going to be either.
 
*In sshd_config from the openssh git repo.

Agreed, devs don't run "bleeding edge" on the systems they build stable packages on, it's just inviting non-issues to present themselves.
Did Fedora devs build and package on their own "infected systems", I doubt it very much, if I build for other systems I do it on the most mature and stable system available, and all because no one wants a shitty binary or archive.
Not really, the payload was only uploaded 5 weeks ago, so even if it did/does have "other functionality" (like injecting malicious code whilst de/compressing an archive) nothing produced before 23rd Feb has even the remotest chance of being compromised.
 
If you are concerned because you have had sshd running on an open port exposed on a public IP with RSA priv/pub key authentication enabled and use systemd then run ldd $(which sshd). If liblzma isn't in the list you have nothing to worry about.

Agreed, devs don't run "bleeding edge" on the systems they build stable packages on, it's just inviting non-issues to present themselves.
Did Fedora devs build and package on their own "infected systems", I doubt it very much, if I build for other systems I do it on the most mature and stable system available, and all because no one wants a shitty binary or archive.
Not really, the payload was only uploaded 5 weeks ago, so even if it did/does have "other functionality" (like injecting malicious code whilst de/compressing an archive) nothing produced before 23rd Feb has even the remotest chance of being compromised.
 
If you are concerned because you have had sshd running on an open port exposed on a public IP with RSA priv/pub key authentication enabled and use systemd then run ldd $(which sshd). If liblzma isn't in the list you have nothing to worry about.

A quick look at the script and associated doc's leads me to believe you are trying to perform the equivalent of "running nitrous through an engine because I can".
What are the conditions you are creating to force the firmware to behave in such a way that it would "utilise the maximum amount of latitude regarding consumption available"?
Do you monitor any per-core frequency or power data?
You understand that a 10210U is 10th gen and not of the Alder Lake+ "permanent PL2" family?
You understand that pre-Alder Lake CPU's allow the use of the PL2 state (per-core) without reporting it?
Are you able to observe states PL3/4 being reached?
 
The distro (or OS) you use to test this is arbitrary, what's important is the kernel - if you've let someone else configure it then you have nothing to complain about, if you've configured and instructed it yourself (a Linux kernel) and the observed behaviour doesn't match the documentation then you should be filling bug reports with Intel, they wrote the driver after all.

"ondemand" has been kinda deprecated by "schedutil" - it's supposed to be quicker to react or something.

Okay bro first of all what your going for is to not disable the gui but to use a terminal, the “pros” use many types of terminals like alacritty etc. You need to find what works for you and not others thats the whole point of using linux compared to windows. I for one use the default xfce terminal with a bit of shell mods, keybinds appearance etc.(i use manjaro theming on vannila arch). And before you start customizing the terminal you need to learn the linux command line, the fs etc and not be a script kitty otherwise you may break your system have unwanted problems and other bad stuff.

Not really requests, you just seem to be taking a sensible approach with the intention of learning something - your experiences will be able to help others here if well documented.

Ubuntu used to ship (less so today) many different versions depending on which desktop it supported out of the box. The point of the * is not censorship but to glob, so it means {ubuntu, kubuntu, xubuntu, lubuntu} - Games don't care what DE you use, they are more interested in your core libraries and graphics stack.
It's to avoid the "People said to use Ubuntu, but I want KDE/XFCE?" confusion.

Ubuntu used to ship (less so today) many different versions depending on which desktop it supported out of the box. The point of the * is not censorship but to glob, so it means {ubuntu, kubuntu, xubuntu, lubuntu} - Games don't care what DE you use, they are more interested in your core libraries and graphics stack.
It's to avoid the "People said to use Ubuntu, but I want KDE/XFCE?" confusion.

Why? What is the criteria for the difference, redundancy, HA or homework?
If it's the latter, feel free to go fourth and multiple - alone.

It does what I tell it to, nothing more, nothing less.

Aye, a new glibc can totally btfo some older games that "used to just werk".
Running them through steam and proton is great, you can keep "old versions" of proton around with little space cost compared to a game, the "correct version" of libraries etc are kept around in the "steam linux runtime", and games will always work.
 
I know it's not a "philosophically ideal" situation, but more games working must = better user experience so...

Yep, the .iso file has it's own filesystem defined within it, you just have to copy it to a drive (note drive, not partition or extant filesystem).

Start by posting the output of:
xrandr|grep -v "^ ";xrandr --listproviders;export |grep "DRI" and if you have a pastebin your xorg.conf.

Yeah, there is. Sudo has been defanged by by modern distros by using the ALL directive in the /etc/sudoers file.
What should be there in place of ALL is a list of actual commands that a user (or group) are allowed to execute with root privilege.
Now, if you need ssh access then set-up exclusive private/public key authentication, then a user that doesn't have user or group permissions in sudoers, and make sure there are no 'authorized_keys' files for other users. If that user isn't in the wheel group either they won't be able to use su to a: change to a user with sudo rights, b: su to root.
As long as your "admin" user is in the wheel group and able to su to root with a password, sudo is a bit redundant with ALL permissions and you can cut sudo access down by just removing that directive.
Lol, a bootable usb, chroot and passwd fixes that.