The cheap alternative I use is based on a USB switch hub and a monitor that has enough inputs for all of the computers I want to switch between.
The hub is a very simple and inexpensive device that essentially just lets you change USB devices between computers. It has 4 ports for USB devices, and 4 input ports for USB hosts. There is a wired remote control that allows you to switch between the hosts.
The way you turn this into a KVM-like device is by having each host connected to the monitor/s indepentently. In my case, I have only two hosts, and each one is connected via HDMI cable to my single monitor. Each host is set up to detect when the USB hub is connected, and then send a DDC command to switch the monitor input over to itself.
The end user experience is: I press a button on the wired remote, which is mounted on my keyboard tray, and then after a short delay the corresponding computer is on my screen and everything works normally.
On linux, this is trivially accomplished with a udev rule + a script calling ddcutil.
On my work machine, a Mac, I could not find a simple solution that worked reliably on my specific Macbook Pro model that I would recommend, so I had an AI write a custom daemon for this purpose.
The major benefit of this "poor man's KVM" is that you do not need an expensive and finnicky piece of KVM hardware. You do not need to worry about the video chip supporting your setup, or firmware bugs. You buy one cheap, commodity product. The downside is the reliance on the hosts, and on monitor features, and having to set up the functionality manually. In my case, this is the sort of thing I basically just set up and then never touched again, so it was a fine trade-off. If I get new computers, or a new monitor, or I change which porta the computers are attached to, then I have to change the code.
At the beginning of my career, it was typical to have servers in the office, either in a server closet, or in a proper server room. Even if we had servers off-site, the development infrastructure was often still local. It was typical for experienced developers to know how to do basic "physical" maintenance. I was a system administrator before I was a developer, so often I was the one who ended up doing it. I imagine many HN readers remember those days. I miss it a bit!
The greatest weakness of Google Photos is that it has no real incremental, automated backup features. If it could incrementally sync over to other services, it would be much better. The closest is to manually use Google Takeout to export specific time ranges, and then copy those elsewhere.
That's me in a nutshell. I have close to 300GiB in Google Photos, mostly photos and videos of my children. I take a lot of photographs because getting a good shot, for me, is mostly a matter of luck. I don't delete that many photos because it's active work and I don't really care to spend the time. I do curate an album of decent ones, just so the few people who care can see new photos and videos every now and then. I pay a relatively small fee for 2 TiB of space.
This model has some significant downsides for humans, but less so for automatons. It eliminates some major problems of software development like merge conflicts, dependency hell, etc.
I still have my copy of Learning Perl. Mostly because it represents a milestone in my learning. I have kept and obtained a number of other books simply because they are antiquated, special and/or classics that are interesting to read even if they are not that useful to me, like Codd's relational book, or Calendrical Calculations. I hope the AI is trained on these sorts of books, so that the knowledge can live on in a different way.
I might be missing your sarcasm, but this is a common approach for large scale builds. Virtual filesystems are used to provide a pre-computed tree hash as a xattr. In a more typical case, you can read the git tree hash.
Not sure it was meant as sarcasm really. I just think so many build (and other) problems could have been avoided it a file hash was available on every file by default.
In the current POSIX paradigm yes, it would be expensive. But if the hash was defined as the hash of fixed blocks, it wouldn't be expensive. The raciness depends, a lot, on the semantics we would define. (In the context of a build system, it's no different than that the file could get a new mtime after we read the mtime.)
The hub is a very simple and inexpensive device that essentially just lets you change USB devices between computers. It has 4 ports for USB devices, and 4 input ports for USB hosts. There is a wired remote control that allows you to switch between the hosts.
The way you turn this into a KVM-like device is by having each host connected to the monitor/s indepentently. In my case, I have only two hosts, and each one is connected via HDMI cable to my single monitor. Each host is set up to detect when the USB hub is connected, and then send a DDC command to switch the monitor input over to itself.
The end user experience is: I press a button on the wired remote, which is mounted on my keyboard tray, and then after a short delay the corresponding computer is on my screen and everything works normally.
On linux, this is trivially accomplished with a udev rule + a script calling ddcutil.
On my work machine, a Mac, I could not find a simple solution that worked reliably on my specific Macbook Pro model that I would recommend, so I had an AI write a custom daemon for this purpose.
The major benefit of this "poor man's KVM" is that you do not need an expensive and finnicky piece of KVM hardware. You do not need to worry about the video chip supporting your setup, or firmware bugs. You buy one cheap, commodity product. The downside is the reliance on the hosts, and on monitor features, and having to set up the functionality manually. In my case, this is the sort of thing I basically just set up and then never touched again, so it was a fine trade-off. If I get new computers, or a new monitor, or I change which porta the computers are attached to, then I have to change the code.
reply