81–90 of 103 posts
Can someone explain this in words that a time traveller from 2010 would understand?
Love the question. This should be the new ELI5. I think a lot of articles on here would benefit from answering that question.
Or ETTT5YA or ET5... explain to time traveler from 5 years ago
Earlier quoted context omitted.
That's a great point, but I think the point of what Bryan has been doing is to make Linux work with Zones (and dtrace). That's a primitive that Joyent has wanted to upstream into the Linux kernel for a long time and has never been able to get the necessary consensus around it (similar to OpenVZ's troubles getting their work upstreamed). In short, this is sort of a hack to give you zones on Linux without needing to ge…
Emulations have been a Unix feature for a long time actually. NetBSD has had 64 bit Linux emulation for ages, for example, but its not very complete because no one has cared enough to implement more. For example Illumos is AFAIK the first system to emulate epoll. The Linux API is huge and historically the process has been just fixing stuff for a binary someone wants to run. It is very tedious work... I dont really se…
edit: parens
Earlier quoted context omitted.
Docker swarm basically lets you say "I want to deploy this image somewhere, you choose from the available actual machines" based on constraints that you've set up. You also had to actually set up the machines themselves (though docker-machine is intended to take some of the pain out of this). sdc-docker (the tech behind this, Triton) basically lets you just keep deploying containers without any regard for the actual…
> sdc-docker (the tech behind this, Triton) basically lets you just keep deploying containers without any regard for the actual underlying machines (or EC2 instances, DO droplets, Linodes) that you are actually deploying to. It's like docker-machine + docker-swarm but all automatic and managed by guys on the other side of the curtain, so you can just write the checks and keep the Docker goodness flowing. Not sure I g…
Yes, the data center operator needs to install the hardware compute nodes, but after that there's no additional step to provision anything else but the containers themselves.
Earlier quoted context omitted.
Emulations have been a Unix feature for a long time actually. NetBSD has had 64 bit Linux emulation for ages, for example, but its not very complete because no one has cared enough to implement more. For example Illumos is AFAIK the first system to emulate epoll. The Linux API is huge and historically the process has been just fixing stuff for a binary someone wants to run. It is very tedious work... I dont really se…
Hey Justin -- do you have insight into how hard any particular remapping (ie: epoll) is to perform ? I was talking to @bcantrill about their effort at a Docker meetup and mentioned the NetBSD emulation (he said "Oh! Of course!"), but whats interesting (in retrospect) is that they (Joyent) just tried running stuff and played whack-a-mole w/ unimplemented APIs... how tough would it be for "us" (NetBSD) to occasionally…
Earlier quoted context omitted.
The difference for the operator is: Baremetal -> smartos -> container vs Baremetal -> hypervisor -> virtual machine -> container. Theres root safety in the smartos implementation of docker. So they can do multi-tenancy. For the customer, you dont have to provision entire virtual machines to run docker containers.
Is it multi-tenancy of various Joyent customers on the same hardware? So you get containers placed somewhere in their data center on shared hardware with other customers? Or do you already need to have dedicated hardware provisioned at Joyent to launch containers on? I'm still unclear on that point, which makes me question how it's saving the end user money.
There's no need to provision anything other than the containers.
Earlier quoted context omitted.
Hey Justin -- do you have insight into how hard any particular remapping (ie: epoll) is to perform ? I was talking to @bcantrill about their effort at a Docker meetup and mentioned the NetBSD emulation (he said "Oh! Of course!"), but whats interesting (in retrospect) is that they (Joyent) just tried running stuff and played whack-a-mole w/ unimplemented APIs... how tough would it be for "us" (NetBSD) to occasionally…
Speaking without familiarity with NetBSD, I think it depends on what kernel facilities the system happens to have; speaking for SmartOS/illumos, in many cases we were able to slightly rephrase Linux facilities as extant facilities -- saving a considerable amount of time and effort. For example, the big realization with epoll was just how naive it is -- so much so, in fact, that it actually looks very similar to a pre…
A lot of the issue is just testing - NetBSD does not have any in tree tests for compat. I have some out of tree, which help a lot.
Earlier quoted context omitted.
Hey Justin -- do you have insight into how hard any particular remapping (ie: epoll) is to perform ? I was talking to @bcantrill about their effort at a Docker meetup and mentioned the NetBSD emulation (he said "Oh! Of course!"), but whats interesting (in retrospect) is that they (Joyent) just tried running stuff and played whack-a-mole w/ unimplemented APIs... how tough would it be for "us" (NetBSD) to occasionally…
Speaking without familiarity with NetBSD, I think it depends on what kernel facilities the system happens to have; speaking for SmartOS/illumos, in many cases we were able to slightly rephrase Linux facilities as extant facilities -- saving a considerable amount of time and effort. For example, the big realization with epoll was just how naive it is -- so much so, in fact, that it actually looks very similar to a pre…
In cases like that, did you end up trying to be bug-compatible, or make a design decision to clear up the trouble ?
[edit -- spell "Bryan" correctly]
Earlier quoted context omitted.
Emulations have been a Unix feature for a long time actually. NetBSD has had 64 bit Linux emulation for ages, for example, but its not very complete because no one has cared enough to implement more. For example Illumos is AFAIK the first system to emulate epoll. The Linux API is huge and historically the process has been just fixing stuff for a binary someone wants to run. It is very tedious work... I dont really se…
Hey Justin -- do you have insight into how hard any particular remapping (ie: epoll) is to perform ? I was talking to @bcantrill about their effort at a Docker meetup and mentioned the NetBSD emulation (he said "Oh! Of course!"), but whats interesting (in retrospect) is that they (Joyent) just tried running stuff and played whack-a-mole w/ unimplemented APIs... how tough would it be for "us" (NetBSD) to occasionally…
I amagine much of the Joyent code could be easily ported to NetBSD/FreeBSD (which now has a 64 bit interface as of a few months back). epoll may well be the most difficult (it has edge and level triggered events and other annoyances). But a not very performant version should be doable.
Mostly, few people have been interested. I have a decent test suite though (rump based) so email if you are interested...
Earlier quoted context omitted.
Speaking without familiarity with NetBSD, I think it depends on what kernel facilities the system happens to have; speaking for SmartOS/illumos, in many cases we were able to slightly rephrase Linux facilities as extant facilities -- saving a considerable amount of time and effort. For example, the big realization with epoll was just how naive it is -- so much so, in fact, that it actually looks very similar to a pre…
Hi Bryan -- I'm also aware that epoll may have been a bad example on my part, because isn't it subject to some nasty fork/share bugs wrt handling the (well) handle, and what file it's actually associated with the handle -- so a parent can get notifications on a handle it doesn't have, or worse, notifications for a socket that it does have that is not really the same handle that's issuing the event. In cases like that…
While a best effort has been made to mimic the Linux semantics, there
are some semantics that are too peculiar or ill-conceived to merit
accommodation. In particular, the Linux epoll facility will -- by
design -- continue to generate events for closed file descriptors
where/when the underlying file description remains open. For example,
if one were to fork(2) and subsequently close an actively epoll'd file
descriptor in the parent, any events generated in the child on the
implicitly duplicated file descriptor will continue to be delivered to
the parent -- despite the fact that the parent itself no longer has any
notion of the file description! This epoll facility refuses to honor
these semantics; closing the EPOLL_CTL_ADD'd file descriptor will
always result in no further events being generated for that event
description.
I saw the name and my desire to read it plummeted. The same person wrote http://www.joyent.com/blog/the-power-of-a-pronoun which led to one of the most talented developers of node core and libuv leaving the project for a while.
That "most talented developers of node core and libuv" took time out of his day to revert a commit to take a gender neutral pronoun and make it back into a male one. Talented people can be shitbirds also you know.