Rendered at 09:36:30 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
abrookewood 3 days ago [-]
Congrats on launching something (more than most of us will ever manage), but I am struggling to see why I would use this over something with more backing. There are a number of similar projects that have a very similar goal, but have the support of a large community and/or commercial sponsor:
- Flatcar Container Linux: An open-source, immutable OS designed for automatic updates and large-scale container deployments.
- Fedora CoreOS: A, secure, automatically updating operating system designed for running containerized applications, succeeding the original CoreOS.
- Talos Linux: A modern, immutable, security-focused OS dedicated entirely to Kubernetes.
- IncusOS: an immutable OS solely designed around safely and reliably running Incus.
I think you need to more clearly explain how this is different. Again, congrats on the launch though.
jvican 3 days ago [-]
I use IncusOS in my homelab. It's a joy to set up and use.
Migrated from Proxmox and manage all my VMs. Heavily use coding assistants to automatically set things up through the IncusOS CLI, translate Docker-Compose images to Incus, write bash scripts to automate launching new containers to use `--dangerously-skip-permissions` without fear of repercussions, etc.
What I love the most about it is that it's possible to manage IncusOS with declarative files, so you always have visibility into networking setups, resource configuration, etc.
Highly recommend checking IncusOS out if you have similar use cases!
c9_9">hnarn 3 days ago [-]
As someone who has moved the opposite way, heavily using Incus and now checking out Proxmox, what made you go for IncusOS?
My gut feeling is that enterprise sentiment is leaning heavily towards Proxmox, fuelled by a VMware exodus that will only gain speed, and I don't see Incus really meeting the requirements most people have that previously used VMware, but of course Incus is awesome and you can't always pick technologies by what will be "employable" :-)
jvican 3 days ago [-]
Having an OS that versions all my VMs and allows A/B running the actual OS, has a high quality CLI, is built on modern standards, supports declarative files, and it’s simpler than Proxmox.
I don’t really care for enterprise support. Incus hits a sweet spot no other solution does.
abrookewood 3 days ago [-]
I haven't migrated to IncusOS just yet, but I use Incus on a server and have been pretty happy so far.
raphinou 3 days ago [-]
What solution do you use for declarative deployments? Last time I looked there was no default option?
I use my own solution (set of bash scripts) on top of IncusOS support for declarative files.
imrozim 3 days ago [-]
All those tools needed hours to setup this just boots and works.
Zta77 2 days ago [-]
Exactly!
happyopossum 3 days ago [-]
As long as there is software, you cannot shortcut the need for maintenance. Nothing is bug free, and telling people they will never need to upgrade/patch/maintain a system is a well-paved path to compromised systems.
mattbee 3 days ago [-]
This OS doesn't says it's maintenance-free! But it skips a whole load of maintenance you'd need to think about with a traditional base system, because 1) there's almost nothing there, and 2) the upgrade to that base is easy, you just reboot and restart your containers.
Obviously the software you run needs upgrades, but (again, but a layer down) it's based on Docker and probably someone else is maintaining it. So you pull that new container, restart and the OS is just making sure your data lands in the same place with the new container.
If you're happy with all your software running from Docker this seems like a step up from a Debian or Redhat, and it has a lot less bureaucracy than something like CoreOS.
Whether it's _usable_ I'm not sure (especially around storage management) but it's a really clear pitch.
TacticalCoder 3 days ago [-]
> Nothing is bug free, and telling people they will never need to upgrade/patch/maintain a system is a well-paved path to compromised systems.
Of course nothing is. But there's a reason projects like "Talos" do exist: no terminal, no SSH, no package manager (how do we like package managers like NPM lately btw?), read-only filesystem, definitely no systemd, etc.
And then a minimal number of executables.
This does, definitely, reduce the attack surface.
I'm not speaking about this Show HN's project but there are such things as systems both more secure and requiring less maintenance than others.
Throwing in the towel and saying: "nothing can ever be 100% secure so we'll always need to patch so we may as well YOLO by accepting npm packages modified 3 minutes ago" is not the way to go forward either.
cassianoleal 3 days ago [-]
IncusOS is another - read-only root FS, interactions with the system exclusively through the Incus API, no package manager, blue-green OS updates (à la Steam Deck / Home Assistant OS).
Talos on IncusOS is likely a very interesting stack that I intend to play with hopefully in the near future.
First time I heard someone call it blue-green OS updates instead of A/B OS updates.
cassianoleal 3 days ago [-]
Heh fair enough!
Same concept, I guess. I'm a platform engineer / SRE, and blue/green is a more common way of describing that way of deploying applications so I didn't even consider it could have a different name on the OS layer.
c7b 3 days ago [-]
How would you say it compares to nixOS?
abrookewood 3 days ago [-]
They are vastly different. Incus is aimed at providing a minimal, immutable Os for the hosting of VMs & containers. nixOS provides a full linux OS that is reproducible and declarative.
cassianoleal 3 days ago [-]
This exactly. Incus OS is competing on a similar area to Proxmox VE.
8fingerlouie 3 days ago [-]
I've been telling people this for years. Yes, you can self host, but you'll end up with a SLA on your spare time as well as you working hours.
I've long since thrown everything with a user count > 1 out.
nullsanity 3 days ago [-]
[dead]
e12e 3 days ago [-]
Interesting - but how do I patch, upgrade and build my own iso?
The source repository isn't very enlightening?
> The actual repository here hosts the source code for Lightwhale, and is not of any interest for most people.
It appears to be outdated (last commit from 2 years ago), and version 3.0 seems not to be there.
Zta77 1 days ago [-]
Yes, sorry. I don't use the master branch, and Bitbucket doesn't easily let me delete it. But wait, you confirmed that "3.0" isn't there, but somehow missed that "3.0.0" is? =)
Sounds fantastic! But how can I utilize it in hardware? Confused
Zta77 2 hours ago [-]
Me too. What do you mean?
gausswho 3 days ago [-]
What's the recommended way to regularly backup the data used by containers running on Lightwhale?
Zta77 1 days ago [-]
I don't have a recommended or official way. But you could look into using `btrfs send` to send the data filesystem subvolume to a backup host, preferably initiated from the backup host, e.g. by ssh into the Lightwhale server and do the send. And there's always rsync.
One nice thing to keep in mind, is that all data that is ever written in Lightwhale, exists in /mnt/lightwhale-data/lightwhale-state. Data is not entangled with the rest of the system in the rootfs.
The tricky part perhaps is that you should sync all container data to disk prior to taking the backup (or snapshot) to be sure you have a clean state. And the only safe way I can think if, is to stop all containers first. But I think this goes for every Docker Engine.
9dev 3 days ago [-]
I like the idea of something like this for swarm mode clusters; not sure if you’re focused on the home server aspect exclusively, but I’ll be following along.
Kudos to the great project!
Zta77 3 days ago [-]
Thanks!
I'm only announcing it for home servers because that's where most people are willing to try it out. But Lightwhale is already running in production, and it makes an excellent Swarm cluster.
nikolay 3 days ago [-]
This is a Linux distro, not an OS!
cassianoleal 3 days ago [-]
And what is a Linux distro, if not an OS?
nikolay 3 days ago [-]
Calling a custom Linux build a brand-new OS is like a car tuner claiming they built a new car. You didn't build the engine or the chassis; you just tuned it and gave it a custom paint job. It's exactly like a hairdresser - they aren't creating a new human being, they're just cutting, coloring, and styling an existing one. It's a Linux distribution, i.e., a "distro," not a new OS!
cassianoleal 3 days ago [-]
> tuned it and gave it a custom paint job
The way to interact with the OS is significantly different from almost all other Linux distros. There is no shell, no DE. This feels like a lot more than "a custom paint job".
Is Ubuntu an OS? Mint?
Neither have built the package managment system, or the kernel, the DE(s), the utilities (maybe some but certainly not all).
What about CentOS? Or Bazzite? Or even Android?
Is macOS an OS, or "a custom BSD distro"?
And if none of those are OSs, does a Linux-based OS even exist? If not, what's the point of the distinction?
nikolay 3 days ago [-]
Yours is a distro. Period. When you create your own kernel, then you can make bold claims like "I created an OS," when you haven't. Be humble, and you'll be more successful. Linus Torvalds and DHH are the only two arrogant people in tech, but both have accomplished enough to earn the exception. Hubris has no place in tech!
cassianoleal 3 days ago [-]
lol what? I have no distros or OSs. You're delusional and arrogant yourself.
> Linus Torvalds and DHH are the only two arrogant people in tech
Are you feeling ok bud?
nikolay 1 days ago [-]
I'm very well, thank you for your sincere concern, but I can't say the same about you, unfortunately. Keep kidding yourself and use misnomers, but your command of English is poor. You can call it MisnomerOS, and that would be totally fine, but you can't claim "I've built an OS." You've built no OS.
chanux 3 days ago [-]
TBF I went in expecting a novel OS.
nikolay 3 days ago [-]
Me, too! I first thought it was just clickbait, but then I realized it was the author's genuine thought, which is sad. I wonder why the popular Linux distro ranking site DistroWatch [0] is not called "OSWatch"! Well, I don't. The "OS" is CentOS, and NixOS is just branding. NixOS is a huge mod, yet it's still a distro!
This is what Wikipedia says about NixOS:
> NixOS is a Linux distribution built around the Nix package manager.
This is about CentOS:
> CentOS (from Community Enterprise Operating System; also known as CentOS Linux) is a discontinued Linux distribution that provided a free and open-source community-supported computing platform, functionally compatible with its upstream source, Red Hat Enterprise Linux (RHEL).
Where can I get one? Also, what about Busybox-based distros?
nikolay 1 days ago [-]
Use an LLM brain crutch to help yourself in your ego-trip endeavors!
darknavi 3 days ago [-]
I'm a novice in this space I think. I've self-hosted for over a decade and around 2019 I moved over to Unraid, which is generally pretty visual (web portal or configuring and doing maintenance). I find the web portal very easy. How does one interact with your home server OS? I assume it's all via terminal because there are no pictures on the website?
Zta77 2 hours ago [-]
Correct, it's only terminal. Lightwhale provides only the bare necessities for you to deploy what you need. So instead of dictating a UI, you're free to choose what you like, be it Portainer, Dockhand, Komodo or something else.
Lightwhale is perhaps more of an "expert system" compare to consumer products that come preconfigured with a UI. On the other hand, if you want to try a server where you are in full control, Lightwhale it is the easiest way to get a pure Docker server up and running.
dandano 3 days ago [-]
So I’ve just set up my home server with Ubuntu server, installed docker with one line and I’m off to the races. What’s different/ exactly the value prop of this? You mention maintenance, of what exactly? Is your server a slimmed down version to run on less powerful hardware? Genuinely curious as I’m new to setting up a home server so seeing how this would benefit me.
Zta77 29 minutes ago [-]
Hi, thanks for taking interested in my project!
I assumes you've visited the Lightwhale website and at least read the headlines:
"No maintenance headaches.
Just boot and focus on what matters!"
and the first section, including:
"Lightwhale lowers the entry barrier, removes tedious administration tasks, and opens a friction-free path to productivity"
But maybe you dismissed as being empty buzzwords, or didn't quite believe it, so you want an explanation. That's perfectly okay, allow me to elaborate:
So, if you've already gone though the process of partitioning, installing, and configuring a general purpose operating system, and then ran that "one line" that added the docker repository, installed docker, docker-compose, and buildx, and presumably also added yourself to the docker user group, then I'd say you've got a head start compared to a clean, bare-metal box. True, you're now off to the races.
Of course, all this work and time invested in your system comes with a tax called maintenance.
Everything you just installed is live. And now your job is to keep everything safe and sound. Not just the files in $HOME and /etc/, but also /usr/bin/docker, /usr/bin/bash, /lib/libc.so, and even /usr/bin/[. But that's just the rootfs. You also have to groom your boot partition. Even the partition table and MBR. I know, your installer and package manager handles that for you. But nevertheless, all this is writable and either imposes an attack surface, is at risk of daily butter fingers breaking things, or lives on a filesystem that may introduce silent bitrot or on a media that can fail. But that's not the end of it.
If do a good job, your server will live a long and happy life. And eventually, you get to experience something remarkable: It dies. I'm not talking about the hardware suffering a fatal crash, no; I'm taking about Canonical deciding that your version of Ubuntu is now suddenly going into End Of Life. You now have choices to make: Should you upgrade and leave your system at the mercy of the numerous upgrade scripts? Should you reinstall to get a clean slate, repeat everything mentioned above, and try to migrate your data configuration, containers, volumes, etc? Or maybe just leave the OS there dead; afterall, you're only interested in your docker containers and they're unaffected, so that seems like a valid path. Except every time you log in, it's like stepping over a dead body in the doorway, and that doesn't feel quite right.
Of course, if you find these administration tasks fun and interesting that's perfectly okay. And honestly, I can absolutely relate to that, because I've been doing it as a hobby since forever, and I enjoyed myself. Until I reached a point where the installer and maintenance didn't interest me as much as just running the software.
Now, look back at my taglines above, and I hope you can see how Lightwhale can benefit you in setting up a home server:
If you want less tedious administration and maintenance,
but instead like a friction-free path to just boot and run your software,
then Lightwhale is worth a try.
zackify 3 days ago [-]
I do the same thing. Being immutable is supposed to be great for updates. New image version and if there's a problem you can boot back to the last version no problem.
But functionally, like you I find Ubuntu server fine. I run apt update and upgrade a couple times a year and its local only with tailscale access.
I find these immutable OS's really nice on laptop or desktop. The home directory is the only thing that can be written to so the OS is supposed to be more stable and can't break easily
Zta77 23 minutes ago [-]
I do the opposite:
My workstation is where I work, fiddle with things, experiment. It 's a workbench in the context of software development. So I need to be able to modify and configure everything, install things, uninstall them again. A can't use a workbench wrapped in cellophane.
I want my server stable and fixed. I don't care about the OS, I don't want to configure it, update it, and otherwise maintain it. It's just a platform to run the Docker Engine and my containers.
dirtikiti 3 days ago [-]
I dont get it.
Why do I need immutable if I'm just running docker?
Why do I need a specialized Debian variant when I can install docker on Debian or Ubuntu in a couple minutes?
And maintenance happens directly through the package manager, either through the distro maintained repo, or by adding the official docker repos?
This immutable fad needs to go away. So does flatpak and snap.
Linux already does the things these "solutions" are trying to solve.
Users can't update the base system without root, and applications should be installing dependencies in /usr/lib
Zta77 14 minutes ago [-]
Interesting. It's almost as if you followed my link, read the top sections that explain the project features, and the completely forgot everything before posting here.
Indeed, Debian stable with podman/Docker is "immutable enough" for me.
It is also the insurance that I will get help whenever I'm stuck.
Sure it could be smaller ... but when it already runs fine on any hardware, even weird stuff like a BananaPi with a low-end RISC-V processor, then I have a difficult time wanting anything else.
davisphan04 3 days ago [-]
This looks super clean . As a beginner, this is exactly what I need to avoid messing with configs. Definitely gonna try it!
andai 3 days ago [-]
This is relevant to what I have been learning about recently!
I'm getting ready to launch an online game and I'm dealing with "how do I just run my game server on dozens of boxes without dealing with linux stuff".
I don't really have an answer yet (leaning into "just get one really powerful box" lol), but my investigation into the problem so far has been pretty interesting.
You can conceptualize the "my program + the OS" as a single program. It's not a pretty picture. Lots of global mutable state. (Also it randomly modifies itself??)
The whole point of Docker appears to be "I just want to run my program", in the least painful way possible. Immutable Linux extends the "lean in the direction of sanity" idea. (The programming and OS worlds seem to be learning the same lessons, from different angles.)
And then there's "it turns out the OS solves problems I don't have, while creating many new problems", which leads to Unikernels. Fun stuff ;)
In a perfect world, I wouldn't need the OS at all. Docker gives me two Linuxes to worry about! The number of operating systems I want to worry about is zero!
Which brings us to Unikernels! Just ditch the OS! Technically the right answer, except... now I'm a kernel developer? Maybe that's the least bad option, long term.
hnarn 3 days ago [-]
> "how do I just run my game server on dozens of boxes without dealing with linux stuff"
A good first question to ask yourself is why you need to run it on dozens of boxes. You probably don't.
The point of Docker is not "I just want to run my program", the point is to bundle an application with its dependencies. It's one way to distribute applications, and far from the only one (despite what talking to some people might make you think).
As for the last part of your post, none of it is correct. Docker is not a "second linux to worry about" and considering unikernels in your use case is insane.
Terry Davis once said that "an idiot admires complexity, a genius admires simplicity". You say you're "getting ready to launch an online game", then launch it. The best way to do that is the simplest way, which in my opinion is running it as a systemd service on _one_ Linux VM. When that actually creates problems for you, solve those problems, and only those problems.
andai 2 days ago [-]
Yeah, I already did that, the current problem is "now I need ten thousand times more players so it pays the bills."
Well, that's several problems, of course :) but one of them is latency and capacity (i.e. servers).
My actual dependency is whatever it takes to get data in and out of a network card.
wrxd 3 days ago [-]
Is the installation only imperative via the docker cli tool or do you support something more declarative like Docker compose?
Zta77 2 days ago [-]
Lightwhale comes with docker compose too! And docker buildx and git for good measure. This means you can clone your git repo, and docker compose up your stack immediately.
visualphoenix 3 days ago [-]
Very cool! I’ve been building something similar with a k8 focus for home serving as well! Excited to check it out.
This feels not unlike talos linux, but for single instances over k8s containers. Pretty neat.
Zta77 3 days ago [-]
Yes, it is a single Docker Engine instance. But Lightwhale fully supports Docker Swarm, so you can easily build a lightweight cluster as well.
YorickPeterse 3 days ago [-]
So how is this different from Fedora CoreOS or bootc/RHEL image mode?
micw 3 days ago [-]
I wish there was something like this or talos or coreos but more generic:
- immutable
- a/b boot
- declarative (like talos)
But with choice of workload, like docker, k8s, qemu
ugh123 3 days ago [-]
Checkout IncusOS which focuses on Linux containers
ggm 3 days ago [-]
If this was built using zfs, it would have zvols and metadata in the fs for persistence. And the states would be perhaps more portable at a cost of .. zfs.
Not a huge criticism, life is about choices.
Zta77 2 days ago [-]
Hello!
I went with Btrfs for persistence, and automated some things around that. For example, if you give Lightwhale two magic disks, it will automatically create a Btrfs RAID1. During persistence setup it will also create a few default subvolumes to fully support snapshots and rollback of the entire data filesystem. (Remember, the rootfs of the OS is still immutable, and is never part of the data filesystem). Besides snapshots and RAID, Btrfs has checksums which I think is a must.
I've heard lots of nice things about zfs, and I know it does snapshots and checksum too. But also that it eats huge amounts of memory for breakfast. I may not be updated on this, but I faintly remember some licensing issues, that potentially could cause problem if zfs was baked into an ISO like Lightwhale. Those are the main reasons why I'm reluctant to zfs and chose Btrfs.
But you're absolutely right, I have taken some radical choices with this dist. But most are deliberate and by design =)
walrus01 3 days ago [-]
If I had a firm requirement to have only one physical piece of hardware home server on bare metal to run further containerized things on, it would be running proxmox, because that grants the ability to run further QEMU, KVM virtualized things, and then to install docker containers inside of any KVM VMs. Even to use QEMU to fully emulate other CPU architectures if necessary.
Or if not proxmox, without a http GUI, just a boring debian stable x86-64 system to manually install QEMU and virt-tools, virsh toolset on to
run QEMU/KVM things on with purely CLI management.
This is an interesting general concept but being limited to only running docker containers is a huge constraint.
Zta77 2 days ago [-]
Oh, but it's not a constraint. And it's certainly not a general concept. It's the very purpose of Lightwhale.
Lightwhale does one thing and it does it great: It lets you run Docker containers effortlessly. And that is it. If that's not what you want, you honestly should run something else — no hard feelings =)
3 days ago [-]
wutwutwat 3 days ago [-]
Am I missing something, I don't see a single screenshot showing what you're asking people to install
Secondly, I dont feel there's much to see, really. It's just classic Linux text mode, although I do find the GRUB splash and getty login screens quite cool. Instead, I focused on explaining what it does and how it makes your life better.
can't imagine a world in which I'd download a little known distro to put on my home network and use as a server. also, doesn't fedora already have something like this already?
tclancy 3 days ago [-]
Game’s truly gone. I remember when all we did was try to find the most obscure indie band of a Linux distro, form emotional attachments and then argue their merits.
Zta77 2 days ago [-]
...and then proceed and do the same again, only with a window manager =)
edoceo 3 days ago [-]
Or use debian slim or Alpine for just enough Linux to run dockers.
Zta77 1 days ago [-]
I think you're missing the point.
Of course you can choose a general purpose Linux dist. But you'll still have to go through the extra work of partitioning the disk, installing the system, selecting packages, possibly follow some other guide to install Docker Engine, Docker Compose, Docker Buildx, and doing that thing with the docker group. At that point you'll pretty much have what Lightwhale provides out of the box. Except you'll be left with a system that isn't immutable, and where system and data is entangled on one filesystem. And if that's your thing, you should do definitely that. But...
If you just want to run your containers, then Lightwhale is best in class.
tamimio 3 days ago [-]
I believe for anything home server (or even production), proxmox got you covered, it’s mature, stable, has strong community, and at the end of the day it’s still debian so you can mod it however you like. You can have containers, vms, firewalls, hdd zfs pools, backups, and more. And you can even use something like community scripts for easier installation, although always read the script before you install anything. I have also been playing with BastilleBSD too but I don’t think it’s there yet.
Zta77 2 days ago [-]
Proxmox is great. I use it for experimenting with Lightwhale swarm clusters locally; I'm currently running 8 Lightwhale worker nodes with 512MB RAM each and no disk, and it's super fast and fits in my pocket.
I don't consider Lightwhale as an alternative to Proxmox. In fact, how do you even run a Docker container in Proxmox? Without booting Lightwhale in a VM first, I mean? ;)
petterroea 3 days ago [-]
Even if i don't see a personal need for it it's a really cool project! I sent it to a friend who is in the "wants to run their own servers at home but never finds time to tinker" stage
ricktdotorg 3 days ago [-]
if this is Cloud Run for my home lab, i am SO in.
first read looks good, excited to try.
Arch-TK 3 days ago [-]
The best way I have found to make something low/no maintenance is to keep it as simple as humanly possible.
And I don't think you can get there via this route. But good luck anyway, I would love to be proven wrong.
Zta77 3 days ago [-]
Hello. There's a balance between "simple as humanly possible" and "usable", where "usable" specifically means "run docker containers". I feel I've hit a sweet-spot, but I'd like to hear where you think I failed or can improve.
logic-designer 3 days ago [-]
did you say anywhere what package manager it uses (couldnt find that info on the website)
- Flatcar Container Linux: An open-source, immutable OS designed for automatic updates and large-scale container deployments.
- Fedora CoreOS: A, secure, automatically updating operating system designed for running containerized applications, succeeding the original CoreOS.
- Talos Linux: A modern, immutable, security-focused OS dedicated entirely to Kubernetes.
- IncusOS: an immutable OS solely designed around safely and reliably running Incus.
I think you need to more clearly explain how this is different. Again, congrats on the launch though.
Migrated from Proxmox and manage all my VMs. Heavily use coding assistants to automatically set things up through the IncusOS CLI, translate Docker-Compose images to Incus, write bash scripts to automate launching new containers to use `--dangerously-skip-permissions` without fear of repercussions, etc.
What I love the most about it is that it's possible to manage IncusOS with declarative files, so you always have visibility into networking setups, resource configuration, etc.
Highly recommend checking IncusOS out if you have similar use cases!
My gut feeling is that enterprise sentiment is leaning heavily towards Proxmox, fuelled by a VMware exodus that will only gain speed, and I don't see Incus really meeting the requirements most people have that previously used VMware, but of course Incus is awesome and you can't always pick technologies by what will be "employable" :-)
I don’t really care for enterprise support. Incus hits a sweet spot no other solution does.
Obviously the software you run needs upgrades, but (again, but a layer down) it's based on Docker and probably someone else is maintaining it. So you pull that new container, restart and the OS is just making sure your data lands in the same place with the new container.
If you're happy with all your software running from Docker this seems like a step up from a Debian or Redhat, and it has a lot less bureaucracy than something like CoreOS.
Whether it's _usable_ I'm not sure (especially around storage management) but it's a really clear pitch.
Of course nothing is. But there's a reason projects like "Talos" do exist: no terminal, no SSH, no package manager (how do we like package managers like NPM lately btw?), read-only filesystem, definitely no systemd, etc.
And then a minimal number of executables.
This does, definitely, reduce the attack surface.
I'm not speaking about this Show HN's project but there are such things as systems both more secure and requiring less maintenance than others.
Throwing in the towel and saying: "nothing can ever be 100% secure so we'll always need to patch so we may as well YOLO by accepting npm packages modified 3 minutes ago" is not the way to go forward either.
Talos on IncusOS is likely a very interesting stack that I intend to play with hopefully in the near future.
https://linuxcontainers.org/incus-os/docs/main/
First time I heard someone call it blue-green OS updates instead of A/B OS updates.
Same concept, I guess. I'm a platform engineer / SRE, and blue/green is a more common way of describing that way of deploying applications so I didn't even consider it could have a different name on the OS layer.
I've long since thrown everything with a user count > 1 out.
The source repository isn't very enlightening?
> The actual repository here hosts the source code for Lightwhale, and is not of any interest for most people.
> https://bitbucket.org/asklandd/lightwhale/src/master/
https://bitbucket.org/asklandd/lightwhale/src/3.0.0/docs/BUI...
One nice thing to keep in mind, is that all data that is ever written in Lightwhale, exists in /mnt/lightwhale-data/lightwhale-state. Data is not entangled with the rest of the system in the rootfs.
The tricky part perhaps is that you should sync all container data to disk prior to taking the backup (or snapshot) to be sure you have a clean state. And the only safe way I can think if, is to stop all containers first. But I think this goes for every Docker Engine.
Kudos to the great project!
The way to interact with the OS is significantly different from almost all other Linux distros. There is no shell, no DE. This feels like a lot more than "a custom paint job".
Is Ubuntu an OS? Mint?
Neither have built the package managment system, or the kernel, the DE(s), the utilities (maybe some but certainly not all).
What about CentOS? Or Bazzite? Or even Android?
Is macOS an OS, or "a custom BSD distro"?
And if none of those are OSs, does a Linux-based OS even exist? If not, what's the point of the distinction?
> Linus Torvalds and DHH are the only two arrogant people in tech
Are you feeling ok bud?
This is what Wikipedia says about NixOS:
> NixOS is a Linux distribution built around the Nix package manager.
This is about CentOS:
> CentOS (from Community Enterprise Operating System; also known as CentOS Linux) is a discontinued Linux distribution that provided a free and open-source community-supported computing platform, functionally compatible with its upstream source, Red Hat Enterprise Linux (RHEL).
[0]: https://distrowatch.com/
[0]: https://www.gnu.org/gnu/linux-and-gnu.html
Lightwhale is perhaps more of an "expert system" compare to consumer products that come preconfigured with a UI. On the other hand, if you want to try a server where you are in full control, Lightwhale it is the easiest way to get a pure Docker server up and running.
I assumes you've visited the Lightwhale website and at least read the headlines:
"No maintenance headaches. Just boot and focus on what matters!"
and the first section, including:
"Lightwhale lowers the entry barrier, removes tedious administration tasks, and opens a friction-free path to productivity"
But maybe you dismissed as being empty buzzwords, or didn't quite believe it, so you want an explanation. That's perfectly okay, allow me to elaborate:
So, if you've already gone though the process of partitioning, installing, and configuring a general purpose operating system, and then ran that "one line" that added the docker repository, installed docker, docker-compose, and buildx, and presumably also added yourself to the docker user group, then I'd say you've got a head start compared to a clean, bare-metal box. True, you're now off to the races.
Of course, all this work and time invested in your system comes with a tax called maintenance.
Everything you just installed is live. And now your job is to keep everything safe and sound. Not just the files in $HOME and /etc/, but also /usr/bin/docker, /usr/bin/bash, /lib/libc.so, and even /usr/bin/[. But that's just the rootfs. You also have to groom your boot partition. Even the partition table and MBR. I know, your installer and package manager handles that for you. But nevertheless, all this is writable and either imposes an attack surface, is at risk of daily butter fingers breaking things, or lives on a filesystem that may introduce silent bitrot or on a media that can fail. But that's not the end of it. If do a good job, your server will live a long and happy life. And eventually, you get to experience something remarkable: It dies. I'm not talking about the hardware suffering a fatal crash, no; I'm taking about Canonical deciding that your version of Ubuntu is now suddenly going into End Of Life. You now have choices to make: Should you upgrade and leave your system at the mercy of the numerous upgrade scripts? Should you reinstall to get a clean slate, repeat everything mentioned above, and try to migrate your data configuration, containers, volumes, etc? Or maybe just leave the OS there dead; afterall, you're only interested in your docker containers and they're unaffected, so that seems like a valid path. Except every time you log in, it's like stepping over a dead body in the doorway, and that doesn't feel quite right.
Of course, if you find these administration tasks fun and interesting that's perfectly okay. And honestly, I can absolutely relate to that, because I've been doing it as a hobby since forever, and I enjoyed myself. Until I reached a point where the installer and maintenance didn't interest me as much as just running the software.
Now, look back at my taglines above, and I hope you can see how Lightwhale can benefit you in setting up a home server:
If you want less tedious administration and maintenance, but instead like a friction-free path to just boot and run your software, then Lightwhale is worth a try.
But functionally, like you I find Ubuntu server fine. I run apt update and upgrade a couple times a year and its local only with tailscale access.
I find these immutable OS's really nice on laptop or desktop. The home directory is the only thing that can be written to so the OS is supposed to be more stable and can't break easily
My workstation is where I work, fiddle with things, experiment. It 's a workbench in the context of software development. So I need to be able to modify and configure everything, install things, uninstall them again. A can't use a workbench wrapped in cellophane.
I want my server stable and fixed. I don't care about the OS, I don't want to configure it, update it, and otherwise maintain it. It's just a platform to run the Docker Engine and my containers.
Why do I need immutable if I'm just running docker?
Why do I need a specialized Debian variant when I can install docker on Debian or Ubuntu in a couple minutes?
And maintenance happens directly through the package manager, either through the distro maintained repo, or by adding the official docker repos?
This immutable fad needs to go away. So does flatpak and snap.
Linux already does the things these "solutions" are trying to solve.
Users can't update the base system without root, and applications should be installing dependencies in /usr/lib
I did a different explanation here that is easier to relate to, perhaps: https://news.ycombinator.com/item?id=47932066
It is also the insurance that I will get help whenever I'm stuck.
Sure it could be smaller ... but when it already runs fine on any hardware, even weird stuff like a BananaPi with a low-end RISC-V processor, then I have a difficult time wanting anything else.
I'm getting ready to launch an online game and I'm dealing with "how do I just run my game server on dozens of boxes without dealing with linux stuff".
I don't really have an answer yet (leaning into "just get one really powerful box" lol), but my investigation into the problem so far has been pretty interesting.
You can conceptualize the "my program + the OS" as a single program. It's not a pretty picture. Lots of global mutable state. (Also it randomly modifies itself??)
The whole point of Docker appears to be "I just want to run my program", in the least painful way possible. Immutable Linux extends the "lean in the direction of sanity" idea. (The programming and OS worlds seem to be learning the same lessons, from different angles.)
And then there's "it turns out the OS solves problems I don't have, while creating many new problems", which leads to Unikernels. Fun stuff ;)
In a perfect world, I wouldn't need the OS at all. Docker gives me two Linuxes to worry about! The number of operating systems I want to worry about is zero!
Which brings us to Unikernels! Just ditch the OS! Technically the right answer, except... now I'm a kernel developer? Maybe that's the least bad option, long term.
A good first question to ask yourself is why you need to run it on dozens of boxes. You probably don't.
The point of Docker is not "I just want to run my program", the point is to bundle an application with its dependencies. It's one way to distribute applications, and far from the only one (despite what talking to some people might make you think).
As for the last part of your post, none of it is correct. Docker is not a "second linux to worry about" and considering unikernels in your use case is insane.
Terry Davis once said that "an idiot admires complexity, a genius admires simplicity". You say you're "getting ready to launch an online game", then launch it. The best way to do that is the simplest way, which in my opinion is running it as a systemd service on _one_ Linux VM. When that actually creates problems for you, solve those problems, and only those problems.
Well, that's several problems, of course :) but one of them is latency and capacity (i.e. servers).
My actual dependency is whatever it takes to get data in and out of a network card.
Not a huge criticism, life is about choices.
I went with Btrfs for persistence, and automated some things around that. For example, if you give Lightwhale two magic disks, it will automatically create a Btrfs RAID1. During persistence setup it will also create a few default subvolumes to fully support snapshots and rollback of the entire data filesystem. (Remember, the rootfs of the OS is still immutable, and is never part of the data filesystem). Besides snapshots and RAID, Btrfs has checksums which I think is a must.
I've heard lots of nice things about zfs, and I know it does snapshots and checksum too. But also that it eats huge amounts of memory for breakfast. I may not be updated on this, but I faintly remember some licensing issues, that potentially could cause problem if zfs was baked into an ISO like Lightwhale. Those are the main reasons why I'm reluctant to zfs and chose Btrfs.
But you're absolutely right, I have taken some radical choices with this dist. But most are deliberate and by design =)
Or if not proxmox, without a http GUI, just a boring debian stable x86-64 system to manually install QEMU and virt-tools, virsh toolset on to run QEMU/KVM things on with purely CLI management.
This is an interesting general concept but being limited to only running docker containers is a huge constraint.
Lightwhale does one thing and it does it great: It lets you run Docker containers effortlessly. And that is it. If that's not what you want, you honestly should run something else — no hard feelings =)
So first of all, you don't install it; you just boot it. And because Lightwhale doesn't write anything to disk unless you explicitly tell it to, (https://lightwhale.asklandd.dk/#persistence-enable), then you're safe to boot it any time and check it out. You can use a VM to be sure: https://lightwhale.asklandd.dk/#faq-virtualiuzed
Secondly, I dont feel there's much to see, really. It's just classic Linux text mode, although I do find the GRUB splash and getty login screens quite cool. Instead, I focused on explaining what it does and how it makes your life better.
But since you asked for screenshots, here you go:
https://lightwhale.asklandd.dk/screenshots/boot.png https://lightwhale.asklandd.dk/screenshots/login.png
Enjoy!
Of course you can choose a general purpose Linux dist. But you'll still have to go through the extra work of partitioning the disk, installing the system, selecting packages, possibly follow some other guide to install Docker Engine, Docker Compose, Docker Buildx, and doing that thing with the docker group. At that point you'll pretty much have what Lightwhale provides out of the box. Except you'll be left with a system that isn't immutable, and where system and data is entangled on one filesystem. And if that's your thing, you should do definitely that. But...
If you just want to run your containers, then Lightwhale is best in class.
I don't consider Lightwhale as an alternative to Proxmox. In fact, how do you even run a Docker container in Proxmox? Without booting Lightwhale in a VM first, I mean? ;)
first read looks good, excited to try.
And I don't think you can get there via this route. But good luck anyway, I would love to be proven wrong.
> Can you please add wget, nano, $my_fav_app_omg_i_love_it to the root filesystem?
> No, not likely.
I am guessing the way to use software not already in the image is to use `docker run`.