Starting with the use of the term of “next-generation”, the text is – I am sorry for the crude words – unappealing, and boring. Too much explaining without direct claims on where Incus trumps Docker or how it can be a good alternative or addition to regular VMs. Interesting admonitions, visual clues or imagery – informational or otherwise – are also lacking.
The github page is similarly plain and mundane.
I know there other projects under the umbrella of LinuxContainers but Incus is probably the most affected all in all.
I again started to heavily use Incus and I am a bit afraid to see that the facade of the project is unprioritized this harshly. Its popularity I believe is probably somewhat hindered as a result. In my opinion a project this great should exude more confidence and be more appealing.
This issue of course expands to other directions as well but I didn’t want to overreach in my feedback and, well, this is not a bad point to improve on as the first google hit for incus is this introduction page.
I’m not aware of anyone working on this. Marketing is usually very very low on any of the maintainers priority list as this is an open source project and not a business
Anyway, all the website content is on Github, so pull requests are welcome.
I hate marketing probably just as much as anyone else here , nonetheless aesthetics is one of the 3 pillars of design and introduction/onboarding as well shall be a pleasant surface/experience. So, don’t be surprised if I attempt to improve on this – but not guarantees just yet.
But others (like @stappers) seem have some things on their minds as well.
The project does not clearly state its goals anywhere (that I can find). I believe it should. I do not think we can state them. I would love to see this coming from the core team.
Found the following on the web:
1. The announcement post (the most explicit statement)
[linuxcontainers.org/incus/announcement/](http://linuxcontainers.org/incus/announcement/) ([https://linuxcontainers.org/incus/announcement/](https://linuxcontainers.org/incus/announcement/)) (Aug 7, 2023) says it outright:
│ "The goal of Incus is to provide a fully community led alternative to Canonical's LXD as well as providing an opportunity to
│ correct some mistakes that were made during LXD's development which couldn't be corrected without breaking backward
│ compatibility."
So its two stated goals are: (a) community leadership/governance, and (b) the freedom to make breaking fixes LXD couldn't. It
also notes there was "no clearly defined roadmap" at launch — Incus would track LXD and diverge over time.
2. The project intro page
[linuxcontainers.org/incus/](http://linuxcontainers.org/incus/) ([https://linuxcontainers.org/incus/](https://linuxcontainers.org/incus/)) frames the product goals: a "next-generation system container,
application container, and virtual machine manager" offering a public-cloud-like experience — mixing containers and VMs over
shared storage and networking, image-based, scaling "from containers on your laptop to clusters of thousands of compute nodes,"
secure by design, intuitive, event-based, with one REST API for local and remote use.
3. The GitHub README
[github.com/lxc/incus](http://github.com/lxc/incus) ([https://github.com/lxc/incus/blob/main/README.md](https://github.com/lxc/incus/blob/main/README.md)) restates the identity goals: a "modern, secure and
powerful" manager that "scales from one instance on a single machine to a cluster in a full data center rack," and — on the
governance side — "a true open source community project, free of any CLA," Apache 2.0, maintained by the original LXD team.
Incus is a next-generation manager for system containers, application containers, and virtual machines.
Incus allows you to manage resources similar to what you get from a public cloud. Depending on your requirements, you can create virtual machines, system containers (which are light-weight virtual machines) and also application containers (such as from Docker).
Incus uses images (archives of Linux runtimes) and provides such images for a wide number of Linux distributions. It provides flexibility and scalability for various use cases, with support for different storage backends and network types and the option to install on hardware ranging from an individual laptop or cloud instance to a full server rack.
When using Incus, you can manage your instances (containers and virtual machines) with a simple command line tool, directly through the REST API or by using third-party tools and integrations. Incus implements a single REST API for both local and remote management.
The Incus project was created by Aleksa Sarai as a community-driven alternative to Canonical’s LXD.
Today, it’s led and maintained by many of the same people that once created LXD.
It’s difficult to explain these terms in an introductory level, there is no official way, and the de facto way is what many people tend to be using.
Virtual machines require hardware acceleration and tend to use KVM+QEMU. Most cloud companies that offer VMs, are in this group. Incus provides such virtual machines. With virtual machines, each one of them will boot a separate kernel, and then run the runtime.
QEMU is big in terms of size and complexity. VMs can avoid QEMU and still perform a decent job. Those are the microVMs, an example of which, is Firecracker. Incus does not currently provide such micro virtual machines, there is no hard no, but if such support is to appear, it should offer the feature set we are accustomed with virtual machines.
On the other hand, with system containers, there is no need for such hardware acceleration. System containers use the Linux kernel facilities to perform the isolation of the container from the rest of the system. And they reuse the Linux kernel of the host. System containers appear to the end-user as virtual machines, they work like virtual machines, but they save so many resources because they do not boot a separate kernel. System containers are light-weight virtual machines. From the point of view of the host system, a system container is a tree of processes, that can be swapped in and out from memory and be observed very well.
An image for a container is just the Linux runtime (root filesystem, rootfs). Whereas, a virtual machine image contains both the operating system kernel and the runtime.
Incus adoption is growing rapidly. We have more introductory users who need a definition ‘in simple terms’. I believe defining something in simple terms invites leniency regarding vocabulary.
# About Incus
In simply terms ...
Here is a more detailed explanation:
- ...
- ...
Introduction is relevant for all audiences, the proper application of “progressive disclosure”, is very useful to apply here too.
Some thought-out mermaid diagrams with some post-processing could convey high-level information effectively too, we could develop some in a few iterations.
On a different note, I dislike the term “next-generation”, it seems to me like an out-of-place marketing term – which in style is inconsistent with the rest of the identity of the project. What defines previous or next generation here? I don’t see this kind of distinction useful, as even older solution are often more applicable then newer ones and each has its strenghts and weaknesses.
And in my opinion, the whole page is to register as an introduction, not just the introduction section embedded in it.
Trying my hand at rewriting the introduction blurb:
Incus is a container and virtual machine management engine that can run on your laptop or cloud instance to full server racks.
It can run a variety of instance types, whether they be system containers in the vein of systemd-nspawn, application containers using the same OCI standard as used in Docker or Podman, or virtual machines backed by Qemu and KVM. All of which can be managed with a simple command line tool, directly through the engine’s REST API, or via third-party tools and integrations.
It provides a user experience similar to that of a public cloud. With it, you can easily mix and match both containers and virtual machines, sharing the same underlying storage, network, and configuration interfaces.
The Incus project was created by Aleksa Sarai as a community driven alternative to Canonical’s LXD. Today, it’s led and maintained by many of the same people that once created LXD.
Its not my place to say, but I think you would benefit from agreeing to a target audience. To better refine the homepage;
Edu kids
18-30, getting started with Wordpress/Node/Ruby/Ollama/Llama.cpp/Vlllm/AI
10+ senior opts teams replacing legacy infra like vmware
Grandparents (old edu)
Some other variation (ETC)
Who you choose to target with the homepage dictates how you should write it.
The fact this thread has minor debate about the definition of a VM is indicative of a technical mindset.
As a technical person if you dont roll your eyes at least twice before getting to the API docs, did you even consider the product? (“To technical” == “1 person”, “To marketing” == “Cost a pretty penny”)
Depending on your audience “a computer inside a computer” is by far the simplest explanation of what Incus/LXD/LXC does I’ve found, a bind-mount / QEMU/ YOUR FAVE FEATURE is just some mad technical detail.
)
, nonetheless aesthetics is one of the 3 pillars of design and introduction/onboarding as well shall be a pleasant surface/experience. So, don’t be surprised if I attempt to improve on this – but not guarantees just yet.