tobbyb

Tor is a project originally by the US Navy developed to protect US intelligence. Given that background it would be a bit of a leap to trust security or privacy to technology produced by the government unless it is reasonable or rational to assume they will work against their own interests by releasing it.

For a long time time before NSA was exposed, it had been working closely with a lot of security related technologies, researchers, developers, companies, and was a key part of the software security industry including standards. For instance SeLinux is a NSA project pushed hard by a number of open source companies including trying to integrate it into the Linux kernel but stymied by Linux Torvalds. A lot of these technologies and companies often get a free pass.

For anyone with serious anonymity or privacy needs it would be pragmatic to think carefully before relying on technology that is linked to the US government or US companies which basically rules out a lot of computing. Using technology to fight an adversary with unlimited resources and access to talent, and has been an integral part of the security industry is foolhardy and seems difficult to win. We need to find alternatives.

There a particular personality that is given to self righteousness and imposing on others, and these self appointed arbiters quickly attach to these causes and use them to police other people, nevermind the cause. The internet has made this kind of self righteous mob effortless, and they feed off each other making justice or the original cause completely secondary to their own need to impose their views.

Civilized society depends on the rule of law. There is a large mechanism in place in any civilized society with an extensive process to first decide guilt and then give the guilty an opportunity to pay the price, reform and try again. This by definition rules out arbitrary individual perceptions of justice or injustice, discrimination or organizing to 'directly' deliver it, to prevent anarchy. Justice by definition cannot empower some arbitrary individuals or groups views over others.

Activism targets laws or injustice based on reason and not individuals. The objective is not to shame or deliver consequences for an individual but change the law. Self righteous mobs on the other hand driven by their own opinions and the need to impose their views, rather than justice, target individuals.

Discrimination is illegal and has a huge social, personal, and professional consequences. If an individual escapes that somehow it indicates a flaw in the rule of law which activism would target, not the individual. But that's not fulfilling for those driven by self importance.

You may decide something is wrong but only the rule of law can make that decision objectively and enforce consequences. A mob convinced of its own infallibility sidetracks all that, evades accountability in favour of their own perceptions and in an exercise in pure self importance and injustice delivers consequences. That is little to do with justice and everything to do with vanity, self importance and inability to recognize the limitation of one own views, and the value of activism and rule of law.

Given the extreme zeal for liberty and freedom espoused by the tech crowd in the early 90's its more than sad, no a complete tragedy that there is just one Snowden today and hundreds of thousands of others who 'toil' away silently actively building this.

Here was your turn to do your bit, something meaningful and what we get instead is a complete co-option into the system. No activism, no protest, very few whistle blowers, especially since you of all other groups would be alert to the possibilities, where is the movement? There has been real sacrifice and sustained, persistent struggle to get here, values have a cost to the individual, if one balks if there is a cost then its just empty words and mass delusion.

And thus there is no shame, no movement, no activism, no code of conduct, no moral pressure to dissociate with these kind of activities or to call out all these people in any technology fora, even today when its out in the open.

And it's just not their failing. Modern populations seem to be completely unequal to any kind of meaningful activism and change. There is such a debilitating focus on individualism, and the completely irrelevance of wider community and other interests that the only real thing left is self interest and self interest has no 'values' or value, beyond expediency and survival.

There are many who not only remain unconcerned but often seek to diminish or dismiss concern as hyperbole or exaggerated, often by pointing to the current status quo.

No one is interested in you the individual, but they are certainly interested in building the capability to track all individuals and preempt anything that threatens any entrenched status quo.

We are not currently a police state but we are certainly building the capability and the cultural language to justify it. The moral high ground and the entire framework of values that powered it have shown to be near meaningless by the alarming ease with which they have been discarded in favour of the language of security and paranoia. Everyone is safe in a cage. It will be naive to believe in the context of how modern states operate that a cluster of extreme right wing medievalists in the ME are bringing on this state of affairs, the bulk and most powerful of whom are paradoxically our best friends in the region.

Surveillance states are not a on/off thing, you don't suddenly wake one day to a surveillance state. These capabilities take time to build, but once the infrastructure is in place it will inevitably get used.

