The Linux Thread - The Autist's OS of Choice

Anyone happen to know what the current state of analog video capture/digitization on Linux is?

Everyone who does it for a living seems to be oldheads who keep ancient Windows 7 or even XP systems around, and are still in the mindset that capturing video requires intense ricing, Virtualdub is the only viable capture program, and Windows is the only viable video-capture OS. But that all sounds like "magic beans" to me in Current Year. It seems to me that in theory ffmpeg should work fine assuming your capture device has some minimal level of driver support.
Ripping your old VCR tapes?

Jason Scott of Textfiles.com fame has been doing a bunch of rips of... old anime fansubs and shit like that. He's talked about it on his podcast, and to some extent on Twitter. I'm pretty sure his process involves VirtualDub (might be with Windows 10, judging by the screenshots), and some relatively high end JVC VCRs. Not sure about the capture hardware or codecs. He seems pretty anal about getting quality, so it's probably still a pretty good way to go.
 
I've used Ubuntu, Redhat, Fedora, LFS, Gentoo, Mint, Debian, Mandrake, open SUSE, OpenWRT and Slackware.
I've always pretty much been a Slackware user, however, and was ultimately unhappy with any of the other Linux distro's I've tried.

Linux From Scratch (LFS) = too much work
Gentoo = too much work
Debian = gets in my way
Mint = gets in my way
Mandrake = too buggy
Open SUSE = gets in my way
Redhat = gets in my way
Fedora = gets in my way
Arch (never used) = too autistic

Slackware has what I consider the best Linux distro maintainer out there, stays out of my way, is rock stable, and very simple to use.

OpenWRT is a great distro for embedded systems and I use it on my routers.

Other thoughts: if OpenBSD had better hardware support I'd probably switch to that -- super simple easy to use design and very stable.

I don't like SystemD I tried it on all the distro's that include it now, since every once in a while I retry them. I've tried every distro in that list from the time they first came out (with the exceptions of Debian and Slackware which I tried a little after they first came out) and retried them (the then current versions) every once in a while over the years.
 
Last edited:
I'm pretty sure his process involves VirtualDub (might be with Windows 10, judging by the screenshots), and some relatively high end JVC VCRs. (...) it's probably still a pretty good way to go.
Not for long, because Windows 10 versions 2004 and later wreck video capture because of bugs Microsoft refuses to fix.
As an LTSC 2019 dead-ender that's fine for now, but I do want to look into alternatives.
 
Any fellow Ubuntu users ever have an issue where your computer completely freezes but you can still move the mouse? Even the keyboard didn't work and I had to reboot twice.
I don't use ubuntu but this sounds like a certified gnome hood classic. Try and see if you can open a terminal with ctrl alt + f1 (I think it may be only alt + f2 or f3 in wayland) and type in "gnome-shell --replace". There may be other workarounds for this (Killing and starting the desktop comes to mind for instance) but If the keyboard truly gives up on you then you'll have to map a command to your mouse, for this I normally use xdotool but I'm not entirely sure if it will work on wayland.
Not to be a snob, but is there any reason why you aren't using Arch Linux for your personal machines?
I don't use arch (Or more precisely Artix, as I no longer use distros with systemd as my daily driver in general) because I absolutely hate having to troubleshoot it, and unlike other distros I can 100% blame this on the community of unhelpful, narrow-minded, opinionated, "go to the wiki" assholes that make the majority of the user base.

I was a mint user for the longest time and even though that community is full of people trying to needlessly fix everything using gui tools rather than the terminal at least the answers that they provide are helpful enough to the point where I can deduce where the problem is originating from and get the system up and running again in 10 minutes. In arch though? I need to open the wiki and read several manuals to troubleshoot it by myself for a couple of hours because I already know the community is made up of unhelpful cunts that will tell me to go do that anyways.
 
I don't use ubuntu but this sounds like a certified gnome hood classic. Try and see if you can open a terminal with ctrl alt + f1 (I think it may be only alt + f2 or f3 in wayland) and type in "gnome-shell --replace". There may be other workarounds for this (Killing and starting the desktop comes to mind for instance) but If the keyboard truly gives up on you then you'll have to map a command to your mouse, for this I normally use xdotool but I'm not entirely sure if it will work on wayland.

I don't use arch (Or more precisely Artix, as I no longer use distros with systemd as my daily driver in general) because I absolutely hate having to troubleshoot it, and unlike other distros I can 100% blame this on the community of unhelpful, narrow-minded, opinionated, "go to the wiki" assholes that make the majority of the user base.

