
Packaging LXD for Arch Linux - Foxboron
https://linderud.dev/blog/packaging-lxd-for-arch-linux/
======
hardwaresofton
LXC[0] is "the original" (citation needed) linux containerization effort, and
LXD[1] which is the daemon built to manage it on top is a really really
interesting project. In an alternative world, it would have taken off
_instead_ of kubernetes as your container management and scheduling solution
(which might have been wrong, k8s runs at a level of abstraction higher than
lxd so actually I think it deserves to be where it is).

The main difference between a common 'docker' container and a LXC container is
user namespacing[2]. This is where the improved security claims, and ability
to run "unprivileged" containers comes from. This is accomplished by uid/guid
mapping[3], and docker now has it[4] though of course docker and LXD are not
comprable -- not even LXC and docker are comparable.

If the ends of the spectrum of abstraction are Kubernetes--<other
tech>\--fork(), I'd say the spectrum with these tools included looks like:
Kubernetes----LXD---Docker swarm----Docker----LXC----fork().

[EDIT] - "difference between a LXC container and a LXD container" ->
"difference between a common 'docker' container and a LXC container". I mis-
typed and just caught it. LXD is built on LXC so obviously it does not make
sense, a LXC container _is_ a LXD container.

[0]: [https://linuxcontainers.org/](https://linuxcontainers.org/)

[1]: [https://linuxcontainers.org/lxd/](https://linuxcontainers.org/lxd/)

[2]: [http://man7.org/linux/man-
pages/man7/user_namespaces.7.html](http://man7.org/linux/man-
pages/man7/user_namespaces.7.html)

[3]: [https://linuxcontainers.org/lxd/docs/master/userns-
idmap](https://linuxcontainers.org/lxd/docs/master/userns-idmap)

[4]: [https://docs.docker.com/engine/security/userns-
remap/](https://docs.docker.com/engine/security/userns-remap/)

------
dsr_
Everything boils down to dependency management. It doesn't matter whether
you're running a distribution, a container system, a VM farm, a herd of
machines or anything that loves static linking: a sysadmin needs to be able to
ask "what packages are in use right now, what is their provenance, and how can
I roll out changes to that with the least amount of tsuris?"

(And the security officer needs to be able to ask a sysadmin to compile that
data. And the auditor needs to be able to verify the chain that produced that
data. And the poor dev trying to fix a bug needs to be able to use that data
to build a version that replicates reported issues, so they can show that they
can also fix the issue. And so on. And so forth.)

Just as interpreters usually beat compilers for speed of debugging, a system
designed to properly manage and modularize dependencies will be faster to
debug than an equivalent system that just builds the final target as fast as
possible.

~~~
smitty1e
I love Arch. It seems to find a sweet spot between the boring business world
of yum-based distros and the wild, wild west nature of gentoo.

Just the right thing for the academic pursuits.

Mileage is wildly variable, of course.

~~~
techntoke
You can't really compare Arch to Gentoo really. Arch's goal is to keep it
simple which they do via a extremely robust, but easy to understand package
format. It takes almost no time to create a new package and submit it to the
AUR. I can get the latest version of almost any piece of software I want with
Arch between their standard package repo and the AUR. I can upload a small
PKGBUILD easy-to-understand text file and create a package from it. Yum on the
other hand is tedious to maintain. That is why RHEL and CentOS are often years
behind stable packages in their repos, and using a two-year old kernel.

~~~
MertsA
As someone who uses Arch as a daily driver and has spent plenty of time
messing around with rpmbuild I disagree with your claim that yum (RPMs) is
tedious to maintain. RHEL and CentOS are behind on software releases because
they actually freeze functionality when they make a release and updates within
a release will not upgrade to the latest and greatest major release of that
software. They tediously backport bug fixes and security patches to keep the
old version up to date and only upgrade to the latest and greatest when a new
release comes around years later.

Arch is just a rolling release, it's basically the equivalent of running
Rawhide but waiting for a couple weeks to install updates. RedHat spends more
effort supporting the old versions that they ship than just following
upstream. The whole point of an enterprise distro with long term releases is
that they don't do any of those major updates to add features between
releases. I can install CentOS and not worry that an update is going to
suddenly change how a package works. Just look at
[https://www.archlinux.org/news/](https://www.archlinux.org/news/), most of
those almost bi-weekly news entries are stuff that I don't need to sweat on
CentOS because they won't make any changes like that between releases.

~~~
smitty1e
RHEL and CentOS make great sense in the office, where we do NOT want to waste
time faffing about with the configuration. All of that is moved to the package
manager.

You will NOT use the walrus operator in python until the distro supports it.

When I want to live closer to the edge, and get the latest QGIS going, Arch
and AUR are there for me.

------
worik
What is "vendored" in this context?

Verbising nouns confuses me....

