LVM

Even though the logical volume manager is longer around in the Linux world than I am, you still see installers of even mainstream distros trying to install your home on a partition table partition. LVM is just a great tool for both abstraction of filesystems and making things more delcarative.

Especially for workstations and traditional single machine fileservers it simplifies operational workload, especially when scaling out, to a degree that is ludicruous. Insert new disk(s), add them to the volume group, resize logical volume, resize filesystem, done.

LUKS

As with LVM, LUKS is around since forever. While full disk encryption certainly has the downside of requiring more care to allow for disaster recovery, on the upside it is the only somewhat secure way of encrypting your data. I have not seen performance impacts in 2010 and hardware has become only more powerful since then.

If you run servers or computers used by employees, it is even more important to encrypt all disks, as at some point those disks will be EOL and well, then you have to make sure the data stored on these does not get into the wrong hands. While some manufacturers already physically shred all disks that are returned by business customers, getting rid of tens to hundreds of thousands of disks securely can be a PITA. Safe yourself the trouble and just encrypt everything.

Building initrd and kernel for yourself

It's not hard. It's fun. It saves time. You don't have to do it always, but you should know how to do it and know that it is easy and does not take much time. The amount of time people spend to mitigate some kernel configuration issues in the larger distros is ridiculous. If it works ootb, fine, don't change a thing. If it does not, don't build tons of init scripts and run several daemons, if it can just be fixed by changing a [*] to [M] or something similar.

Especially as the number of services on any machine orchestrated by the machine itself is going down, moving things to the initrd might be part of making deployments more atomic.

I like these three previous items so much, I even bothered to write a post on how to build a minimal initramfs for use with LUKS and LVM.

git

If you do not use version control yet, start reading about git and learn to use it. If you still use svn, I am sorry. Start reading about git and learn to use it. Even if you do not code, git is a gift. Especially in academia it is still underutilized and people still collaborate in Word (LOL) or send .tex files with e-mails, numbering the versions by name or what have you.

It is just the right tool for many jobs and definitely made software better. Some people did not like how git does some things and inspired to write them quite similar version control systems, but in the end they all ended up only improving upon git marginally.

Sometimes it is cumbersome and while branching, merging and those things are simple in theory, working with those takes some practice. But it is practice well worth it and it will just make your and your collaborators' lifes so much easier.

vim (or any other modal editor)

OK, I do not care actually about what version of vim you like, if it is vi, vim, neovim or what not. The main feature I like is the distinction between navigation and editing and just writing things. Maintaining documents is far harder than writing new ones, thus it is only sensible that insert mode is not the main mode.

Asides that vim - like pretty much any other editor out there - has a lot more functionality. You do not have to become a master, but at least show some effort learning how to use your most important tools.

unison

Even today unison is the best tool to synchronize your own work stations. It was almost ten years ago when I wrote a short post about using unison and people already considered it dead, because, well, feature completeness ain't sexy.

For actual file sharing and a multi-user solutions it would probably best to setup an EFSS like ownCloud, Seafile or Nextcloud somewhere. But, for single user "I have n unix boxes and want part of my home synchronized", unison is the tool. It does one job and it does it exceptionally well.

Kubernetes

Kubernetes is aweseome and probably I will write a few more posts about it, time and workload permitting, over the course of the next months.

I remember when I was first managed a couple installations about a decade ago and I dreamed about creating one great solution that would allow me to deploy a typical LAMP stack across a couple of servers. Because in the end most of the stuff was just apache + software + a few configs pointing at some db server. Of course you would need to find a way to distribute configs accordingly, manage reverse proxy and hostnames, make sure data is available. But then you would need to have backup plans and then you would need to make sure you can move services across machines to reduce downtime, etc., etc..

While the task itself is simple, reducing it to something like "magical tool install wiki running on 2 hosts, db cluster running on 3 hosts" is not trivial and just a lot of work that has to be automated in a somewhat uniform way. And well, Kubernetes does exactly this. Great. I am amazed. I continue being amazed. And it even is somewhat lightweight and simple, but I guess for this I need some more articles, as the existing literature is not that good.

It took me some time to see the awesomeness of it, but that was because much of the beauty was tainted by the mess that docker was and still is, both conceptually and from a usage standpoint. Luckily kubernetes does not care about your container runtime and you can use something better (i.e. anything but docker).

ceph

More cloud things. Kubernetes is cool, but what also is cool and especially in conjunction with kubernetes, is scalable and reliable network storage. Just as Kubernetes, ceph seems like a needlessly complex beast from hell at first sight, but it's pretty close to being the simplest solution to the problem of hosting files replicated over several systems.

Its performance is pretty much dictated by the performance of your network and disks, just as one would expect from a well designed network filesystem. Especially rbd block devices have, network speeds permitting, comparable performance to the underlying disks, with reads being a bit faster and writes a tiny little bit slower.

It seems to scale well into the single digit petabyte range and fits exceptional well into the whole cloud native landscape with CSI provisioners being available for Kubernetes.

I'd love to write something about the awesomeness of EOS, but I won't be able to dive into this for real before it is sensible to travel again. However, as far as I know, it is the only candidate already warming up for the exabyte age.

Downloading and owning media

Either by malevolence, incompetence or just companies going out of business or moving to other sectors, I think at this point everyone has experienced some significant loss of media they only had access to online or via some propietary app. If your taste is sufficiently mainstream, this might never be much of a problem. But in niches, like smaller music releases, research that's not hosted on something like arXiv or maybe just some blog article with a recipe you liked, expect the source to go away and make offline backups. With the exception of archive services backed by the research community, there is little reason for discriminating between services. Commercial services are not yet built to last on the scale of lifetimes.

Of course there is also the problem that usually such propietary services siphon the money and the creators end up being paid close to nothing, unless of course they are the very big fish. Furthermore the costs for all this DRM idiocy is coming out of your pocket and it is not sensible to pay for a war waged against you, the customer.

Conclusion

I think there is an overarching theme here: Make your life easy and own your data, no matter on which scale.