The Linux Thread - The Autist's OS of Choice

[Klokateer636]

Just thought I'd also add, you don't even need to create a live Linux disc or even a VM of your own. You can use https://distrotest.net/index.php to pick a flavour of Linux and run it there.

It's a tad slower naturally, but it's still a nice way to test without having to do any extra setup. It's how I decides on using Mint after trying a few other flavours.

 

[WinnieTheJew]

cpupower-gui is what you want. It's available in the standard repositories (sudo apt install cpupower-gui). Depending on your processor, it'll allow you to manually adjust the frequency scaling of each CPU to a certain degree and you can also use preconfigured governor algorithms to dynamically adjust your CPU's frequency and power consumption.

This can actually make some systems hotter if the maximum frequency is set too low, especially in the context of desktop usage where computation is done in short bursts, as opposed to a server that stays under full load more often. If you set all cores to the base frequency they'll spend more time on the same workloads. Ideally the processor should finish a task as fast as possible and then resume idling. Finding the best setting takes a few tries, since it depends on your specific hardware.

 

[Fcret]

Mint is OK but I hate recommending it because it uses Xorg which is its own can of worms and Cinnamon is unstable beyond fuck.

If you want to go Ubuntu just go Ubuntu, KDE (Kubuntu) being the most feature rich DE. Pop is also very nice, but it's still just another Ubuntu derivative.

I don't recommend Wayland as a rule until you know what kind of desktop environment you're going to be using. Everything supports Xorg and like 90% of the applications you run in a Wayland environment will be using Xorg anyway through Wayland's stripped down implementation of it. If you want that, that's fine, but if you're just trying stuff out it's easier to just have Xorg configured by default so you can easily switch between environments.

 

[Mister Uno]

tl;dr systemd-resolvd makes everything more complicated just for the sake of it, which breaks things in subtle and hard-to-debug ways.

The few times I've had to troubleshoot systemd have been a nightmare. The documentation on it is so bad. Meanwile runit ran perfectly fine. Any issues I had or wanted to change was much easier to look up.

 

[XMassAllYearRound]

We hating on systemd? Finally an excuse to use this gif.

 

[Knight of the Rope]

We hating on systemd? Finally an excuse to use this gif.
View attachment 3115449

In the finale of this whole thing we'll all be calling it GNU/Poetterix.

 

[Kosher Dill]

In the finale of this whole thing we'll all be calling it GNU/Poetterix.

Or Poetterix plus GNU as I prefer to call it.

 

[DavidS877]

Some of it may be Ubuntuisms/Debianisms. But both resolved and timesyncd both annoy me by mostly ignoring the perfectly good DNS and NTP servers I provide in DHCP. The DNS does some adblocking as well as providing local resources so resolved's tendency to ignore it is wonderful. Similarly I have a perfectly good NTP server which I have to go reconfigure if I keep timesyncd running. I did finally get tired of it and just added a *.pool.ntp.org alias to my DNS for my local NTP servers which works great once I convince DNS to work right and send everything through my local name server, I added similar aliases for Windows and Apple time servers.

 

[AmpleApricots]

Meanwile runit ran perfectly fine. Any issues I had or wanted to change was much easier to look up.

Runit is basically AUTOEXEC.BAT but with multitasking. There can't be many issues because there's just not that much that can go wrong, and that's how it always should be with the crucial basics of a system. Abominations like systemd always started with the excuse of "We have to solve inter-service dependency else pandemonium!11!1" but in my experience I just let them start in an arbitrary order and don't give a fuck and that literally was never a problem. Pretty much all common services you need are smart enough to know to wait when something isn't available yet and it always felt more like a problem that should be addressed by the services in question or a script wrapper and not the init system anyways. They need to know what they need to run, why should the init system disentangle this? If your software service can't, then find/write a better one.

---
I've been playing around with the small N4020 Celeron "Netbook" I got and it's actually a very useful machine, the CPU is just strong enough for my needs and even heavier browsing works surprisingly well. I found out that if you turn off the second CPU core, it can boost to 2.8 Ghz (from 1.1 Ghz) pretty much indefinitely which in many situations is actually faster than having two slower cores. (although not amazing for the battery, the closer you get to the 2.8 the harsher the curve with power consumption is, obvious silicone limits)

