Whitespace is not visible. It is the absence of something that is visible. Whitespace should be used for the comfort of the reader, not to determine scope. Are you proposing that a " " character is more visible than "{}"? The fact I must quote it to make what I am discussing even apparent speaks for itself. I'm not arguing that indentation is bad, far from it. In fact, the flexibility of using indentation purely for readability, makes code more readable.
If you run it in podman, podman can export into a kubernete file, but its been a long time since I've tried it though. podman kube generate $CONTAINERNAME
is podman-compose really dead? Their github page looks active at a glance. The tooling is so similar, I use podman for local testing, and deploy to docker, but I've also done the reverse. As long as your not using really exotic parameters its really just a drop in replacement, I've even used GPU passthrough for AI project no problem in both docker and podman. At the end of the day, they're just slightly different frontends for the same backend.
As far as docker support, its often as simple as just providing a Dockerfile, which is basically the same thing as your build scripts. These days I've often used the Dockerfile INSTEAD of the readme to find help compiling some projects.
I agree, whether or not it is good or bad, or readability concerns over nested braces. I fundamentally hate invisible delimiters. If it matters, make it visible. We have so many ascii characters, why not just borrow a few?
Raid0 (combining both drives' capacities) is not really tiered storage. You would want Raid1 (each drive is a copy of the other drive ), but doing this isn't a backup. How will you be monitoring the drives so that you know if one of them actually fails?
I don't think the RPi has a new enough kernel, but with bcachefs you can do tiered storage. By combining the storage of the ssd + hardrives, into a single block device, then make the ssd the read/write cache, and give the whole pool replicas=2, so that that if one drive dies you still have the failover of the other drive. Do be aware this setup is still not a backup however.
I've used it in the past with rclone, just mounting it with a systemd service on boot, and treating it like another folder on the system. Does it give you any logs as to why its not connecting right?
I use pgup/pgdn every day. Especially with terminal multiplexers, as I am unaware of how to view the scrollback buffer of long outputs faster than a quick couple of pgup's.
It does make sense. Thank you. I appreciate the link!
However, my cloud usage is purely as a proxy/load balancer, as none of my cloud providers hold any actual data. They're just routing traffic, and all data/processing is on premises. What I'm interested in, is how to setup something like what you describe, but on premises also. From a design stand point, if I wanted to protect myself from a ransomware attack, obviously my cloud backups would be lost because they're a mounted filesystem during a backup eventually. So I don't know how to wrap my head around handling this, just storage design wise as specific tools I can figure out. How does one create a recovery point, and keep it safe from something like this? Just image the entire file system from a live booted offline environment? Feels like a chicken-egg problem to me.
I've thought about how I could handle disaster recovery for my homelab environment, but I haven't come to any good solutions. For example, if my main concern was being hit by crypto. I can't just recover from a regular backup, since I'm not sure how I can make a backup without that backup just being encrypted along side everything else. Since I mainly just backup everything to my file server, which is then synced to the cloud. In that setup, my cloud backups would be lost as well.
Would you have some starting points on how others handle disaster recovery? I'd like to avoid manually making an offline backup, because inevitably I'd forget to do it, which would make it useless anyway.
In that it’s not a kernel with just a c library and busybox
This wouldn't be a distro though, at least not in the context of the question being asked by the OP. My point being that Arch isn't "minimalist", because its not really any more minimal than Debian, or Fedora. It is more vanilla than them, preferring to not modify the original sources beyond their packaging, while Debian does do a lot more changes in this regard.
Something like Tinycore, or Puppy are minimalist focusing on running in memory entirely, or Alpine is minimalist by focusing on reducing disk space. Debian, Fedora, or Arch installs, on the other hand, are basically the same in terms of size, unless you also consider them to be minimalist. At which point we are in agreement.
I wouldn't consider arch minimalist. It just defaults to a netinstall with no desktop. Debian's default net install also doesn't have a desktop. Arch is more "vanilla" than debian, but not noticeably more minimal on first install.
I believe they changed some of their licensing from the fallout of their IPO. Just worth noting for the selfhosting crowd. I know terraform is being forked entirely, but I'm unfamiliar with the specifics beyond that.
No amount of polishing that turd will make me ignore the fundamental user unfriendliness that is nested text drop-downs.
Can you give me an example of this? From my perspective, using something like Kate, the extremely user friendly experience of discovery is vastly better than something like vi. In Kate, I appreciate the discoverability of having a list of options. I recently learned it can interact with LSP's because of the menus. I don't use it for that all that much, but it was cool to even know it could do that. Maybe vi is bad comparison, but off the top of my head GTK apps just have the hamburger menu, that then opens up the list of text menu options. Seems like its just hiding the option menus by nesting them in an additional layer of a button.
For the record, I haven't used a windows computer as anything more than an appliance in over a decade, so maybe the influence is lost on me.
Whitespace is not visible. It is the absence of something that is visible. Whitespace should be used for the comfort of the reader, not to determine scope. Are you proposing that a " " character is more visible than "{}"? The fact I must quote it to make what I am discussing even apparent speaks for itself. I'm not arguing that indentation is bad, far from it. In fact, the flexibility of using indentation purely for readability, makes code more readable.