5 ms·

finally the end of lx* containers on the way. not the actual end of course, who knows docker guys could buy this one as they did to some other unikernel compani

finally the end of lx* containers on the way. not the actual end of course, who knows docker guys could buy this one as they did to some other unikernel companies.

tamentis 8y ago
What other unikernel companies did they buy?
- kuwze 8y ago
  Unikernel Systems, which is cool because it is OCaml based. Their stuff is open source too: https://mirage.io https://mirage.io
  - rdl 8y ago
    What I would love more than really any other tech improvement would be a “trusted” mirageos hardware/software environment which would remotely attest to its integrity and the degree of hardware protection it gave running programs. Ie a regular dedicated server, a VM, or a HSM attested to by some authority.
    - perbu 8y ago
      It sounds like you'd like Intel SGX. However, it seems Intel botched the implementation and their SGX VMs are leaking data through a number of attack vectors.
      - rdl 8y ago
        Haha I did a startup based on SGX. I will never trust Intel again.
jmspring 8y ago
Jails and Zones did their jobs before LXC was a thing. The better technology doesn’t always win out — see Windows history.
- Thaxll 8y ago
  Jails and Zones are inferior to Docker overall, the advantage of Docker is not the isolation technology but the whole workflow of using those containers.
  - kuwze 8y ago
    Jails, maybe. Zones, definitely not.
    - elcritch 8y ago
      Zones are much more developed than jails, but not quite as flexible as lxc.
      - kuwze 8y ago
        I did not know that, I thought lxc was behind zones in terms of features/flexibility.
        elcritch 8y ago
        From what I understand, Linux let’s you configure independent namespaces for network, disk, CPI, etc separately. Though sure entirely what lxc allows you to configure. Whereas zones have a more one-to-one mapping of namespaces so it’s easier to secure. Just what I picked up from using Joynet’s Triton system. I really enjoyed the zones interface on smartos, decent JSON api and cli tools, built from the ground up on ZFS datasets. Jails are terrible in comparison by not really having a good standard api interface, imho.
  - hestefisk 8y ago
    You can get a similar workflow with Jails. Docker became popular because of the CLI but there are many similar options now on FreeBSD.
    - zbentley 8y ago
ckocagil 8y ago
I don't understand all the hatred towards containers. It's simply an OS abstraction to facilitate isolation. What's wrong with that? In fact I'd love to see more containers, especially on the Linux desktop: for example a container aware compositor that could render windows from container processes and color code their borders, like Qubes does. I have nothing against VMs either. But even when they're tiny (as in the case of unikernels), do VMs scale as much as processes? I'm skeptical. Maybe someone has data.
- en4bz 8y ago
  People have turned containers in to a packaging, deployment, and orchestration tool rather than the original intent of lightweight virtualization. Containers kinda suck for those 3 things but no other tool does all 3. It's a jack of all trades master of none situation. I hate the trend of "download this container cause packaging a .deb is hard" etc.
- 0xFACEFEED 8y ago
  > I don't understand all the hatred towards containers. It's simply an OS abstraction to facilitate isolation. Containers on their own aren't enough to deploy a reliable production system. Even on a small scale. To use them for reals you need a lot of domain knowledge and the support of a large ecosystem like Docker. And even then it's easy to get stuck in a rats nest of brittle tooling. I don't have anything against containers. I'm just tired the exaggerated "ease of use" claims (eg: I talk about container management being a non-trivial problem and people telling me "just user Kubernetes!").
- tannhaeuser 8y ago
  Docker-style containers only shield you from mixed-library situations eg. where one "service" needs version A and another needs version B. It's painful because this situation is entirely accidental and could be trivially solved by linking everything statically. Then once you have two or more containers up and running, these libraries still need security updates and other fixes which is the entire point of shared libs in the first place. Basically, Docker is not a solution but part of the problem. But with Docker comes a ton of constraints; for example, basic file access and anything related to permissions is a PITA. And you need overreaching orchestration software such as mesos/marathon, k8s, or openshift. It's not that these tools are bad, but rather that they're nuclear weapons for relative little benefit, requiring expensive devops experts. All so you can pack multiple services on a single physical host (which would be much easier using classical service runtimes), and so your HTTP services (because everything has to be HTTP because of the firewalls) can all listen on virtual port 80/8080.