In this case we can see all the pieces being put in place methodically with language that makes George Orwell look astonishingly prescient. And its the self absorption of this generation who have inherited and enjoyed a relatively 'free' and equal state with 'hope for improvement' but are going to willfully pass on something more ominous.

I am not quite sure I totally agree with the authors view of 'giving back' but this is a much needed article and we need more of this. I think it's a bit risky to conflate start ups and businesses that are solving problems with 'giving back'. Let's celebrate these startups for innovating, solving problems and being successful, but let's not mix that up with 'giving back'.

Giving back would be getting involved in social causes, solving problems for free with no expectation of any return, and in this context giving back to the open source community. Stripe is awesome but in this context it would be great to hear about how they are supporting open source projects they are built on than how they are solving problems in payment processing.

Open source funding is a bit of a mess at the moment. There is a huge lacuna on how to highlight startup companies (and thus encourage others) that are successfully built on open source contribute back. Companies that use open source should at least have a page listing the projects they are using and how they are giving back. There is no visibility or any initiative that tracks and encourages this positively. Without focus and organization nothing happens. Another important thing is giving back should be simple funding for open source projects and not hiring the developers or adding developers. That seems to be more about gaining influence than supporting the project for everyone.

The more worrying thing is a general lacuna of user representation in open source in an organized fashion, developer funding of popular and interesting projects that are not a part of the startup scene and just general funding. The inevitable result is open source will if it's not already, be hijacked by corporate interests. Ultimately money makes its own agenda, and if users do not secure their interests others will.

I have often appreciated your quick interventions to stop snark and abuse on this message board. But this doesn't seem right.

This thread by its definition is controversial and lends itself to subjective option and heated discussion, more than others. At what point does opinion become 'ideology' as every single comment can be described as such, who decides the thin line between ideology and opinion and worse cross it to label and dismiss a 'comment' in this context as an 'inflammatory ideological rant'? This is extremely subjective and dangerous territory.

Abuse, snark and insult do not lend themselves to subjectivity and are easily flagged. But in this case I think the comment makes a genuine attempt to engage, reason and articulate a point of view, and is not dismissive or abusive but veers slightly to the personal as did the original commentator. But still deserves to be heard and not hidden. The warnings about abuse or bad language is not subjective and hold.

But it would be unfortunate to want to hide away articulated and reasoned responses one may not agree with as that inevitably leads to an echo chamber bereft of diversity, pushing away diverse opinions, and in effect making discussion pointless. In my case, rightly or wrongly, it discouraged me from reading the rest of the thread, as it appears anything diverse will be flagged and leave behind a sterile and uninteresting discussion.

Perhaps Hacker News is not the right forum for this discussion. How does one discuss violence against people and sometimes entire populations for political or other ends with a distant and dispassionate tone without coming off as passive and unfeeling, unlike a more technical subject in which passion may be misplaced and derail discussion.

I think in discussions its useful to deal with defaults because there are always workarounds. For Docker the default is to run init less containers so you do not get a normal OS environment. For LXC the default is run init in the container so you get a container with a normal OS environment out of the box, more like a VM.

lxc-start by default will start the container's init and any apps installed with services will start with container start. lxc-start has no options or documentation I have seen that enables users to launch as a single process without starting the container init so it will be useful to share how that works.

With Docker you launch the app in the container directly from the host and if the app is a daemon for instance Nginx, you need to disable daemon mode or it won't work as there is no init process to manage background processes. So with Nginx you would need to disable daemon mode in nginx.conf or start it with 'nginx -g "Daemon off"' in Docker. In contrast with LXC you install Nginx and it will work as it would on bare metal or VMs. There is no need to think about how the app manages its processes

To run multiple processes or daemons in Docker you need to use a shell script, or use a third party process manager like supervisord for instance. The entire Docker ecosystem, and tooling is built and defined around single process containers.

A ton of problems around deployments especially for multi process apps, daemons, databases or any apps that require cron, logging, agents etc emanate here. This becomes a process in itself to know how the apps operates and then to configure it accordingly. Your deployments also become docker specific, for instance Nginx with a Wordpress stack deployed on bare metal or VM can move seamlessly to an LXC container and vice versa because they all run normal OS environments.