I was a mint user for the longest time and even though that community is full of people trying to needlessly fix everything using gui tools rather than the terminal at least the answers that they provide are helpful enough to the point where I can deduce where the problem is originating from and get the system up and running again in 10 minutes. In arch though? I need to open the wiki and read several manuals to troubleshoot it by myself for a couple of hours because I already know the community is made up of unhelpful cunts that will tell me to go do that anyways.
I'm actually using KDE Plasma
 
I've used Ubuntu, Redhat, Fedora, LFS, Gentoo, Mint, Debian, Mandrake, open SUSE, OpenWRT and Slackware.
I've always pretty much been a Slackware user, however, and was ultimately unhappy with any of the other Linux distro's I've tried.

Linux From Scratch (LFS) = too much work
Gentoo = too much work
Debian = gets in my way
Mint = gets in my way
Mandrake = too buggy
Open SUSE = gets in my way
Redhat = gets in my way
Fedora = gets in my way
Arch (never used) = too autistic

Slackware has what I consider the best Linux distro maintainer out there, stays out of my way, is rock stable, and very simple to use.

OpenWRT is a great distro for embedded systems and I use it on my routers.

Other thoughts: if OpenBSD had better hardware support I'd probably switch to that -- super simple easy to use design and very stable.

I don't like SystemD I tried it on all the distro's that include it now, since every once in a while I retry them. I've tried every distro in that list from the time they first came out (with the exceptions of Debian and Slackware which I tried a little after they first came out) and retried them (the then current versions) every once in a while over the years.
Arch is incredibly easy to maintain once you have it set the way you like, but that does take some time to get it to that state. I feel about FreeBSD the way you feel about OpenBSD, the hardware support is annoying. It tends to work well on much older hardware.

My history with Linux is similar to yours, started with RedHat back in the late 90's, then Mandrake, Slackware, Debian... just pretty much every distro I found I would try. LFS led me to Sorcerer, which put me on the source based distro detour, ending with Gentoo for many years. Used SuSE 8 for a bit, but never OpenSuSE. Switched to Arch as the performance matched Gentoo without all of the compiling. I still use Gentoo, but not for laptops or normal desktops. I use Kali for pentests as it's just working beautifully out of the box with very little fuss.

SystemD is Redhat shovelware, I prefer OpenRC but have become accustomed to using SystemD. I will say that nmtui is one of the nicer fetaures of SystemD.
 
  • Thunk-Provoking
Reactions: khronosschoty
Not to be a snob, but is there any reason why you aren't using Arch Linux for your personal machines?

I'd rather deploy Alpine Linux instead of Arch, because from what I read no amounts of install script improvements equal to a less difficult and in-the-way maintenance experience. From what I've tried with Alpine, if I gaffed the install, I'd just start over and use its own script as-is with none of the more autistic tweaks added. Works fine.

It's primarily a server (Docker, Kubernetes, etc.) distribution but it has a solid enough GUI foundation for work machines. With Arch you will likely have to spend more time finding very specific tweaks that many of its devotees won't help narrow down. Sure the systemd situation rears itself with non-systemd distributions, but not enough to cause outright workflow disruption.
 
The IBM branded ThinkPads are the nicest laptops. Even being discontinued they are still better than any of the modern brands with how well they are made. I get IBM gets off on spinning off business to keep their company lean thus we now have CCP apparatus Lenovo but I genuinely miss those computers and wish they would come back.

They were sturdy, had great keyboards, good thermals, notable long battery lives at the time, a reliable keyboard touch-ball, had very slick looks, and were attractively priced.

The only reason I use a Mac for a mobile computer is they are closest thing in quality.
Mac's are fragile, limited use machines, with crappy keyboards, and notable bad thermals.... in short, with the exception of the exceptional (some times not so exceptional) long lasting batteries, macs are the exact opposite of everything those old thinkpads by IBM were.
 
Last edited:
I now finished my setup with a very basic but functional KISS linux install and everything more complicated shoved into root directories of various distros and ran sandboxed. No dockers, no flatpacks, just bwrap, sh scripts and onboard tools. If I wanna get rid of one of these containers, rm -r. bwrap doesn't even need suid, just user namespaces. I think that's the only way at this point. The downside is mostly HDD space and redundancy but we're talking here about a few GB extra at the very most, it really doesn't matter. Gentoo has become such a headache to maintain with these complicated softwares if you really wanted to keep control of what you actually had installed, and then there was a permanent fight with the distro maintainers I just couldn't be bothered anymore.

