I'm familiar with Proxmox, but it doesn't natively support docker.
It was originally developed as an absolute minimal distro for running containers on servers, but the immutable desktop movement led them to develop a desktop user-facing variant.
Other ideas that are very similar: Fedora SilverBlue (very similar, more mature) and VanillaOS (based on Flatpak insteak of Podman/Docker, very new)
The idea and execution is very similar to MicroOS, both on the desktop and on the server. Immutability isn't as scary as it sounds, highly recommend checking it out.
No webgui though, that has to come from another project...
https://rancher.com/docs/os/v1.x/en/support/
Rancher is working on a new version.
All of this left me feeling like the devs had different goals than I did as a user.
But the current iteration seems like k8s/helm are first-class features now, so yeah, should definitely look again.
[1]: https://github.com/linuxkit/linuxkit/blob/master/ADOPTERS.md
Its almost certainly the most performant distro in this huge thread (unless your host is ARM).
But I've never quite understood the appeal. Is it about running untrusted containers with VM-level isolation? Or having a familiar GUI for managing and lifecycling them? Something else?
Fundamentally, I worry that mixing VMs and containers is more likely to end up with the worst of both worlds rather than the best— basically you get the slow bootup of starting the kernel every time, but none of the application-level benefits of sharing base layer storage or mounting the same shared volume to multiple containers at once.
Although personally, I prefer Podman over Docker.
Proxmox is neat and you can run any OS under the hood including the suggestions mentioned.
You could also go for NixOS and declare you need OCI (e.g. Docker or Podman) in your Nix config.
https://www.truenas.com/docs/scale/scaletutorials/apps/docke...
https://www.virtualmin.com/documentation/cloudmin/virtualiza...
Is this a server? CoreOS
Portainer or Cockpit for web UI
Or Fedora Kinoite! IMO KDE is probably a better fit for the root commenter's "I just want a UI" position.
I’m sure it’s actually very straightforward and I’m just an idiot, but I haven’t had much luck.
We found that even with a web GUI, containers are just too complicated for the typical user "that knows nothing about containers".
Even with a GUI, no matter how nice it is, you need to learn about env vars, port mappings, cni networks, bridging, volume mounts, images, tags, host isolation, etc etc..
Our solution is to wrap apps into pre-packaged recipes. Pretty big trade-off of course, but it makes the installation and management completely fool-proof afterwards.
You can see some screen shots in the documentation here:
https://sentinelc.com/docs/user-guides/administration/manage...
As far as software goes I'm waiting on finalizing the DOS before exploring games and development, but it was fun was to be able to run this port of Wolfenstein 3D:
https://github.com/jhhoward/WolfensteinCGA
Besides all that I'm thinking of maxing out the RAM (it's 640k now, but can take an additional 128k for video), and maybe adding a real time clock and network card. I do have another Tandy 1000 TX, so I could see how 80's networking worked. That is probably another can of worms though.
The result is way more maintainable than previous iterations of PrintNanny OS images, which used a combination of Ansible and Packer to bake a "golden" image based on Raspberry Pi OS.
I haven't done much with Yocto, but I had very good experiences with Buildroot, particularly with getting helpful answers to noob questions I posted on stack overflow. One was answered by Thomas Petazzoni who, I think, is one of the main people behind Buildroot.
When whatever movie we wanted to watch failed to play on their computer, likely due to codec problems (it used to be a hassle before VLC) I'd pop the bootable Linux CD in, reboot and bam we were watching the movie. It was great.
And it literally rocks at that. I would strongly encourage everyone with an old or small pc/laptop/sbc/whatever that is too resource limited to run a "regular" distro, to try Alpine on it. The amount of resources saved thanks to using musl instead of glibc is astounding.
Something akin to BSD but Linux. Ideally something that supports a two-stage deployment where you compile for the exact target CPU and then the final thing has no extraneous components at all.
Maybe Nix?
This might be a shot in the dark, but wouldn't Alpine Linux be a good general purpose candidate for this: https://www.alpinelinux.org/about/
Many use it as a basis for container images, but it also runs pretty well as a regular Linux distro, albeit musl and busybox might present some compatibility challenges in some cases. Regardless, it seems to be pretty lightweight and widely supported, most software that you'd expect is also available and generally there are few surprises.
It does have a somewhat short release lifecycle, though: https://endoflife.date/alpine
I'd think about what your goals are and optimize for that use, it's going to be hard to do both the things you mention at once since they are somewhat at odds with each other. IMHO start with Debian, with minimal packages it's very slim yet you have the full power of their packages when necessary.
1. Write a config file
2. Run the command that builds the system
3. Test the system
4. (optional) Run the command that bakes the fresh system generated from the config into an image.
5. Deploy using either an image or NixOS's config based deployment tooling.
Huge improvement, reboot to activate was a major downside.
- a Linux image that can upload to a VPS
- a Linux image including your web app and essential tools (web server, database)
- anything not needed from the Linux image is removed (tools, utilities)
The idea is that a custom Linux image (which includes your pre-installed web app) can be installed to any VPS: pre-configured to be Linux only for your web app. (Note: this a scenario without docker.)
In the days before Docker what we would use is CentOS with custom scripts using Anaconda[1]. You start with the base system and then add on whatever you need. You can also configure /etc however you need. The output is an ISO of your own custom Linux distribution.
One neat thing about Anaconda is you can add a provision script that runs on initial boot. So if you need to "bake" in your app but leave a certain amount of configuration for install-time, that's the way you do it.
[1] https://access.redhat.com/documentation/en-us/red_hat_enterp...
> The following subscription-only content has been made available to you by an LWN subscriber.
Looks like someone with a subscription submitted the link to HN, allowing us to read the article.
I've been a low level subscriber for 20+ years now. I remember when it seemed the financial model came very close to unravelling - 2002ish. Despite that, the apricot coloured site has managed to flourish and continues to flourish.
LWN is quite a phenomenon. Cheers: Jon.
:)
:)
Isn't this basically what you get when using any minimal install type distro as a base, and also when building Docker images via Nix or similar?
Relatively long-lived, potentially multi-process server things is what LXC is for. It makes more sense to run LXC than Docker in that situation anyway. -_-
> OpenSUSE MicroOS has a read-only root file system, using Btrfs. Transactional updates are handled by a SUSE-specific wrapper script around the package manager zypper, transactional-update. This creates a new Btrfs snapshot of the root file system and then performs an update of the system. If the installation was successful, the script marks the new snapshot as the default snapshot. On errors, the snapshot is discarded and the previous one remains as the default. A reboot activates the new snapshot.
My comment above was saying that you don't have to use MicroOS per se to get this. A regular openSUSE install supports the transactional server role that does the same thing as MicroOS.
"Alpine Linux was chosen as the base distribution due to its low storage requirements, making it more suitable for older devices. Excluding the kernel, a base installation takes up approximately 6 MB"
i guess that would also make a more secure phone, one that is less likely to call it's mother ship.
thanks for the tip!