This can't happen with Docker and you need to re-engineer deployments. Why take on this extra load, and create incompatibility from a non standard OS environment, or worse give up the init that comes for free for for a third party process manager to do the exact same thing, only with more effort and cognitive load? This doesn't make much sense unless there is an extremely clear upside and use case.

What I find curious about all the container discussions and narrative is the strange lack of context. Sure discuss Docker but also discuss namespaces, cgroups, overlayfs, aufs, and all the other critical enabling technologies where a lot of major problems with containers exist and will be solved. For instance user namespaces, cgroups are not namespace aware, how to integrate overlayfs or aufs so they can be mounted by user namespaces seamlessly.

Surely these projects and developers need support and focus. Or else it become mere marketing for companies that have the funds or ability to market themselves. Do we just talk about libvirt without context or understanding of kvm and xen, how would that be useful or meaningful?

An ‘immutable container’ is nothing but launching a copy of a container enabled by overlay file systems like aufs or overlayfs, a ‘stateless’ container is a bind mount to the host. Using worlds like stateless, immutable or idempotent just obscures simple underlying technologies and prevents wider understanding of core Linux technologies that need to be highlighted and supported. How is this a sustainable development model?

Docker chooses to run containers without an init. The big problem here is most if not all apps you want to run in a container are not designed to work in an init less environment and require daemons, services, logging, cron and when run beyond a single host, ssh and agents. This adds a boatload of additional complexity for users before you can even deploy your apps, and a lot of effort is expended is just managing the basic process of running apps and managing their state in this context.

Contrast that with LXC containers which have a normal init and can manage multiple processes enabling for instance your VM workloads to move seamlessly to containers without any extra engineering. Any orchestration, networking, distributed storage you already use will work obviating the need for reinventing. That’s a huge win and a huge use case that makes deployment simple and slices all the complexity, but if you listen to the current container narrative and the folks pushing a monoculture and container standards it would appear there are no alternatives and running init less containers is the only ‘proper’ way to use containers, never mind the additional complexity may only make sense for specific use cases.

LXC has supported user namespaces since 2013 and it works well enough. You could run unprivileged containers from Ubuntu 14.04. I think Nspawn supports it now too.

This is different from running the Docker from a user account. With Docker you are interfacing with the Docker daemon from a non root account but the container is still running as root. With Unprivileged containers thanks to user namespaces containers are launched and run from the user account.

But unprivileged containers need to be a simple no fuss experience and this can only get addressed in the kernel. On top of that the most popular user land container implementation Docker chooses to run containers without an init and since most apps you want to run in a container are not designed to work in an init less environment and will require daemons, services, logging, cron and when run beyond a single host, ssh and agents, just managing the basic process of running apps and their state adds tons of additional complexity for users. Integrating user namespaces on top of this is going to be non trivial.

Contrast that with LXC containers which have a normal init and can manage multiple processes enabling your VM workloads to move seamlessly to containers without any extra engineering. Any orchestration you already use will work obviating the need for reinvention. That’s a huge win but if you listen to the current container narrative and the folks pushing a monoculture and container standards it would appear there are no alternatives and running init less containers is the only ‘proper’ way to use containers, never mind the complexity.

A lot of problems related to unprivileged containers are in kernel namespaces and cgroups which are not going to be solved in user land. Cgroups are not namespace aware and only root users can manage them. Access to resources like mounts and networking require privileges and that won’t change. These are probably not 'sexy or fundable’ so the problems remain unsolved, and instead complexity deriving from niche use cases whether security or micro services is foisted on everyone.

A container is just a Linux process in its own namespace that anyone can create with unshare, iplink and chroot or pivot root. An ‘immutable container’ is nothing but launching a copy of a container enabled by overlay file systems like aufs or overlayfs, a ‘stateless’ container is a bind mount to the host. Using worlds like stateless, immutable or idempotent just obscures simple underlying technologies and prevents wider understanding of core Linux technologies that need to be highlighted and supported. But we choose to focus on wrappers and the narrative becomes about funding and standards. Without more focus and support on the filesystems, namespaces and other critical enabling technologies end users will not get a consistent experience. How much support do they have beyond the occasional article on LWN? These devs and projects work in obscurity with little support. This does not seem to be sustainable development model.

