Re: [dev] containers opinion
On 23 September 2016 at 19:19, stephen Turner wrote: > whats the suckless view of containers and why? what about a Containers are an indicator of conceptual decay. Application developer code has now become infrastructure and is due to the juniority far away from any half-standardized protocols. In times with agile software development, architects lost track of the _overall_ system architecture. System daemons seem not to be enough anymore or too hard for junior application developer people to base some services on. Also it is hard to write a daemon in J2EE Java or nodejs... Since application programmers started developing (system) infrastructure you now need to put their dependency hell into some manageable "containers" to keep your base server infrastructure somehow manageable. But the introduction of containers will not lead to a better architecture, it is just the opener for uncaring developers to do system programming in nodejs etc. Remember what the introduction of all programming paradigms into C++ led to. -Anselm
Re: [dev] containers opinion
> Docker daemon is a single, statically > linked binary. that's irrelevant. you still need the right version of loonix with namespaces support, etc. containers are not independent of the operating system.
Re: [dev] containers opinion
Only slightly relevant, but I found this on Alan Cox' feed today: https://ptpb.pw/R5ZJ.jpg cheers! mar77i
Re: [dev] containers opinion
On Fri, 23 Sep 2016, stephen Turner wrote: > whats the suckless view of containers and why? what about a > containerized init helper where sinit calls the container program and > then runs daemons and the rest of the system from containers? Do you > feel containers offer additional security/stability? Containers DO NOT add any security. Unsharing resources does. If you are serious about security, proper privilege separation is the way to go. But it requires thought and careful design, something chronically missing in that whole the "move fast, break things" crowd. Stability - no. Unstable and shitty code is going to stay unstable and shitty, no matter how many layers you wrap it in. A Good operating system will shield one application from misbehaviors of another, **by default**. > Just thinking about "cloud" stuff again and daydreaming about servers. Yes, this is where containers shine. The developer writes a Dockerfile, builds and tests the image on his laptop, does it work? :shipit: Then the sysop guy just clicks around on the GCP admin panel to spin up a Kubernetes cluster, points it at the image, and viola, fuken deployed. For me, as a sysop, the image/container workflow finally makes the pain of deploying the unstable and shitty code to production bearable, because it confines the unimaginably imaginative developers' inventions into a conceptually simple and uniform package. Finally I only have to deal with one kind of crap, as opposed to 20 different kinds of crap. I welcome containers with ovations and fanfares. > I suppose with a system as small as suckless offers it might be a moot > point by the time you fire up several VM instances. VM's would add a > semi redundancy in the event of a single failure in that it wouldn't > take down the other services but then you have other issues if the > system fails anyways right?! Last time I checked, sta.li was shifting focus to the embedded space. Maybe I'm too old for this job, but I just... don't run my production workloads on a bag of potatoes. Also... Face it. The reason why we have containers, is because most applications are a stinking pile of crap, and we needed a way to confine them into something manageable. If the people that wrote all of that shitty code cared about being suckless, they'd have to harakiri. Now once you have a container, it doesn't matter at all, which host OS is it running under. On AWS, your cluster runs Amazon Linux, some sort of bastardised CentOS knockoff. On GCP, your clusters run on Debian Wheezy. (Yes, I WTF'd and LOL'd, but hey, if it works, it ain't broke.) Is there any difference? No, the Docker daemon is a single, statically linked binary. <3,K.
Re: [dev] containers opinion
> On Sep 23, 2016, at 12:18 PM, hiro <23h...@gmail.com> wrote: > > containers are there to emulate static linking or the common portable > windows programs in the form of a single .exe > > there is no security benefit of running more people's software on your > computer. > I am reminded of the fact that the main proponent of categorical imperatives never ventured far from his home.
Re: [dev] containers opinion
I am new here. I am using devuan + libvirt + lxc containers. I think in terms of security, it's less secure than a VM, since it shares the kernel & resources with the host system. But I think it's easier to backup & update containers. I like that I can just copy a container to another computer, and only need to set it up once. Also, if I update one container, it can't break the other containers. Also, each of my Container contains devuan and has its own network interfaces, it's like having many different and complete servers with own IPs, hostnames, etc., but without many expensive computers or crazy amounts of ram for VMs. However, I always have a physical second fallback & backup systems if the first one fails, because a single computer is still a single point of failure. Since I use containers as if they where normal computers, I don't see why I need to be able to control the services from the host system, I just ssh to the container if I need to restart a service. I think if I just want to isolate a single service, I would just use a simple chroot. I don't think an container is much more secure than a chroot. Am 23.09.2016 um 17:19 schrieb stephen Turner: > whats the suckless view of containers and why? what about a > containerized init helper where sinit calls the container program and > then runs daemons and the rest of the system from containers? Do you > feel containers offer additional security/stability? > > Just thinking about "cloud" stuff again and daydreaming about servers. > > I suppose with a system as small as suckless offers it might be a moot > point by the time you fire up several VM instances. VM's would add a > semi redundancy in the event of a single failure in that it wouldn't > take down the other services but then you have other issues if the > system fails anyways right?! > > just random thoughts. > > thanks, > stephen >
Re: [dev] containers opinion
containers are there to emulate static linking or the common portable windows programs in the form of a single .exe there is no security benefit of running more people's software on your computer.
Re: [dev] containers opinion
My personal view is that separate users are enough software separation for everything that I have ever wanted to do. Dunno about the party line though. On Fri, Sep 23, 2016, at 05:19 PM, stephen Turner wrote: > whats the suckless view of containers and why? what about a > containerized init helper where sinit calls the container program and > then runs daemons and the rest of the system from containers? Do you > feel containers offer additional security/stability? > > Just thinking about "cloud" stuff again and daydreaming about servers. > > I suppose with a system as small as suckless offers it might be a moot > point by the time you fire up several VM instances. VM's would add a > semi redundancy in the event of a single failure in that it wouldn't > take down the other services but then you have other issues if the > system fails anyways right?! > > just random thoughts. > > thanks, > stephen >