Ideas from discussion

[jbenet]

No description provided.

[hosh]

• Something about modifying Docker so it uses ipfs instead of the layers.
• Permissions. Allowing for +x would let nsinit to start a container directly

[wking]

On Fri, Apr 17, 2015 at 03:03:06PM -0700, Ho-Sheng Hsiao wrote:

• Permissions

Permissions are mostly in ipfs/kubo#846, although that issue is
also getting deeper into trust issues that I don't think we need to
resolve yet. We do need at least an executable mode in IPFS if we
want to run #22 directly from a FUSE mount.

Having a statically linked ipfs binary would also be nice 1.
@jbenet just pointed me at https://gobuilder.me/, so I'll see what it
spits out…

[hosh]

Get performance better so we can demo things without having pre-pinned assets.

[wking]

Longer term down the nsinit path, it would be good to be able to use Docker's bridging with nsinit. I'm not sure how that's handled in Docker, but the default nsinit config just sets up the loopback interface. If it's another stand-alone-ish library like libcontainer, it could be pretty easy to recycle here. If it's baked into docker/docker, it will likely be harder to tease out.

[wking]

On Fri, Apr 17, 2015 at 03:41:43PM -0700, Ho-Sheng Hsiao wrote:

Get performance better so we can demo things without having
pre-pinned assets.

Heh, yes ;). And fix whatever reliability issues we were having
around @jbenet's VM :p. Although towards the end I think most of the
issues where that my local IPFS daemon was serving assets over a slow
DSL link.

[wking]

And symlink-support would be nice, it's a pain (for me anyway) to get a statically linked ipfs, and Linux distros like to use symlinks like: libc.so.6 -> libc-2.20.so It's not hard to unwind those links, but it is an extra step if you're going from a vanilla distro tarball to something you can store in IPFS.

[whyrusleeping]

@wking I'm planning on having symlinks. Its on my todo heap

[jbenet]

Let's use checkboxes for tracking todos.

• symlinks (easy)
• permissions on unixfs (metadata?) (easy)
• getting exec to work from ipns inside a container (easy)
• docker storage driver (medium)
• docker with a different image format -- straight ipfs (hard)
• perf issues
• mounting on osx problems?
• prepared built nsinit, etc. (may need multiple archs)

[wking]

On Fri, Apr 17, 2015 at 05:39:48PM -0700, Juan Batiz-Benet wrote:

Let's use checkboxes for tracking todos.

I think it's easier (epecially for those of us following by mail, who
don't get updates when comments are updated) to use a separate issue
for each entry in your list, with a "demo" label (allows cross-repo
grouping [1]) or milestone (only inside one repo, but gives %
complete) to group them together.

Mechanics aside, the list looks good to me, except I think “perf
issues” and “docker with a different image format” are pretty fuzzy
;).

I'll ping the libcontainer folks about their build issues.

[wking]

On Fri, Apr 17, 2015 at 07:10:26PM -0700, W. Trevor King wrote:

… (allows cross-repo grouping 1)…

Oops, forgot the reference:

[jbenet]

@wking hm-- we use checkboxes a lot in various other repos. They're really useful to capture independent items to ensure are handled without yet having to do the work of making individual issues. Also, sometimes i edit my comments for correctness/clarity if i notice an error within a few min-- will this mess up your flow (happy to avoid it)?

[wking]

On Sat, Apr 18, 2015 at 05:06:56AM -0700, Juan Batiz-Benet wrote:

we use checkboxes a lot in various other repos. They're really
useful to capture independent items to ensure are handled without
yet having to do the work of making individual issues.

New issues aren't that hard to make ;). If you like the command
line, you can use ghi 1 and do:

$ ghi open -m 'Support symlinks'

Although I just installed ghi via:

$ gem install ghi
$ ghi config --auth wking

and bumped into 2, which I worked around by adding:

require 'socket'

to the top of my gem-installed
~/.gem/ruby/2.0.0/gems/ghi-0.9.3/lib/ghi/authorization.rb (after the
encoding comment).

Also, sometimes i edit my comments for correctness/clarity if i
notice an error within a few min--

Usually errors that you miss with the first version aren't terribly
serious, so I'm fine missing out on them.

… will this mess up your flow (happy to avoid it)?

If checkboxes are easier for you, I'll handle working with them. But
my personal preference for anything distinct enough for a checkbox is
to open a new issue.