we have a pretty easy to use multi-domain mail server in a Debian Wheezy container [1] based on LXC. It's an integrated package with Postfix, Dovecot, a GUI admin (Vimbadmin) and Roundcube webmail preconfigured so you can start with a GUI admin right away and add domains and users. It's like a small head start and works out of the box and there is a comprehensive guide on how to use it and configuring a mail server including a screencast [2], that could be worth exploring.

But the thing with a mail server is there are number of steps beyond installation. You need to configure SSL and spam filtering, then your DNS and SPF records. Then you need to test and ensure your mail is making it through. And a mail server requires constant attention. It's not a configure once and forget. You need to take care of spam filtering, anti virus, and ensuring your mail server is up pretty much 24/7 without break, as email is important and cannot be down. This can become a huge time sink, hence folks leaning towards hosted solutions like Gmail etc which take care of all of that for a small cost.

[1] https://www.flockport.com/apps/mailbox/

[2] https://www.flockport.com/using-the-flockport-mailserver/

A container is just running a process or chroot in its own namespace. If you run it as it is you have a single process container like Docker uses, if you run an init in the namespaced process you have LXC or OS containers that can support multiple processes like a lightweight VM. [1]

With LXC containers you start them as root and there is no lingering background LXC process running. Docker also starts containers as root but also has dockerd hanging around presumably so non root users can interface with it. But the container process is still running as root so dockerd seems a bit redundant and unnecesary.

This is because untill recently you couldn't run chroot as non root users and needed to run containers as root. But 'user namespaces' (> kernel 3.8) changes this and allows users to run processes in namespaces as a non root user. LXC has supported unprivileged containers for some time now [2] so you can run LXC containers as non root users, as in the entire container process is unprivileged. Docker and Rkt are working on this but its not simple to implement for container managers as non privileged users cannot access networking and mounts. But when it does presumably dockerd can run as an unprivileged process.

But Linux kernel namespaces have not been designed for multi-tenancy for instance cgroups are not namespace aware, and untill this changes in the kernel, containers will not provide the level of isolation or security required for multi-tenant workloads.

And containers managers like LXC or Docker that take these capabilities and merge them with networking and layered filesystems like aufs or overlayfs cannot work around this. Parallels OVZ is designed for multi tenancy but the kernel patch it appears is too large and invasive and doesn't look it will be merged.

So user namespaces is one level of security and isolation, you can also use seccomp, app armour, selinux or even grsec. But you have to find the middle ground between security and usability and given the relative confusion about containers, namespaces, and container managers it will take time to mature.

[1] https://www.flockport.com/how-linux-containers-work/

[2] https://www.flockport.com/lxc-using-unprivileged-containers/

First he manages to 'semicrash' his helicopter in icy waters, then retrieve his life raft from beneath the sinking heli in freezing water, then survive in extreme weather for 36 hours with half a litre of water and a few protein bars, and the energy to stave off 3 polar bears!

You obviously have to have presence of mind, some training I suspect, but also dollops of luck. What if the polar bears were a bit more hungry, a bit more determined?

What a great read! Kudos and a big congratulations to Sergev Ananov for surviving this! What a relief for his family and friends and I don't think they are going to let him try again, at least not without a crew.

We are trying to solve this problem with Flockport [1] so users can at least get to see and try apps without needing to install and configure tons of stuff and we use LXC containers which behave like lightweight VMs and provide an OS environment similar to a VM or a bare metal server that users are more familiar with. And this also allows us to package the stack and app in a single container..

With Docker apart from the app you have to deal with the additional complexity of a single app environment that is not an environment that most users are familiar with, for instance you need to launch all your apps in 'non daemon mode' (how many uses know how to do this, and why you would need it?) figure out how to deal with storage persistence, networking and 'linking containers' and things like logging, cron and ssh (there is no place for these in single app containers). Installing something as simple as Mysql with Docker is non trivial because of storage. So this adds a whole new layer of complexity on top of the app that's makes it completely unsuitable to package apps if simplicity and accessibility is the objective. You need to be a real expert to deal with this, much more than LXC containers or VMs.

We have a guide on building a simple Wordpress stack from scratch with Docker [2] that gives readers an understanding of the level of complexity involved with Docker and what it seems to be designed for. It's not for end users and certainty not to making things simple. It would take a tenth of the effort to install Wordpress in a VM or LXC container. But its pointless to compare VMs or LXC containers to Docker, as Docker is intended for a completely different use case and that's what its users and advocates should highlight and push.

