Desktop Environment Variants?

[marbetschar]

Hi there,

TL;DR

Any chance we can distribute desktops images through images.linuxcontainers.org based upon the existing cloud variants which support cloud-init?

• ubuntu/$RELEASE/desktop-default
  • based on: ubuntu/$RELEASE/cloud
  • additional package installed: ubuntu-desktop
• ubuntu/$RELEASE/desktop-kde
  • based on: ubuntu/$RELEASE/cloud
  • additional package installed: kubuntu-desktop
• centos/$RELEASE/...
  • ...
• debian...
• fedora...
• mint...

I'm aware this request implies the need of more resources (storage, bandwidth, ...) as desktop environments probably bump the size of the images quite a bit. So its totally understandable if this is out of scope for images.linuxcontainers.org - but as it would make things on end user machines way easier and a lot more reliable I dare to open this issue anyways ;)

Also I guess just for amd64 is enough - since its mainly for local development.

Further Information

I'm currently developing Tins, which should make access to a local, containerized desktop environment as easy as possible (for development, or if you are just curious).

While hacking together a rough solution I came across the issue, that installing the desktop environment packages using cloud-init is quite error prone and takes a loooooong time.

Now I'm wondering if we can deliver pre-built images with the base packages already installed through images.linuxcontainers.org - just like another variant. Any specific changes can then still be done on the client machine using cloud-init (as for adding users, devices etc.)

[stgraber]

I'd say not at this time. Maybe once we have support for graphical output on the VM front, there will be more of a use case of this than just containers and we could build a few specific ones.

You are right that this will be quite expensive for us to build and distribute, those images will be significantly larger and will take a long time to build, so that means a lot more stress on the build machines, more storage for Jenkins, more bandwidth between Jenkins and the signing server and then more bandwidth and disk on the public facing mirrors.

[marbetschar]

Understood. Was already expecting that, will pursue the cloud-init road then - will figure out how far this goes :)