With recent kernels schedutil with intel pstate is recommended for frequency scaling but schedutil seems to be pretty dumb (in this setup at least) if something causes a low level background CPU load (e.g. javascript heavy "web app" website with idiotic loops) it just puts the CPU to the max, burning electricity and causing heat for no reason. (especially when turbo boost is enabled) It in general just seems to know no load = lowest setting and any load = highest setting. Doesn't feel very intelligent to me. Might even be buggy for all I know. Or maybe the developers just got tired of desktop users complaining about latency. From my measurements depending on situation this is easily 1/4 to 1/3 more battery usage than necessary. pstate comes with the ability to just let the CPU select it's frequency itself via HWP feature which in my tests works a lot better and leads to less wastage but is not supposed to be the standard anymore because schedutil is the Shiny New Thing now. Maybe there are knobs to play with, I didn't try, intel's pstate active mode just simply works better. Same with xf86-video-intel which works noticeably better than the generic modesetting driver and has no tearing in X on this system even with TearFree off and no compositing. Why oh why do they keep reinventing the wheel, making it less round each iteration?

Next project up - generous usage of SIGSTOP and SIGCONT to freeze background processes (esp. programs I don't actively look at - I use ratpoison here) to go light on the battery, my goal is 16-18 hours which feels like it should be possible.

 

[Fcret]

systemd sucks but I'd take it in a heartbeart over writing sysv-style initscripts ever again

 

[teriyakiburns]

systemd sucks but I'd take it in a heartbeart over writing sysv-style initscripts ever again

Systemd unit files are far more opaque than a simple bash script and come with immense amounts of baggage, none of which should be handled by the init. If you want to exchange well-defined simplicity for arcane complexity, just to have a superficially easier (but not actually) init file, you might want to rethink what you're actually trying to do with your init script.

 

[Fcret]

well-defined simplicity

You should take a look around /etc/init.d sometime, because that is certainly not the way I would describe init scripts.

 

[Miller]

Avoid all of them if you care about proper Linux support.

How long until people reverse-engineer some drivers based on the recent hacks/leaks?

Learn Bash, frens. It's the patrician's scripting language.

Everytime I see his face I'm reminded of the cult leader from Far Cry 5.

 

[byuu]

How long until people reverse-engineer some drivers based on the recent hacks/leaks?

Using those leaks is a good way to get the whole project taken down.

 

[Fcret]

How long until people reverse-engineer some drivers based on the recent hacks/leaks?

Probably never. There'd be all kinds of risk of contaminating the drivers with patent infringement and fear of that would keep it out of the kernel's source tree for decades.

 

[BootlegPopeye]

I'm going to start the transition to Linux. Never used it before so I thought I'd ask for some advice before I fuck something up spectacularly.

I was thinking of going with Kubuntu, which I hear is a good distro for beginners. Considering I'm not that well versed with the inner workings of a modern computing system, neither do I have the time to spend tinkering with settings and packages for days on end, is that the distro to go with? Or would you guys recommend something else?

Also, I absolutely need Windows for some things, mainly software that doesn't run on Wine. I've been reading warnings about Windows 10 updates fucking up the Linux part of dual boot. Is that a realistic scenario? If yes, is there some way to get around it? Or am I just in a situation where I'm forced to buy another computer for daily computing needs on Linux?

Stick to debian based distros (Debian, Ubuntu and many variants, Mint, PopOS, etc) and ignore anyone who says otherwise. Third party support is best on them and anything more complicated is going to scare off most Linux beginners.

Even though I have used Linux for well over 10 years I still use Mint. Every time I've gone to another distro, I end up going back to Mint.

 

[Dr. Geronimo]

Which NVidia cards are people using that give them these problems? I'm genuinely asking because I may want to upgrade my (NVidia) card in future and I want to know which ones to avoid.

My 1660 works fine. I assume all the tard cards that are popular like the 3070 also do.

I've installed mint on 2 rigs with Nvidia and had issues on both of them. Installing to my old 1060 it would refuse to recognize my 1440p screen until it magically did after like 4 reboots.

On my current rig with a 3070 it installed fine but opening a program would cause whatever video 8 was playing to stutter and drove me fucking crazy.

 

[ditto]

Learn Bash, frens. It's the patrician's scripting language.

Nice ad for Linode. But he doesn't explain a damn thing. Just the usual "type these commands" pajeet level tutorial except with zoomer editing and a cuck beard.

 

[teriyakiburns]

You should take a look around /etc/init.d sometime, because that is certainly not the way I would describe init scripts.

Vastly simpler than hauling in half of userspace, just to make writing an init appear easier.

 

[XMassAllYearRound]

Stick to debian based distros (Debian, Ubuntu and many variants, Mint, PopOS, etc) and ignore anyone who says otherwise. Third party support is best on them and anything more complicated is going to scare off most Linux beginners.

Even though I have used Linux for well over 10 years I still use Mint. Every time I've gone to another distro, I end up going back to Mint.

I want to agree with your post as a debian user but I'm not entirely sure I agree with debian being the one that gets the most support.

On enterprise I've always come accross more platforms running Redhat or CentOS and on the end-user side I don't have the exact number but I believe Arch has support for more packages and programs thanks to the Arch User Repository and Arch Build System (Plus unlike debian they're usually up to date).