ZFS has encryption now, dunno about the rest

You may be surprised to learn that they didn’t all run out until 2013. UEFI had been around for 7 years by this time, and Microsoft was doing patent enforcement actions against Tom Tom during this time period.

Sure, they’re expired now, but not at the time. It was supposed to be an open standard at the time.

More like

Best: the one I use.

Worst: also the one I use.

Out of curiosity, which one?

If “D” is physically on the same hard drive, then you’ll probably want to back it up before installing. Technically, you can manage to do it without screwing everything up, but I would not trust myself to. It’s always a good idea to have backups anyway.

Also, user files typically reside on C by default and it takes some effort to put them on a different drive. Things like Downloads, Documents, Pictures, etc. so it’s worth checking that before wiping as well.

Additionally, you’ll probably want to format your “D” drive to a Linux native filesystem (eventually, after you back it up, because formatting results in data loss). While Linux does support NTFS quite well, it’s not perfect, and your data would probably be safer on ext4 or f2fs (depending on if you have HDDs or SSDs) (or zfs or btrfs is you’re into COW filesystems).

In Linux, you have all of your files mounted to a single “drive” called /. Everything is below /, which is called the “root” of your filesystem.

Typically, user data is stored in “/home” and this resides in the same directory structure as the rest of your OS, but on most systems it’s on a different filesystem or even on a different drive entirely. This is because in Linux it is routine to put a “D” drive just in a folder. On my computer, I have several of these mount points defined, so the different types of data don’t get mixed around, and I don’t have to worry about downloading too much bullshit affecting my computer’s updates.

Hope this helps.

Just make sure you back up any important data before wiping your own hard drive. And yeah, Steam handles a lot of the weirdness of running windows only games pretty well automatically.

The last draft before publication: https://j3-fortran.org/doc/year/23/23-007r1.pdf

This is a cool idea. There are other programming languages that have libraries that expose similar behavior. For instance, Rust has the uom crate, Haskell has the units package, and C++ has the header only library SI.

But there is something to be said about it being built in.

The single killer feature that convinced me to move to NixOS is the ability to very easily keep separate development environments separate. For instance, if you’re working on multiple dev projects that have different minimum requirements, and you want to ensure that (for instance) you don’t accidentally use features from after boost 1.61 for project A, because that’s the stated requirement, but you need features from boost 1.75 in project B.

In a normal distribution, in order to set up an environment that has the proper version for project A you’d need to set up a chroot, a virtual machine, a complicated set of environment variables in a bespoke script with custom installation paths that you need to set up manually and remember to source, or just install a newer version of boost and rely on continuous integration to catch it if you screw up.

In NixOS, you can set up different shells which all reference the exact correct version of the libraries required for every project, you can have them installed simultaneously and without conflicts, and there’s even a shell hooking program that will automatically load and unload this configuration when you change directories into and out of the project folder. It makes managing many different projects much easier. It’s like a better version of venv, but for everything.

You can always configure the garbage collection to reduce disk space usage, or manually run it.

Another NixOS user (and minor package maintainer, if it matters) here. Essentially, NixOS is actually rather simple to write a configuration file for a particular program once you get the knack for the nix language and learn how to workaround the sandboxing. I would actually consider it substantially less involved as compared to (for instance) creating your own Debian package.

However, getting to this point will take a bit of effort, and this step is more or less obligatory to use software on NixOS, whereas it generally isn’t (but still is a good idea) on other distributions.

If the streching is so small as to be unnoticable (and I agree it’s pretty subtle) then I also don’t really understand the benefit.

Typically, the idea behind this sort of design is that it should be unnoticeable. The motivation is that, with other monospace fonts, the differences in character width, along with the inconsistent spacing and line thicknesses are both noticable and distracting. Some of this badness is avoidable, and this is what this font attempts.

and yeah that height difference is really weird. That almost seems like a bug.

I’ve been informed, (and had to double check because I didn’t believe it,) that the two "i"s are actually the exact same height. The first looking larger than the second is an optical illusion. Font design is hard.

True, they are the exact same height. Holy optical illusion, Batman!

I suppose this is part of what makes font design so difficult.

Here’s your code example in the editor. I don’t personally think the difference between the 'm’s is super noticable. But what did strike me a lot more is the difference in height between the two 'i’s in the first line. I think that difference is pretty bad.

Putting aside the misleading title…

Because this writes to and then runs an executable file with a known name, this script should never be used on a multiuser system in a directory where another user has write permissions. It is vulnerable to a timing attack where the attacker copies an executable they want run with your permissions between this script creating the file and running it.

You can likely inspect the traffic if you use Wireshark.

A wrapping script is a small text file that calls the program you want to call. For instance in Linux this would be something like:

#!/bin/sh

deluge -torrent $1

You save it as deluge-wrapper.sh. Use chmod to enable the execution bit (chmod a+x deluge-wrapper.sh). And then point your browser at it.

Be sure to doublecheck that running deluge in this way does open the torrent. You can test it in the command line. It might be --torrent or I might be misreading or misremembering the code from last night. Additionally, it might be deluge-gtk or something.

When you attempt to open a link in your browser it calls the executable you specify with the link URL as its first argument. Glancing at the deluge torrent source, it seems to want a different command line than the one the web browser provides. You can fix this using a small wrapping script.

Disclaimer, I have not studied the software in question and there are many ways to implement it, so this isn’t a way to say a computer is clean, just a way to detect if it’s infected.

Typically, keylogging programs like these are installed as device driver filters. Open devmgmt.msc, locate your keyboard and right click -> properties -> details tab -> property drop down -> upper filters and lower filters.

These should be empty normally. If there are entries present then you have some program that is hooking into your keyboard driver and accessing your keystrokes.

Similarly, there should be a filter on your mouse if it is being listened to.

If you are especially paranoid, you can jot down the GUID of the keyboard and mouse driver (it looks like a long hex number with dashes surrounded by {}s), then shut down the computer and boot to a rescue disk, open up regedit, mount the registry hive for SYSTEM it’s located in \windows\system32\config\system, (let’s say you mount it to SYSTEM.remote), then navigate to SYSTEM.remote\CurrentControlSet\Control\Class\

Then you scroll through this key’s values and look for UpperFilters and LowerFilters.

The reason why you do it this way is to avoid a rootkit situation, where a driver also hooks into requests to the OS for certain information, and uses that to hide its presence.

If a phone can track you with a deactivated eSIM then it can also track you without a SIM, by just also giving you a secret eSIM for use when your regular SIM is missing, and then simply lying to you about it.