Looking for something to do this weekend? How about trying out the all new Incus 0.6!
This Incus release is quite the feature packed one! It comes with an all new storage driver to allow a shared disk to be used for storage across a cluster. On top of that we also have support for backing up and restoring storage buckets, control over accessing of shared block devices, the ability to list images across all projects, a number of OVN improvements and more!
The full announcement and changelog can be found here.
And for those who prefer videos, here’s the release overview video:
You can take the latest release of Incus up for a spin through our online demo service at: https://linuxcontainers.org/incus/try-it/
And as always, my company is offering commercial support on Incus, ranging from by-the-hour support contracts to one-off services on things like initial migration from LXD, review of your deployment to squeeze the most out of Incus or even feature sponsorship. You’ll find all details of that here: https://zabbly.com/incus
Donations towards my work on this and other open source projects is also always appreciated, you can find me on Github Sponsors, Patreon and Ko-fi.
Enjoy!
Github
Twitter
LinkedIn
Mastodon
RSS feed
Good to here that, seems works on going steadily, appreciate that, sir.
And also good to know that most install method listed in docs are NOT with snap, which is fantastic finally…
Considering that incus-to-lxc are kind doing something somehow similar (not exactly same though) like Rocky-to-CentOS, I really wish that Rocky 8 or 9 can consider providing official support to incus, that could be a win-win situation, just like Debian.
Rocky has been looking at Incus for a little while now, so I’m hopeful we’ll have a solution for the RHEL derivative folks soon.
I was very hopeful when I heard that now there was an alternative (Incus) to the Ubuntu lxd social engineering strategy. However, I found the following still in the make file:
.PHONY: woke-install
woke-install:
@type woke >/dev/null 2>&1 || \
{ echo “Installing \”woke\” snap… \n”; sudo snap install woke; }
.PHONY: doc-woke
doc-woke: woke-install
woke *.md **/*.md -c https://github.com/canonical/Inclusive-naming/raw/main/config.yml
May I ask, how committed is this project to catering to a woke ideology. Is this a residue from where it came from or something that this project is committed to continue. Your response would be appreciated.
I don’t particularly care about the tool used to perform that check and I don’t think that “woke” was necessarily the best choice of project name for such a tool. I do however agree with the check it performs here, terminology like blacklist/whitelist, master/slave and the like have long had good, if anything clearer alternatives that should be used in their stead (allowlist/denylist and primary/secondary in this case).
Thank you for the response. In essence, if I understood you correctly, you do agree with the ideology that we must check for words that woke culture finds offensive, accepting that we must self-censor and accommodate such ideology. And that the project will actively continue to use tools to enforce the use of accepted words.
If I misunderstood you, please, correct me. Otherwise, I take the answer to my question is in the affirmative, the project sympathies with woke culture and it will find necessary to make an effort to enforce it by way of tooling that alerts and selects other alternative words in order to accommodate the idea.
My intention was to find out for sure and I do appreciate your response, even as disappointing as I find it.