Most of the popular touring bikes fit your budget. Really you're just looking for durable, a wide gear range and the capacity to mount gear. Surly disc trucker has historically been one of the most popular as an example, but there are a lot of others.
Also, it can absolutely be done with cheaper. My partner and I finished a 4800 mile trip last year. I used a second hand cyclocross bike that I got off craiglist for ~500 a few years ago. She had a road bike that she bought for 200 from the local bike project.
Thanks a lot. Touring bike then. I'll probably consult some bike shop owner to give opinions. BTW how did you train for the long ride? Did you go from say 100 and then inter-city?
It looks like at least some of the individuals claiming production issues are pulling the latest version of Axios from a CDN. It doesn't seem like they actively pushed a release to production without adequate testing. Not that I disagree with your overall point, but it's at least a little bit less damning.
The parent comment is still talking about rootless podman (and really just user namespaces). Root in the container is absolutely mapped to the user executing podman outside the container.
If it mapped to root outside the container, you could just use podman to create setuid scripts owned by root for very trivial privelege escalation.
I've happily used systemd-boot in the past, but it's definitely less featureful than grub. Notably, it doesn't support the use of a (LUKS) encrypted boot partition. I'm not even sure it supports /boot on btrfs? Both are necessary if you want to have an encrypted root AND include the matching kernel / initramfs in any snapshots of root.
Systemd-homed isn't inventing the idea of encrypted home partitions and fundamentally, what you're saying is that cron is incompatible with encrypted home partitions (or any other auto mounted home partition, ex: network mounted). The same is true for the concerns about ssh.
If you listened to the original talk from Lennart, you're really just giving examples of one of his major points. Because /etc/passwd wasnt flexible enough to accomodate arbitrary user properties, user configuration has organically spread out over time into all these "side car" configuration files. Some are scattered around /etc so not easily portable while others are in the user's home directory and suffer from exactly the scenario you've mentioned. One of the goals of systemd-homed is to add a portable, extensible format for a user record external to the home directory which would mean that systemd-homed rather than causing, could actually lead to a solution for the issue you've highlighted.
One of the supposed benefits I remember from his original talk on systemd-homed is better handling of encrypted home directories even for a single user workstation.
Even on a single user workstation, having an encrypted root filesystem doesn't do as much good if your laptop is left booted up with the root filesystem unlocked most of the time. Systemd-homed in that scenario is supposed to make it easier to automatically unmount/mount on locking/unlocking the workstation.
Have you taken a look at podman / buildah? My understanding is that podman resolves all of the security concerns you highlight above while mostly maintaining compatability with the docker cli and existing docker images. It gets rid of the docker daemon so your containers (and restart policy) can just be managed by your existing service manager.
I only just recently discovered podman and I've been pretty excited. Having never used LXD and only understanding the high level differences between the two, I'm curious how it compares with regards to security and usability.
I'm a little bit too familiar with podman. LXD is more mature and actually implements all of the hardening features I mentioned. podman could implement them in theory, but doesn't. Its default security posture is very similar (though not the same as) Docker. Don't get me wrong, I do want to see podman succeed -- but I don't like the amount of unneeded hype around it. It's effectively a Docker rewrite by Red Hat (and other folks) that has some fairly important improvements, but it's not a revolutionary new concept. As for buildah, I am too biased to respond to that question.
Oh, and most of the Docker CVEs found in recent years -- including those I've found -- have also impacted podman. The most brazen example is that podman was vulnerable to a trivial symlink attack that I fixed in Docker 5 years ago[1,2]. It turns out that both Docker and podman were vulnerable to a more complicated attack, but the fact that podman didn't do any special handling of symlinks is just odd.
I have to admit, the biggest selling point to me for podman is the removal of the central docker daemon. For my use case (personal workstation and home lab), it seems strange to me that I need essentially another service manager for these processes just because I want to slap them in a container. It definitely makes sense that there would still be some gaps though as it's a less mature product.
You've definitely convinced me to take a good look at LXC/LXD though. Thanks for the thorough response!
It should be noted that (unlike Docker), LXD can be safely killed and upgraded without your containers dying -- which is the main problem most people have with Docker's container liveliness model (even with Docker's --live-restore there are many issues). The main reason why LXD has a daemon is that it supports lots of management features (such as live migration and clustering) which cannot easily be done without a daemon.
You can use LXC directly if you want to avoid a long-running daemon.
Also another vote for Splendor Duel. The original Splendor is probably my favorite game and Duel is the better version for two players.