[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Docker and Container Tools Podman/Buildah/Skopeo



On Wed, Mar 06, 2019 at 03:32:02PM +0100, Dejan Jocic wrote:
> On 06-03-19, Reco wrote:
> > 	Hi.
> > 
> > On Wed, Mar 06, 2019 at 12:17:27PM +0100, Dejan Jocic wrote:
> > > On 05-03-19, Reco wrote:
> > > > 
> > > > Canonical's famous for their NIH too. Mir, Unity, LXD - it's a long
> > > > list, although RedHat has longer one.
> > > > 
> > > > Reco
> > > 
> > > 
> > > Mir and Unity I can get, but why would you put LXD in that sentence about
> > > NIH? 
> > 
> > Given the existence of LXC, why would anyone need LXD?
> 
> You do realise that LXD is wrap around LXC, or rather libxlc, which
> improves its functionality, while not taking anything from it?

Yep. And I see nothing that needs to be improved with LXC, security
issues left aside.
LXC has sane configuration format already, and, which is more important,
sane semantics, compared to [1].
It has features, including the arbitrary network configuration (not that
kind of abomination in LXD, or $DEITY forbid, systemd-nspawn or runc),
and arbitrary storage configuration. What's more important, it's easily
extensible.


> Some of that functionality is live snapshot migration,

CRIU is lightyears ahead here.


> bit improved security,

LOL. [2] says:

[LXD] Containers can be managed over the network in a transparent way
through a REST API.


Every time you add a web interface to a good thing you diminish its
security. No exceptions.


> improved/easier to manage networking,

Nothing comes easy once you start writing your own DSL for the network
configuration.
Besides, if one has trouble with LXC network configuration, one should
consider a job change IMO.


> overall better management. 

You forgot YMMV, so I'm adding it here.


> Also, while Canonical is not only supporter of LXC, it is practically
> major supporter, as far as I know ( but could be wrong about it ).

... and that's exactly why they could focus on fixing real issues such
as [3], [4], and [5] (last one is a shameless plug) instead of trying
to write yet another Openstack clone.

Reco

[1] https://lxd.readthedocs.io/en/latest/configuration/
[2] https://linuxcontainers.org/
[3] https://seclists.org/oss-sec/2019/q1/125
[4] https://seclists.org/oss-sec/2019/q1/119
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906805


Reply to: