No problem! Yeah, as long as you have the space, I think this would be a good way to repurpose an old junker PC. I imagine a quick search of something along the lines of “how to configure a samba server” should bring up some decent tutorials.

I use an older HP thin client PC with a 4TB solid state drive as an SFTP file server using vsftpd, but if you are local only then an SMB server using samba would probably be fine. I use SFTP because I wanted something a bit more secure which I can port-forward with my router on a random higher-numbered port for remote access.

I mostly taught myself how to do this by looking at guides originally meant for the raspberry pi, but there is nothing different about running these same programs on Debian or the like. Personally, I would not recommend a raspbery pi for a large file server, as they do not natively support SSDs without additional hardware which will make the price significantly higher and less self-contained than a used, older-gen thin-client PC which can be had for relatively low cost on places like ebay (though they do make some fairly high capacity micro SD cards these days).

Hardware-wise, generally these types of servers are not CPU intensive, nor do they require any particularly high amount of RAM, so an older-gen or lower power CPU can often work fine, but you should probably make sure to get something with at least gigabit ethernet speeds, as a 100Mbit connection on, say, a raspberry pi 3 or older will be very slow for transferring large files.

I mostly learned from some of the terminal customization which came stock with Manjaro when I was first learning Linux. So when I made the jump to Arch, I customized my terminal with fsh with the powerlevel10k theme and text highlighting. I also modified some of the default text colors to a green color to evoke green phosphor CRT terminals.

Daily Arch user here. The process of configuring an Arch install is perhaps not as difficult or mystical as you are imagining. I would say it is more like your first analogy: picking what off-the-shelf parts you want for a system and then putting them into a case. I think what you are describing is more like Linux from Scratch.

Installing Arch is effectively taking the steps performed by the installer .iso disks which every distro uses and instead doing it manually with CLI commands. You use CLI commands to partition the drive, create a filesystem, install a basic set of packages, then chroot into your system and use the package manager to install the rest of the packages you want. Aside from editing a couple config files, there is zero coding involved. The exact steps vary from guide to guide, but a basic outline of what I do is as follows:

• First, I download the Arch iso and write it to a USB.

• Once I boot up the install USB, I use iwctl to connect to my wifi for the packages I will need to download,

• then I use fdisk to partition the drive I want to install to with an EFI and linux filesystem partition (You might also make a swap partition at this step but I typically use a swap file on my filesystem partition).

• then you use mkfs to create filesystems on the EFI and linux filesystem partitions.

• Then I use genfstab to make the /etc/fstab file

• Then, I use pacstrap to install the base packages like pacman. Then I mount the filesystem and chroot into the new partition.

• From there, I basically use pacman to install all the packages I need, including the linux kernel (I use linux-zen), the DE (I use KDE), the boot manager (I use Refind), and everything else. There are a few cleanup steps like setting the locales and time zones, etc. but that is about it.

I suggest watching a guide on youtube, which was how I learned, or installing something like Arcolinux or Endeavour, which simplifies the installer into a series of checkboxes to select what DE you want, etc.

As others have mentioned, secondhand laptops and surplus business laptops are very affordable and probably better value for the money than a chromebook. My understanding is that drivers for things like fingerprint sensors, SD card readers, or oddball Wi-Fi chipsets can be issues to watch out for. But personally I don’t care about the fingerprint sensor and only the Wi-Fi would be a major issue to me.

A couple years ago now I picked up a used Acer Swift with 8th gen intel and a dent in the back lid for something like $200 to use as my “throw in a backpack for travel” laptop, and it has been working great. In retrospect, I would have looked for something with 16GB of RAM or upgradeable RAM (8GB soldered to the motherboard, ugh), but aside from that minor gripe it has been a good experience.

The Arch installation tutorial I followed originally advised using LVM to have separate root and user logical volumes. However, after some time my root volume started getting full, so I figured I would take 10GB off of my home volume and add it to the root one. Simple, right?

It turns out that lvreduce --size 10G volgroup0/lv_home doesn’t reduce the size by 10GB, it sets the absolute size to 10GB, and since I had way more than 10GB in that volume, it corrupted my entire system.

There was a warning message, but it seems my past years of Windows use still have me trained to reflexively ignore dire warnings, and so I did it anyway.

Since then I have learned enough to know that I really don’t do anything with LVM, nor do I see much benefit to separate root/home partitions for desktop Linux use, so I reinstalled my system without LVM the next time around. This is, to date, the first and only time I have irreparably broken my Linux install.

Not my preference personally, but cool.

I have been daily driving Linux for a couple years now after finally jumping ship on Windows. Here are a few of my thoughts:

• it is important to make the distinction between the distro and the desktop environment, which is a big part of how the UI will look and feel. Many of these DEs such as KDE Plasma, XFCE, and GNOME will be common across many distros. I might do some research on which DE you like the look of. I personally have used KDE the most and that is what I prefer, but all of them are valid options.
• Coming from Windows, I would go into this with the mindset that you are learning a new skill. Depending on how advanced you are with windows, you will find that some things in Linux are simply done differently to how they are in Windows, and you will get used to them over time. Understanding how the file system works with mounting points rather than drive letters was probably a big one for me, but now that I have a grasp of it, it makes total sense to me and I really like it.
• It will also be learning a skill in terms of occasionally debugging problems. As much as I would like to report that I’ve never had a problem, I have occasionally run into things which required a bit of setup at first or didn’t “just work” right out of the box. I know that probably sounds scary, but it really isn’t with the right mindset, and there are tons of resources online and people willing to help.

I could see that being the case for some things, at least in cases where it is an older design being updated or VE’d. Perhaps some sourcing person changes the LED part number on the AVL and forgets to check with engineering whether the resistor value which goes with it is a sane level of brightness still.

Electrical engineer here who also does hobby projects. I’m with you. I think some of the reason may be that modern GaN-type green or blue LEDs are absurdly efficient, so only a couple mA of drive current is enough to make them insanely bright.

When I build LEDs into my projects, for a simple indicator light, I might run them at maybe only a tenth of a milliamp and still get ample brightness to tell whether it is on or not in a lit room. Giving them the full rated 10 or 20mA would be blindingly bright. I also usually design most things with a hard on/off switch so they can be turned all the way off when not in use.

Of things I own normally I also have two power strips with absurdly bright LEDs to indicate the surge protection. It lights up my whole living room with the lights off. If I had to have something like that in my bedroom, I would probably open it up and disconnect the LEDs in some way, or maybe modify the resistor values to run at the lowest current I could get away with.

I feel like designers have lost sight of the fact that these lights are meant to be indicators only-- i.e. a subtle indication of the status of something and not trying to light a room-- and yet they default to driving them at full blast as if they were the super dim older-gen LEDs from 20+ years ago.