The $1 is a positional variable. So if you run ./script.sh arg1 $1 would be arg1 in that example, $0 would be the ./script.sh. It’s the simplest way to pass an argument to a script.
- 0 Posts
- 16 Comments
Finally? It’s been SUSE’s default for at least a decade now. It’s the default for Fedora since 33, so ~5 years ago. Btrfs has been working for a long time.
Use a modern filesystem like btrfs or even lvm with thin provisioning to solve that problem. Separate partitions for ease of backup, but they all pull from the same pool of storage.
FlexibleToast@lemmy.worldto
Selfhosted@lemmy.world•Do you participate in this hobby without a formal IT education or a career in a similar field?English
1·2 months agoI was that guy. And then ended up with that career partly because of it.
FlexibleToast@lemmy.worldto
linuxmemes@lemmy.world•In a universe of enshitification, Linux is one of the few things that consistently gets better.English
4·3 months agoYou manually run that instead of letting it automatically stage updates in the background?
FlexibleToast@lemmy.worldto
Selfhosted@lemmy.world•Finally happish with my all-in-one homelab (20+ services and way too much tinkering)English
2·3 months agoYeah, but if you were doing lxc + docker per container you might as well use this oci as lxc method. I think both methods are silly, but that’s just my opinion.
FlexibleToast@lemmy.worldto
Selfhosted@lemmy.world•Finally happish with my all-in-one homelab (20+ services and way too much tinkering)English
4·3 months agoHow does that make it easier for maintenance?
FlexibleToast@lemmy.worldto
Selfhosted@lemmy.world•Finally happish with my all-in-one homelab (20+ services and way too much tinkering)English
71·3 months agoYou have each “docker” container in there own lxc running docker? That’s a silly way to do it if I’m understanding correctly. You’re adding overhead to containers for little to no benefit. You could put them all in the same lxc or Proxmox supports OCI containers natively now.
Sure. Red Hat moved CentOS where it belonged, upstream, in between Fedora and RHEL. That generally upset people who wanted a bug for bug free version of RHEL. Rocky and Alma were both born out of that era. Alma actually works with Red Hat, created its own SIGs and contributes upstream to Fedora. Rocky on the other hand is backed by CIQ. Does not contribute anything upstream, bends/breaks licensing to get source from Red Hat to get as close as they can to that bug for bug code without doing any engineering themselves. Then CIQ poaches Red Hat employees and customers by offering way cheaper support because they don’t pay for any of that pesky engineering.
Honestly at home there really isn’t a reason not to just use CentOS Stream imo. It is ABI compatible with RHEL. There is a misconception that it is a “rolling distro” but it only rolls through minor releases in that it doesn’t even have minor releases. Alma is something in the middle. Actively contributing, ABI compatible, and offers minor versions.
Hell, even Oracle at least adds their own twist to OEL instead of straight up ripping off RHEL.
At least use Alma. Rocky is toxic to the ecosystem while Alma contributes to the ecosystem.
You could almost literally do that with buildah in an action.
Way harder? It’s one little file to create.
For the free docker hosting?
If you have a dockerfile, take the extra step of making the workflow that builds the container and pushes it to a registry somewhere.
I switched from Portainer to Komodo a while back. I like how everything is declarative. It almost has a Argo CD feel to it without needed kubernetes.