923 karma · joined February 26, 2009
Another self-taught software engineer.
https://dottedmag.net/
Remote: Yes
Willing to relocate: Maybe
Technologies: Go, GCP, Terraform, Kafka, ELK, C, and more
Resume: https://dottedmag.net/cv/
Email: cv@dt.mg
- Expert in low-level Linux, server automation, containerization, Kubernetes
- Head of engineering in an infrastructure startup, responsible for architecture and development processes
- Prolific open source contributor, created an embedded Linux distribution
- Owned development processes and tooling end-to-end in numerous companies
When I went through a process of relinquishing my previous citizenship, it included:
- 11 documents,
- 10 apostilles,
- many authorized translations,
- several photos (?!),
- notarizing my signature at the consulate,
- receiving two documents via regular mail from my birth country (IIRC this service is now discontinued, and one has to go to obtain these documents in person, and no, power of attorney is not accepted, and yes, the country in question is at war, so any man trying to do so risks being drafted and sent to frontlines immediately),
- several thousand euro in various fees,
- many hours spent preparing documentation,
- ~6 months from the beginning of the process to the end.
However if this code refers to any functions from modules via syntax "foo:bar/1" then these references will be resolved on the target node, and both nodes better have the same versions of modules loaded.
Have you got it working with PCI or PCIe? PCI devices attached to the top-level bus do not request I/O ports unless they need to, and if they do, they request only small slice.
QEMU also allows one to put 8 static PCIe devices into a single "multifunction PCIe device", so it requests 4K I/O ports per 8 devices, giving a bigger headroom. The downside, of course, is that all these 8 devices lose individual hotpluggability, and can only be added/removed en masse.
The biggest problem is hotplug slots, each taking 4K I/O ports unless told otherwise in a way libvirt does not support as I described in the article.
A lot of hardware has migrated from using I/O ports to memory-mapped I/O, and instead of fixed I/O addresses ACPI or a similar mechanism provides the OS with the directory of memory addresses to talk to.
For example, instead of PS/2 keyboard/mouse at I/O ports 0x0060-0x0064, ACPI provides the OS with the memory address to talk to a USB controller, and the USB controller does not use I/O ports at all.
Have a look at a list of the most common I/O ports: https://wiki.osdev.org/I/O_Ports#The_list
Most of this hardware is gone. The easiest way to see them at all is to boot a VM in QEMU and specifically ask for these ancient devices to be present.
Not sure it will work though: I need to add an option to a `pcie-root-port` command-line argument managed by libvirt.
I can try skipping creating `pcie-root-port`s by libvirt completely, and add them manually using options passthrough, but I'm not sure the rest of libvirt won't throw a fit when it finds other devices that refer to these (unknown to libvirt) PCIe slots.
To make public IPs and volumes hotpluggable without a guest agent running inside every VM one has to manage them in a way guest OS will handle hotplug using regular mechanisms. For volumes it's PCIe storage hotplug, for public IPs it's PCIe network card hotplug.
If a VM is used as a Kubernetes worker, couple of dozen volumes and public IPs attached is not an unlikely situation.
Window width as a determining characteristic of a mobile? Come on.
I have no idea about none of their areas either.
So I guess this only applies to a prestigious occupations.
When I was using NixOS I regularely saw software that was tested on Ubuntu and Fedora and had installation instructions for these two distros, but was missing from Nixpkgs (because it was experimental, new or very obscure), and didn't work out of the box with NixOS' FHS.
Nevertheless community of NixOS developers is many magnitudes smaller than the amount of developers churning out new software, hence once you get off the golden path of the widely or somewhat widely software, the probability of a random thing working without additional elbow grease from the one who tries to use it is indistinguishable from 0, due to NixOS' dialect of Linux not being perfectly compatible with other dialects.
At the very least, documentation for the random thing will never tell you what to do under NixOS, and documentation is very much the part of the software product.
I don't remember the exact set of errors (there was more than one), but NixOS+FHS failed so many times I gave up, and wrote that blog post.
This is the essence: you can't expect application developers to target your niche distro.