finally the end of lx* containers on the way. not the actual end of course, who knows docker guys could buy this one as they did to some other unikernel companies.

tamentis 8y ago

What other unikernel companies did they buy?

kuwze 8y ago
Unikernel Systems, which is cool because it is OCaml based. Their stuff is open source too: https://mirage.io https://mirage.io
- rdl 8y ago
  What I would love more than really any other tech improvement would be a “trusted” mirageos hardware/software environment which would remotely attest to its integrity and the degree of hardware protection it gave running programs. Ie a regular dedicated server, a VM, or a HSM attested to by some authority.
  - perbu 8y ago
    It sounds like you'd like Intel SGX. However, it seems Intel botched the implementation and their SGX VMs are leaking data through a number of attack vectors.
    - rdl 8y ago
      Haha I did a startup based on SGX. I will never trust Intel again.

jmspring 8y ago

Jails and Zones did their jobs before LXC was a thing. The better technology doesn’t always win out — see Windows history.

Thaxll 8y ago
Jails and Zones are inferior to Docker overall, the advantage of Docker is not the isolation technology but the whole workflow of using those containers.
- kuwze 8y ago
  Jails, maybe. Zones, definitely not.
  - elcritch 8y ago
    Zones are much more developed than jails, but not quite as flexible as lxc.
    - kuwze 8y ago
      I did not know that, I thought lxc was behind zones in terms of features/flexibility.
      - elcritch 8y ago
        From what I understand, Linux let’s you configure independent namespaces for network, disk, CPI, etc separately. Though sure entirely what lxc allows you to configure. Whereas zones have a more one-to-one mapping of namespaces so it’s easier to secure. Just what I picked up from using Joynet’s Triton system. I really enjoyed the zones interface on smartos, decent JSON api and cli tools, built from the ground up on ZFS datasets. Jails are terrible in comparison by not really having a good standard api interface, imho.
- hestefisk 8y ago
  You can get a similar workflow with Jails. Docker became popular because of the CLI but there are many similar options now on FreeBSD.
  - zbentley 8y ago

ckocagil 8y ago

I don't understand all the hatred towards containers. It's simply an OS abstraction to facilitate isolation. What's wrong with that? In fact I'd love to see more containers, especially on the Linux desktop: for example a container aware compositor that could render windows from container processes and color code their borders, like Qubes does. I have nothing against VMs either. But even when they're tiny (as in the case of unikernels), do VMs scale as much as processes? I'm skeptical. Maybe someone has data.

en4bz 8y ago
People have turned containers in to a packaging, deployment, and orchestration tool rather than the original intent of lightweight virtualization. Containers kinda suck for those 3 things but no other tool does all 3. It's a jack of all trades master of none situation. I hate the trend of "download this container cause packaging a .deb is hard" etc.
0xFACEFEED 8y ago
> I don't understand all the hatred towards containers. It's simply an OS abstraction to facilitate isolation. Containers on their own aren't enough to deploy a reliable production system. Even on a small scale. To use them for reals you need a lot of domain knowledge and the support of a large ecosystem like Docker. And even then it's easy to get stuck in a rats nest of brittle tooling. I don't have anything against containers. I'm just tired the exaggerated "ease of use" claims (eg: I talk about container management being a non-trivial problem and people telling me "just user Kubernetes!").
tannhaeuser 8y ago
Docker-style containers only shield you from mixed-library situations eg. where one "service" needs version A and another needs version B. It's painful because this situation is entirely accidental and could be trivially solved by linking everything statically. Then once you have two or more containers up and running, these libraries still need security updates and other fixes which is the entire point of shared libs in the first place. Basically, Docker is not a solution but part of the problem. But with Docker comes a ton of constraints; for example, basic file access and anything related to permissions is a PITA. And you need overreaching orchestration software such as mesos/marathon, k8s, or openshift. It's not that these tools are bad, but rather that they're nuclear weapons for relative little benefit, requiring expensive devops experts. All so you can pack multiple services on a single physical host (which would be much easier using classical service runtimes), and so your HTTP services (because everything has to be HTTP because of the firewalls) can all listen on virtual port 80/8080.