We have packaged over 60 apps in LXC containers at Flockport and Ruby apps are by far the most complex to setup, usually requiring a complete build environment. PHP is the simplest both to install and troubleshoot, and usually just works. The Ruby apps like Redmine, Gitlab are more complex and Discourse is the toughest to get going. You need to be an expert to install it and an even bigger expert to run it so much so that I think unless you are a rails developer the only reliable way to use Discourse is to have the Discourse team manage it.

[1] https://www.flockport.com

[2] https://www.flockport.com/a-beginners-guide-to-docker

We had looked at a bunch of forums from the traditional forums like MyBB, PhpBB, Flux BB to newer takes on forums like Vanilla, Discourse, Nodebb and Esotalk an year ago.

I liked the minimalism of Esotalk but it was being phased out in favour of developing Flarum. I found Vanilla was somehow missing the typical community feel of forums though lowendtalk is using it and is one of the busier communities.

Discourse was Ruby and extremely difficult to install and we did manage eventually but I always felt you need to be comfortable with Ruby or have managed hosting with Discourse. It's a handful.

Flux BB was one of the fastest of the traditional forums then. Arch Linux uses Flux BB and its a busy forum. It will be interesting to see which way they go now that it is going to be Flarum. I remember seeing some heated discussions in the Fluxbb forums about the shift.

We just added a flarum container in the Flockport app store [1] for those who want to give it a quick spin. It will work with LXC and most likely Nspawn too for those who have a recent versions of Systemd.

https://www.flockport.com/store

That's a bit naive. A vote doesn't mean a do what you want. Trust is not automatic. It comes from transparency and accountability which secrecy inhibits.

There is no concept of trust in a democracy. Everything is about being open and accountable. There is zero need to negotiate a commercial treaty in secret, this is an anti-pattern.

Debating the need for secrecy drags one down a flawed, self serving and fabricated narrative.

What a depressing read. Jeff Bezos needs to tell us why he is treating our fellow human beings so badly. I am willing to wait another day for my gadgets from amazon, or not even have gadgets. I didn't ask for this, no customer asked for this. I don't want people to be treated like this,

Some of the reports about the sick and unlucky being penalized is grotesque and Bezos needs to stand up and defend himself or be dismissed as a psychopath.

Efficiency, performance and wealth should not be a ruse for businesses to drag us a sterile world stripped of humanity in pursuit of profits. No one signed that social contract.

Ultimately the only reasons sociopaths thrive and succeed is there are too many people willing to do their bidding, every single time, to dehumanize themselves and others.

To clarify, this is a preview GUI container, more to show users how to run GUI apps in containers than a Chromium container. You are right hough, We ideally need to keep it updated but it can also be updated directly by users inside the container.

Flockport provides something similar but with containers https://www.flockport.com/store We have a fledgling app store with over 30 apps that can be deployed on any Linux server in minutes. It's completely free.

The advantage with using containers as opposed to VMs is containers are portable so you are not stuck to any server or cloud provider. Your apps are portable, and cloning, snapshots and backups become simpler.

The advantage of using LXC is the entire stack can be in one container and the environment is more like an OS that users are familiar with. Users can use the flockport utility to pull the app and then directly get to the App dashboard, without all the installation and configuration hassles of a typical stack. And Flockport apps should work with nspawn and other container managers.

Haven't tried mbox yet but Firejail is pretty straight forward to sandbox locally installed apps. You can roll your own namespaced sandbox with unshare but Firejail does that cleanly, adds seccomp support, and is easy to use.

Docker, LXC, Nspawn and other container oriented managers are more focused on running chroots in namespaces so you would need to install the app in the container. In a way a container, especially an unprivileged one is perhaps a bit 'cleaner' as the app is installed in its own chrooted OS and not on the host.

The only thing is running GUI apps in containers is involved in terms of configuration, so Firejail wins for simplicity. Firejail also supports chroots so you can run proper containers with it.

We have a writeup on running accelerated GUI apps in containers here - https://www.flockport.com/run-gui-apps-in-lxc-containers/