I like to keep on the most recent stable mainline, because that's where the driver improvments are. 5.17 recently introduced a bug where some Dell laptops wouldn't wake up anymore once put to sleep and you basically had to either disconnect the battery or had to wait until they ran out in sleep mode. Admittedly a pretty serious bug, if you are affected but by no means universal to the x86 experience of 5.17 and it also was fixed fairly quickly. What was the gentoo jannies solution? Mask all kernels starting from 5.4 for way too long - 5.4 doesn't even support my hardware properly. Of course I could easily revert that and was already past the official gentoo recommendation with 5.17 but shit like that is why I lost trust in them and second-guessed every newly pulled in package and changed use flag and generally enjoyed gentoo less.
Sounds very similar to what Fedora Silverblue is doing, except they very much rely on flatpaks and a sandboxed VM of a regular Fedora system. One thing that they also do, from what I've read, is mount the root itself as read-only so you get an immutable and, theoretically, safer system. I'm starting to see a lot of posts discussing similar Linux setups, which I take as a signal that this is the next big thing on the horizon.

The problem is, flatpak is still stuck in a Wayland state of eternal beta testing and shit not being completely ready, which is likely going to continue for years to come. Running everything else in KVM containers has to incur some performance overhead and there's no graphics acceleration. Those are my only gripes with doing that.
 
The problem is, flatpak is still stuck in a Wayland state of eternal beta testing and shit not being completely ready, which is likely going to continue for years to come. Running everything else in KVM containers has to incur some performance overhead and there's no graphics acceleration. Those are my only gripes with doing that.
I looked at both flatpak and docker for this but they felt way too complicated for what I was trying to do. (they might make more sense if you maintain a few hundred systems, I don't know) I also looked at some at the universal package manager solutions but all I checked out sounded like a cure worse than the illness. I also don't want to be dependant on the decisions of other people how my computer is ran so isolating of some things just became a necessity too from that angle. bwrap, which is essentially something developed for flatpak but basically relying on the linux kernel for function, lets you basically whitelist system paths. So can whitelist the /sys/ and /dev/ paths to your graphics card to get hardware acceleration in e.g. firefox, but keep $HOME/documents and the /dev/ device of your webcam out of scope of the program. If you play an offline video game then, you can isolate it only to the game files and give it it's own network namespace so that it can't talk to the outside world. (or servers on your computer) It's a powerful isolation feature I used before bwrap, but bwrap makes it a lot simpler.

I am sure there are more safe solutions, but this is "good enough" for me. I want to combine it with mandatory access control but the common systems feel too complicated to maintain myself, and I want to configure everything myself and not rely on outside people there. That said, Tomoyo is interesting and I've used it before, I'm just not quite sure what the state of it in the kernel is currently. I want to avoid the performance impact and additional complexity of a VM.
 
Sounds very similar to what Fedora Silverblue is doing, except they very much rely on flatpaks and a sandboxed VM of a regular Fedora system. One thing that they also do, from what I've read, is mount the root itself as read-only so you get an immutable and, theoretically, safer system. I'm starting to see a lot of posts discussing similar Linux setups, which I take as a signal that this is the next big thing on the horizon.
There's Ubuntu Core as well, which uses the same idea.

People forget that one of Canonical's major revenue earners is commercial/industrial kiosks, like the kind you see in airports. It's the perfect use case for something like this since you're able to lock them down entirely.

e: Also keep in mind Snaps are immutable too. You can basically have a system where the only place a user can write is a partition mounted with noexec (for the snap's log files and such), which is going to make rooting the damn thing pretty hard.
 
Last edited:
Based Gentoo Black Man teaches us how to customize a kernel.


He recently did a pretty cool Gentoo installation video, that goes along with it.


I'll be honest, the last time I even messed around with a kernel was a long, long time ago, back when I had a K6-2 450Mhz. At the time, it made a lot of sense to trim down some fat to get it running faster. These days, not so much, but I am all for "hot rodding" your OS as much as you can.

Insightful comment I've found on his Gentoo install video:

1651969348734.png
 
Last edited:
The trick to not choke your system to death is the -l or --max-load parameter in makeopts which limits the amount of jobs in one compile job based on the specified load average. Otherwise it's highly situational how well compile jobs can be parallelized and there's no straightforward one size fits all value. I honestly rarely to never bothered. After setup, that kind of stuff happens in the background with low priority anyways. If you really want to give gentoo's updates a nice speed bump, put /var/tmp/portage into a tmpfs. Beware of packages that are too big for your RAM though and let them compile on the HDD via package.env.
 
The trick to not choke your system to death is the -l or --max-load parameter in makeopts which limits the amount of jobs in one compile job based on the specified load average. Otherwise it's highly situational how well compile jobs can be parallelized and there's no straightforward one size fits all value. I honestly rarely to never bothered. After setup, that kind of stuff happens in the background with low priority anyways. If you really want to give gentoo's updates a nice speed bump, put /var/tmp/portage into a tmpfs. Beware of packages that are too big for your RAM though and let them compile on the HDD via package.env.
I always just gave the -j flag the number of threads on the CPU +1. Now, with something like a 32 core Threadripper I'm not sure if j=65 would even show a benefit.
 
Back