Why don’t they just move to El Salvador if they like Bitcoin so much

Plan 9 posting

We are so back

OpenBSD, RISC-V, and 9front mentioned?

Haven’t listened to BSDNow in a while, but maybe I’ll listen to this episode

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

Out of all the parasites capitalist society has produced, Nestle executives possibly deserve the the most

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

The Innovator’s Dilemma

Did you know this was Steve Jobs’ favorite book?

Rich Dad Poor Dad

Wow, this is life-changing, I knew it was poor people’s fault for being poor!

The Coddling of the American Mind

This new generation is turning into got-dang snowflakes!

I’ll believe it when we dismantle the nukes, class society, and fossil fuel industry. A better world is possible but only if we fight for it.

Programmers can trust language security features too much…

Of course, they’re nice to have and really can make things easier to implement securely but it’s still very easy to introduce security problems or bugs into any code. This is just an unsolvable problem of writing imperative code. All imperative code will reliably have memory leaks (even in Java!) and security holes because no compiler can check to see if you thought of everything.

And large and complex compilers/interpreters with these security features can end up introducing their own security problems or bugs in the process of implementing them.

I’m just tired of people entirely dismissing languages like C because they don’t have these features. Especially when the operating systems their code runs on and their languages may even be implemented in C!

C is very reliable. It works almost everywhere with very little resources or overhead and many of the most fundamental parts of our systems (that have to work reliably) are written in C. Many of the languages in that image are even implemented in C.

If you want to write portable, fast, and simple code C can help you with that if you use it in the right way.

Cygwin is great too! You can have a fully POSIX-compliant environment on Windows, no virtualization or anything needed. You can even distribute programs to other Windows users linked to their POSIX compatibility layer library.

NTFS file locking is pain

Sorry, I should have been more clear. I agree with you. I’m not talking about text-based interfaces and commands. I just mean the way Unix/POSIX handles “terminals” (devices that accept streams of characters according to a protocol established in the 70s) is an antiquated way of handling simple plain text streams. It made sense back then when there was a need to send commands to dumb terminals in-band with the plaintext but this doesn’t really make sense these days when your “terminal” is actually just a program pretending to be a dumb terminal running inside a window. When was the last time you used job control instead of opening another window?