The new Firejail app [1] may be worth exploring as it is designed to run locally installed apps like browsers and games in sandboxes, as opposed to more chroot oriented container managers like LXC, Docker or Nspawn. They all use namespaces.

If you want to use a chroot oriented container manager its better to use an unprivileged container so you are not running as root. Currently only LXC has support for unprivileged containers. We have an experimental GUI app container with Chrome that can be used in unprivileged mode. [2]

You can even run your own sandbox with a simple command like this 'unshare -fp --mount-proc' That gives you a bash shell in its own pid space. You can expand this command further to use more namespaces like mount, net, user to get yourself a sandbox.

That is what apps like firejail and container managers are using, but its useful to know what's happening underneath. We are currently working on a guide on how to use unshare that may help. [3]

[1] https://l3net.wordpress.com/projects/firejail/

[2] https://www.flockport.com/apps/lxc-gui/

[3] https://www.flockport.com/how-linux-containers-work/

Not really, Nspawn is extremely promising and is developing fast. Systemd 220 adds support for user namespaces so you can run nspawn containers as non root users.

But containers need minimal OS templates, networking and a way to configure it properly, storage support for things like cloning and snapshots, a way to configure cgroups, and management and those are still not available beyond some basic machinectl commands, and neither is the documentation. Nspawn is going to be a very strong solution, especially given Systemd is now there by default on most mainstream distros, but its not there yet.

User namespaces while letting non root users run containers brings with it a whole bunch of problems on accessing host resources like mounting file systems, networking devices etc that LXC has faced and addressed.

I have an article up on using nspawn containers here [1]. There are a lot of wild misconceptions floating around about LXC. It is actually pretty mature and easy to use, has supported user namespaces since 2013, has advanced networking and storage support for things like cloning and snapshots with btrfs, zfs, overlayfs, LVM thin, aufs, a nice set of tools to manage containers, and a wide choice of minimal container OS templates.

We have a lightweight boot2lxc VM image based on Alpine Linux for those who want to give it a go [2]

[1] https://www.flockport.com/a-quick-look-at-systemd-nspawn-con...

[2] https://www.flockport.com/start/

A lot of the cgroups and namespaces functionality too time to mature and stabilize. User name spaces for instance was only available with 3.8. Cgroups and namespaces still don't play well with each other.

Cgroups was initially added by some folks from Google in 2007. A lot of the early work on Linux containers was done by Daniel Lezcano and Serge Hallyn of the LXC project, supported by IBM. It was initially a kernel patch and userland tools. You can still see it on the IBM website. It was merged in 2.6.32.

Then around 2012 the LXC project started being supported by Ubuntu and Stephane Graber of Ubuntu continued the work with Serge Hallyn. LXC was of course focused on OS containers and they didn't really market themselves.

Around 2013 when LXC was finally becoming usable by end users, Docker who were probably using it in their previous avatar in dotcloud as a PAAS platform, took it as a base, modified the container OS's init to run single apps, removed storage persistence, and built it with aufs layers, and took it to market aggressively.

But if you look beyond the PAAS centric use case, OS containers are simpler to use, offer near seamless migration of VM workloads, more flexibility in storage and networking scenarios and are more easily used with the ecosystem of apps and tools with a normal multi-process OS environment.

The ability to gain the advantages of containers without needing to re engineer how you deploy applications is an incredible value proposition.

LXC is mature, pretty advanced and simpler to use than Docker, but a lot of users and media have got the impression that its 'low level' or difficult to use.

The Docker, PAAS and micro services folks are the only ones really messaging and going out there to gain adoption and there is an unfortunate conflation of containers to Docker and monoculture developing. The 'Open Container Standard' is an example. Shouldn't that be 'Open App Container Standard'?

App containers are a constrained OS environment and add complexity, and the various Docker specific solutions being developed for everything from networking to storage is evidence of the additional complexity. There is obviously a huge devops PAAS case here that people see value in. And the sheer amount of money and engineering deployed means something good has to come out of it. But containers cannot be just about PAAS.

I run Flockport that provides an app store [1] based on OS containers that are as easy to use as Docker hub and extensive documentation [2] on using containers so do give it a look.

https://www/flockport.com/store

https://www.flockport.com/guides

Just playing with this in a VM with an attached btrfs volume, a complete revelation. 96 lines! And it's actually pretty functional. This takes keeping it simple to a whole new level.

