deleted by creator

You can check to see what drivers were compiled as modules or into your kernel by reading the kernel configuration at /proc/config.gz or /boot/*config*

There might also be out-of-tree (not included with the kernel) drivers installed as packages on your system but this is very rare outside of like… having an NVIDIA card and running the closed-source vendor driver

The vast majority of drivers are included with the Linux kernel now (in tree) so the difference usually comes down to kernel version (newer kernels have more drivers, of course) or kernel configuration set at compile-time (this can be anything from including or not including drivers, to turning driver features on and off, or more fundamental changes beyond drivers)

You can get kernel version info from uname -a and a lot of the time, probably most of the time (this is also down to configuration), you can get kernel configuration info from /proc/config.gz (use gzip -d to decompress) or something like /boot/config

Then you can run diff on configurations of 2 different distro kernels you’re interested in to see how the 2 distribution’s kernels were set up differently

This could also be caused by different setups of userspace tools or UI that interact with these drivers in different, sometimes worse ways but this is usually much less likely in my experience (most Linux distros do things like this the same way these days tbh)

Oh, also, there are a lot of drivers that require vendor-supplied firmware or binary blobs to function and most of the time distros don’t bake these into the kernel (although it is possible) and different distros might have more or less of these blobs available or installed by default or they might be packaged differently. The kernel should print an error message if it can’t find blobs it needs though

I guess there’s kinda a lot to consider lol. Sorry if all of this is obvious

What hardware are you talking about specifically?

Ohh that’s true, I didn’t think about that. It would be difficult to route anything through it unless you were connected directly to it with nothing in-between because no other router would forward packets destined for somewhere else to my machine (except maybe in the extremely unlikely case of source routing?). It seems obvious now lol, thank you!

I’ll write some firewall rules just in case

I see. Our motherboards have different chipsets (I have an X570 in mine). It probably has nothing to do with my issue…

Hoping those kernel parameters fix it. I wish I could help further. PCs are just a bottomless, mostly undocumented rabbithole :(

What motherboard do you have? Also what happens exactly when the lock-ups happen? Have you ever been playing audio when the lock-ups happen and does it loop or stop or keep playing?

I recently had to “fix” (workaround) a similar issue in the OpenBSD kernel with a specific hardware peripheral on my PC (running a 2nd-gen Ryzen), the High Definition Audio controller. For whatever reason (and only when I was running OpenBSD) interrupts from the HDA controller (to let the CPU know to refill audio buffers) would just randomly stop making it to the CPU and audio would loop for a few seconds and then shut off. I spent a long time trying to figure out what causes it and reading Linux driver code but I couldn’t find a cause or why only OpenBSD would trigger it. I ended up having to write kind of a hacky polling mode into the HDA driver. My only guess is some of these AMD-chipset-having motherboards have faulty interrupt controllers.

Maybe there is a similar issue with your system and timer interrupts aren’t making it to your CPU or something. But I’m not really an expert on PC architecture and idek if it even works like that on PCs lol

Sorry for so many questions but do you also have any kernel logs available from when this happens?

I simply do both

It’s not working

There are some purpose-built ARM Linux laptops available but as an owner of an unused Pinebook Pro… can’t recommend

Walking the path of a PC hater is not easy

Rip out the fan and connect the processor heatsink to a heatpipe

Then carry around a cup of water to dip the heatpipe into

This is not a bit, I am a real hardware designer

Xorg? Wayland? You have bespoke protocols just for windowed graphics? I’m happy with my /dev/draw and /dev/wsys/*

Unix is a zombie OS that should probably die

deleted by creator

Yeahh, you have a good point lol. Bash and the GNU ecosystem have developed their own sprawling problems.

True, but a man page is a different thing from a tool’s built-in usage information.

Running grep without parameters is also pretty fucking useless.

The difference is grep is a simple tool that can take in text, transform it, and output it to a console. It operates in a powerful and easy to understand way by default (take in text and print lines in the text containing the search parameters). This vmalert tool is just an interface to another, even more complicated piece of software.

Claims to have a Unix background, doesn’t RTFM.

Since when do Unix tools output 3,000 word long usage info? Even GNU tools don’t even come close…

Translation: Author does not understand APIs.

The point is that these abstractions do not mesh with the rest of the system. HTTP and REST are very strange ways to accomplish IPC or networked communication on Unix when someone would normally accomplish the same thing with signals, POSIX IPC, a simpler protocol over TCP with BSD sockets, or any other thing already in the base system. It does make sense to develop things this way, though, if you’re a corpo web company trying to manage ad-hoc grids of Linux systems for your own profit rather than trying to further the development of the base system.

Ok. Now give me high availability

I would hope the filesystems you use are “high availability” lol

atomic writes to sets of keys

You’re right, that would be nice. Someone should put together a Plan 9 fileserver that can do that or something.

caching, access control

Plan 9 is capable of handling distributed access controls and caching (even of remote fileservers!). There’s probably some Linux filesystems that can do that too.

In the end, it’s not so much about specific tools that can accomplish this but that there are alternatives to the dominant way of doing things and that the humble file metaphor can still represent these concepts in a simpler and more robust way.

This reads as “I applied to the jobs and got rejected. There’s nothing wrong with me, so the jobs must be broken”.

This is the maybe the worst way of interpreting what they said. They can come and correct me if I’m wrong but I read that as: they have a particular ideological objection to this “cloud” ecosystem and the way it does things. It’s not a lack of skill as your comment implies but rather a rejection of this way of doing things.

deleted by creator

NTFS file locking is pain

deleted by creator

Well Linux is using rdrand in place of the fTPM one so … from firmware to hardware.

That depends on your distribution’s setting of the CONFIG_RANDOM_TRUST_CPU compile-time configuration option and the random.trust_cpu sysctl setting. I’m not sure what the major distributions are doing with that at the moment.

Then again even if you generate random numbers using pure software, is your CPU or firmware FOSS and without bugs (cough … Debian OpenSSL maintainers, cough …)? If not, and you assume you can’t trust the firmware and hardware - all your random numbers are belong to us.

Like you said, it is impossible to be completely safe. But using proprietary cryptographic hardware/firmware, the inner workings of which are known only to Intel, introduces a lot of risk. Especially when we know the NSA spends hundreds of millions of dollars on bribing companies to introduce backdoors into their products. At least when it’s an open source cryptographic library they have to go to great lengths to create subtle bugs or broken algorithms that no one notices.

Our CPUs are certainly backdoored too, beyond RDRAND. But it’s way more complicated to compromise any arbitrary cryptographic algorithm running on the CPU with a backdoor than making a flawed hardware RNG. Any individual operation making up a cryptographic algorithm can be verified to have executed properly according to the specification of the instruction set. It would be very obvious, for example, if XORing two 0s produced a 1, that something is very wrong. So a backdoor like this would have to only activate in very specific circumstances and it would be very obvious, limiting its use to specific targets. But a black box that produces random numbers is very, very difficult to verify.

Ultimately, the real solution is the dissolution of the American security state and the computer monopolies.

If I’m fucked, they’re fucked.

Not if they’re the only ones who know about the backdoors.

Edit: I started writing that before your edit about the “Ken Thompson hack”. An element of any good backdoor would include obfuscation of its existence, of course. The issue is it is impossible to predict every possible permutation of operations that would result in discovery of the backdoor and account for them. Maybe if you had a sentient AI dynamically rewriting its own code… anyway, backdoors in tooling like compilers is very concerning. But I’m not too concerned about a Ken Thompson type attack there just because of how widely they’re used, how many different environments they run in, and how scrutinized the outputted code is.

👁 Imagine using any commercial firmware/hardware RNGs.