Nice! Reminds me of Galos: https://github.com/ascension-association/galos
Incus-OS: Immutable Linux OS to run Incus as a hypervisor
51–60 of 71 posts
Re: Incus-OS: Immutable Linux OS to run Incus as a hypervisor
#52Earlier quoted context omitted.
I was hoping for easy backup via zfs send as well, but turns out it’s not so easy atm. IncusOS does not give you shell access, you have to figure out IncusOS ways to do things via their CLI/API. I haven’t found an easy way to do incremental backup of the whole system yet. You can backup individual instances/volumes via incus export (which seems to use zfs send under the hood), but not the whole thing. I have mixed fe…
Check out SmartOS, it's illumos/solaris based but I think you'll find it is a nice middle ground. Not as abstracted, nice tooling that makes common tasks simple but not so opinionated you have to de-abstract things to get under the hood. Not painless but what is?
Sorry to say but that is bad advice. SmartOS is great and it was cool tech, but it is not Linux and it doesn't act like Linux is certain scenarios.
My favourite example is OOM .. Linux will kill your docker container. SmartOS locks it up and makes it super hard to see understand why it failed.
I like smartos but I have painful memories from about a decade ago.
Incus however is what in use now in Linux.
Re: Incus-OS: Immutable Linux OS to run Incus as a hypervisor
#53Incus is very nice and super featured, but suffers from a few issues, namely unintuitive/hard onboarding and bad defaults, which makes giving access to people annoying, as it requires teaching them first and that they can't just make a vm with a few clicks immediately, limited authentication and user control options, like if no external auth users must exist on underlying system, and with limited but very strict auth…
Sorry what? Lxd is NOT incus upstream. Incus was forked from lxd specifically to allow divergence and the licenses mean changes rather flow in the other direction. Not that canonical considers incus “upstream” - they’re just divergent forks at this point.
Re: Incus-OS: Immutable Linux OS to run Incus as a hypervisor
#54Interesting. I recommend Incus over other hypervisor-oriented OS distributions (Proxmox, etc.), for many reasons, but one minor reason is that you can install it on Debian or Arch or whatever Linux you like. It's a comprehensive management layer for VMs and Linux containers, with good CLI, web UI, cloning/moving/copying/migrating etc., but... why does that need to be an OS?
However, I'm confident that if that is what you want, this is probably fantastic — Incus, including the old LXD (which was mainly built by the same core developers, until Canonical behaved in ways they didn't like, and they hard-forked LXD to create Incus) has been one of my favorite open-source projects for several years.
Fantastic software, steady stream of reliable releases, helpful community... Incus is great.
Re: Incus-OS: Immutable Linux OS to run Incus as a hypervisor
#55Incus is very nice and super featured, but suffers from a few issues, namely unintuitive/hard onboarding and bad defaults, which makes giving access to people annoying, as it requires teaching them first and that they can't just make a vm with a few clicks immediately, limited authentication and user control options, like if no external auth users must exist on underlying system, and with limited but very strict auth…
Sorry what? Lxd is NOT incus upstream. Incus was forked from lxd specifically to allow divergence and the licenses mean changes rather flow in the other direction. Not that canonical considers incus “upstream” - they’re just divergent forks at this point.
But unfortunately it pretty much is, at least according to the maintainers themselves.
They try to not diverge unless "necessary", and for most parts it's not necessary to them.
Re: Incus-OS: Immutable Linux OS to run Incus as a hypervisor
#56Earlier quoted context omitted.
Sorry what? Lxd is NOT incus upstream. Incus was forked from lxd specifically to allow divergence and the licenses mean changes rather flow in the other direction. Not that canonical considers incus “upstream” - they’re just divergent forks at this point.
But unfortunately it pretty much is, at least according to the maintainers themselves. They try to not diverge unless "necessary", and for most parts it's not necessary to them.
Can you substantiate this?
The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other
Re: Incus-OS: Immutable Linux OS to run Incus as a hypervisor
#57Earlier quoted context omitted.
But unfortunately it pretty much is, at least according to the maintainers themselves. They try to not diverge unless "necessary", and for most parts it's not necessary to them.
Can you substantiate this? The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other
https://github.com/zabbly/incus/issues/89#issuecomment-30764...
I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending.
But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects.
And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes.
Re: Incus-OS: Immutable Linux OS to run Incus as a hypervisor
#58Earlier quoted context omitted.
Can you substantiate this? The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other
https://github.com/zabbly/incus/issues/89#issuecomment-30764... I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending. But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects. And I swear I had a similar experience with regards to some other incus issues where there was a similar response a…
> https://github.com/zabbly/incus/issues/89#issuecomment-30764...
> I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending.
This one is fair since Incus and Zabbly have had no desire to reimplement a web UI, they've instead opted to leave that to the community resulting in LXConsole for example.
Zabbly, for additional context, is Stephane Graber's company that he set up as a consultant service for Linux and Linux Container (both in terms of the Linux Container organization and the LXC project)
As a whole, the project has left the choice of web interface up to the user: https://discuss.linuxcontainers.org/t/incus-6-7-has-been-rel...
> But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects.
This is getting dangerously close to a mischaracterization of events surrounding the Linux Containers and Canonical split.
See: https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-unde... in addition to: https://linuxcontainers.org/incus/announcement/
EDIT: I read this part to suggest that former LXD team members that are now on the Incus team potentially have the same mindset, if this is wrong, please correct me.
> And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes.
So far from my two years of interaction (both as a lurker and commenter) on the forums and purveyor on the issue tracker, I've yet to see anything that resembles treating Canonical LXD as any form of upstream especially since the split.
Re: Incus-OS: Immutable Linux OS to run Incus as a hypervisor
#59Earlier quoted context omitted.
Can you substantiate this? The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other
https://github.com/zabbly/incus/issues/89#issuecomment-30764... I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending. But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects. And I swear I had a similar experience with regards to some other incus issues where there was a similar response a…
It's very very different between the UI and Incus itself :)
The Incus teams are low level system engineers who develop in Go or C. The UI is a pile of typescript which none of us really want to understand/touch any more than strictly needed.
The Incus UI is a soft fork (really just a small overlay) on top of the LXD UI to adjust for the API differences between LXD and Incus and for fixing the few big gripes we had with the LXD UI. Because both projects are under the same license, we can actually just follow what happen in LXD UI and pull in code from it.
Incus is a very different beast. The whole reason the project had to be started is because of Canonical's series of changes which eventually led to a re-licensing of LXD to AGPLv3. With Incus remaining Apache 2.0, none of us can even look at the LXD code without risking being "tainted". We cannot import any code from LXD since that license change and we never have. However LXD has no problem with importing Apache 2.0 code into an AGPLv3 codebase, which they have quite actively been doing.
In short Incus is a hard fork of LXD, we don't look at any LXD code or even at their issues or release announcements (mostly because it's not useful for those two). That means that everything that happened in Incus since December 2023 has been completely independent of LXD.
The Incus UI is a soft fork of the LXD UI, it's rebased every time they push a new version out and our goal is to keep the delta as small as possible as it's something we want to spend as little time on as we possibly can. It's also why we always package it as "incus-ui-canonical" to make it very clear as to what it is.
There are also other UIs out there that could be used, sadly last I checked none came close to the feature coverage of the LXD UI or they had dependency on external components (database, active web servers, ...) whereas what we want is a UI that's just a static javascript bundle which then hits our REST API like any other client.
Re: Incus-OS: Immutable Linux OS to run Incus as a hypervisor
#60Earlier quoted context omitted.
Check out SmartOS, it's illumos/solaris based but I think you'll find it is a nice middle ground. Not as abstracted, nice tooling that makes common tasks simple but not so opinionated you have to de-abstract things to get under the hood. Not painless but what is?
Sorry to say but that is bad advice. SmartOS is great and it was cool tech, but it is not Linux and it doesn't act like Linux is certain scenarios. My favourite example is OOM .. Linux will kill your docker container. SmartOS locks it up and makes it super hard to see understand why it failed. I like smartos but I have painful memories from about a decade ago. Incus however is what in use now in Linux.
Ah well different tools for different folks, sorry to hear you couldn't get it going.