The Wheezy image I use with LXC worked well enough, the minimal alpine image not so well, apk complaining about its database.

User name spaces support would be nice, then we can play with unprivileged containers.

And Overlayfs would be a nifty alternative to btrfs, it's in kernel 3.18, and 4.04 adds support for multiple lower layers. But this btrfs implementation is cool too. Cgroups support will be somewhere on that list too.

Cgroups and namespaces is in the kernel. General Linux ecosystem for networking, storage and distributed systems is already extensive. The possibilities are endless.

So now LXC, Docker, Rkt and Nspawn have Bocker for company.

That's why I used the word took, Docker used LXC as a base till version 0.9, untill it got enough traction, at which point it basically recreated LXC with libcontainer.

But that was not the point. The point is you have always had perfectly usable end user containers from the LXC project even before Docker. Then a VC funded company Docker bases itself on LXC and markets itself aggressively and suddenly a lot of users think LXC is 'low level' or 'difficult to use'? This messaging is coming from the Docker ecosystem and the result is the user confusion we see on most container threads here.

Informed discussion means people know what OS containers are, what value they deliver, and what Docker adds on top of OS containers so there is less confusion and FUD, and users can make informed decisions without a monoculture being pushed by aggressive marketing.

But that discussion cannot happen if you are in a hurry to 'own' the container story and cannot acknowledge clearly alternatives exists and what value you are adding exactly on top. I see people struggling with single app containers, layers and lack of storage persistence when they are simply looking to run a container as a lightweight VM.

The 'open container movement' is yet one more attempt to 'own' the container technology and perpetuate the conflation of Docker to containers. How can a 'open container movement' exclude the LXC project that is responsible for the development of much of the container technology available today. It should ideally be called 'Open App Container' because there is a huge difference between app containers and OS containers. OS containers provide capabilities and deployment flexibility that app containers simply cannot give because they are a restrictive use case of OS containers. Containers technology as a whole cannot be reduced to a single PAAS centric use case.

OpenVZ or LXC give you OS containers like KVM or VMWare gives your Virtual machines. Unlike OpenVZ, LXC does not need a custom kernel, and is supported in the mainline Linux kernel paving the way for widespread adoption.

Docker took the LXC OS container template as a base, modified the container OS init to run a single app, builds the OS file system with layers of aufs, overlayfs, and disables storage persistence. And this is the app container.

This is an opinionated use case of containers that adds significant complexity, more a way to deploy app instances in a PAAS centric scenario.

A lot of confusion around containers is because of the absence of informed discussion on the merits or demerits of this approach and the understanding that you have easy to use OS containers like LXC that are perfectly usable by end users like VMs are, and then app containers that are doing a few more things on top of this.

You don't need to adopt Docker to get the benefits of containers, you adopt Docker to get the benefits of docker and often this distinction is not made.

A lot of users whose first introduction to containers is Docker tend to conflate Docker to containers, and thanks to some 'inaccurate' messaging from the Docker ecosystem think LXC is 'low level' or 'difficult' to use, Why would anyone try LXC if they think it's low level or difficult to use? But those who do will be pleasantly surprised how simple and straightforward it is.

For those who want to understand containers, without too much fuss, we have tried to provide a short overview in a single page in the link below.

https://www.flockport.com/containers-minus-the-hype

Disclosure - I run flockport.com that provides an app store based on LXC containers and tons of tutorials and guides on containers, that can hopefully promote more informed discussion.

Are you referring to the fdb tables, I tried that some months ago but it didn't seem to work. Maybe its changed now. I will give it a shot. Any tips?

I remember seeing a patch floating around that added support for multiple default destinations in VXLAN unicast but I think some objections were raised and it's not made it through. At least it's not there in 4.1-rc7. That would be quite nice to have.

http://www.spinics.net/lists/netdev/msg238046.html#.VNs3rIdZ...

This looks unbelievably simple, on the lines of why hasn't it been done before.

So you ping 10.3.4.16 and your host automatically 'knows' to just send it to 17.16.4.16 where lying in wait, the receiving host simply forwards it to 10.3.4.16. I like it.

