An Stelle in bestehende Technologie & Software zu "investieren" und das Ökosystem rund um Docker & LXC weiter zu stärken, häkelt Canonical (mal wieder) an ner ganz dollen Eigenbau-Lösung.
Ach so, aber wenn ich mir das verlinkte Posting anschaue, dann muss ich stellenweise schmunzeln....
> - Secure by default (unprivileged containers, apparmor, seccomp, ...) NIX ist "secure by default"....gibts per Definition nicht...
>- Image based workflow (no more locally built rootfs) Die Nutzung eines Image-basierten Workflows bringt Vorteile, aber verschenkt die Benefits, die ein natives Dateisystem bringt (im Hinblick auf Performance)....
Von -.,-.,.-,.-,.- am Mi, 5. November 2014 um 13:56 #
Dieses Mal nicht. Canonical passt mit Hilfe des Docker Inc.-Know-Hows das Bestehende nur an seine eigenen Bedürfnisse an. Das ist völlig legitim und o.k. Einen Alleingang wie bei Unity oder Mir kann ich da nicht erkennen. Wie schon geschrieben wurde, wird hier nichts "ersetzt".
LXC ist in der Implementation unsicher dass äußerten sich bereits Security Forscher bei Red Hat oder Microsoft. Man kann bereits auf Treiberebene die Trennungen der Container durchbrechen. Deshalb sucht man einen Zwischenweg zwischen LXC und KVM.
An Stelle in bestehende Technologie & Software zu "investieren" und das Ökosystem rund um Docker & LXC weiter zu stärken, häkelt Canonical (mal wieder) an ner ganz dollen Eigenbau-Lösung.
Großes Kino Mr. Shuttleworth...really impressive
LXD wird auf LXC aufbauen und LXC nicht ersetzen. Dabei geht es eher um eine Ergänzung.
https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/010817.html
Ach so, aber wenn ich mir das verlinkte Posting anschaue, dann muss ich stellenweise schmunzeln....
> - Secure by default (unprivileged containers, apparmor, seccomp, ...)
NIX ist "secure by default"....gibts per Definition nicht...
>- Image based workflow (no more locally built rootfs)
Die Nutzung eines Image-basierten Workflows bringt Vorteile, aber verschenkt die Benefits, die ein natives Dateisystem bringt (im Hinblick auf Performance)....
Ich lasse mich überraschen....
Dieses Mal nicht. Canonical passt mit Hilfe des Docker Inc.-Know-Hows das Bestehende nur an seine eigenen Bedürfnisse an. Das ist völlig legitim und o.k. Einen Alleingang wie bei Unity oder Mir kann ich da nicht erkennen. Wie schon geschrieben wurde, wird hier nichts "ersetzt".
LXC ist in der Implementation unsicher dass äußerten sich bereits Security Forscher bei Red Hat oder Microsoft. Man kann bereits auf Treiberebene die Trennungen der Container durchbrechen. Deshalb sucht man einen Zwischenweg zwischen LXC und KVM.
wieso ein bild von dieser hac******** und nicht einfach ein ubuntu logo oder ähnliches. würde weniger in den augen weh tun.
jaja .. das bereits erfundene Rad soll GPLisiert werden
Nehmt doch gleich FreeBSD mit Jails und ZFS.
Oder SmartOS ... dort gibt es Solaris Zones ... ebenfalls mit ZFS .... und die Kroenung ist KVM !!!