This is a vexing problem for containers and even VM networking. If they are in a NAT you need to create a mesh of tunnels across hosts, or you create a flat network so they are all on the same subnet. But you can't do this for containers on the cloud with a single IP and limited control of the networking layer.

Current solutions include L2 overlays, L3 overlays, a big mishmash of GRE and other type of tunnels, or VXLAN multicast unavailable in most cloud networks, or proprietary unicast implementations. It's a big hassle.

Ubuntu have taken a simple approach, no per node database to maintain state and uses commonly used networking tools. And more importantly it seems fast. And it's here and now. That 6gbps suggests this does not compromise performance like a lot of other solutions tend to do. It won't solve all multi-host container networking use cases but will address many.

Hi, I think we are playing with words and context here so I will leave it here.

The quote is in a context and says LXD uses LXCs low level api. It does not say 'LXC is a low level api'.

How does one conclude that from the quote and take it out of context without misleading readers? Any one with a remote awareness of LXC will know that's erroneous. Do you still think your comment was accurate?

Have you used LXC, are you familiar with LXC beyond the quote, are you interested in having an informed discussion on LXC and containers? There has be a basis for informed discussion.

No, I was referring to LXC. Did you have look at the links to the LXC website and the container overview? There are plenty of 2 minute screencasts there that show LXC in action.

The LXC project does not refer to itself as low level, but ironically Docker which knows exactly what LXC is, does. And the results are these needless misconceptions, which is a tad unfair to the developers of the LXC project. Why would anyone try LXC if they think its 'low level'?

LXD extends LXC to add a REST api, multi-host container management and soon live migration.

LXC is a full fledged userland project and has been since 2009 when it began development. It is also responsible for driving the development of a lot of the kernel capabilities mainly 'cgroups' and 'namespaces' needed to support containers.

That's the 'low level' capabilities that LXC, Docker. Nspawn use to give you containers, but it would be as inaccurate to refer to Docker as 'low level' because it uses these, as it would LXC.

A container is simply a file system in a folder that gets booted and works on any underlying Linux filesystem so I am not sure about how conceptually a 'container format' fits there? That's one of the great things about containers. You do not need to think about storage. Simply zip the container folder and move across servers. Containers are completely portable across any Linux system today. But if you are going to use aufs or overlayfs layers to build single apps containers with constrained container OS templates then perhaps there is a need for a format.

That's just wrong. Please have a look at the LXC or Systemd nspawn websites [1] or our guide to container technology [2]

LXC is not 'low level' capabilities as Docker erroneously refers to it on its website or a 'low level api'. [3]

The LXC project in development since 2009 on which Docker was based, and now Systemd-nspawn give you pretty advanced OS containers with mature management tools, full stack linux networking, multiple storage options including support for btrfs, zfs, LVM, Overlayfs, cloning, snapshotting and a wide choice of container OS templates.

It also offers unprivileged containers that let's non root users run containers, which is a big step forward for container security, and is currently working on live migration of containers.

Docker takes that as a base, limits the container OS template to a single app, builds the containers with layers of aufs and enforces storage separation. [4] It's not rocket science, you can do this yourself with overlayfs and LXC in minutes. [5]

Docker is an opinionated way to use containers. You don't need to adopt Docker to get the benefits of containers. You adopt Docker to get the benefits of Docker. A lot of the messaging, hype and marketing conflates the 2 and it suits the docker ecosystem to do that but it does not benefit informed discussion.

Nspawn is a systemd container project, which is similar to LXC in that it gives you OS containers, not layered single app containers. Rkt is based on Nspawn if I am not mistaken.

It's curious that LXC project largely responsible for the development of most of the container technology available today is not part of this. I feel most folks who can move beyond the wild misconceptions floating around to try LXC will find it's significantly simpler to use.

We provide a lightweight VM image with a complete LXC environment based on Alpine Linux for those who are interested. It's 80 MB and available for Virtualbox, VMWare and KVM at https://www.flockport.com/flockbox

Disclosure I run flockport.com which provides an app store for servers based on LXC.

[1] https://linuxcontainers.org [2] https://www.flockport.com/a-new-users-guide-to-container-tec... [3] https://www.flockport.com/guides [4] https://www.flockport.com/lxc-vs-docker [5] https://www.flockport.com/experimenting-with-overlayfs-and-l...