garthk

I worked for a clever, clever, stupid bastard like that once. He could have made legitimate millions but chose instead to cook the books, embezzle a few hundred thousand, set up patsy directors to take the blame, flee the state with his wife and kids, and live under an assumed name.

Either that or, now that it occurs to me, we might have been a front for drug laundering. That would also have fit the evidence. Huh.

It's so common, large companies have entire teams dedicated to running Black Duck scans of their software to hunt down the paste-ins lest their software become open source or their patents cross-licensed by accident.

That scenario might not be entirely possible given the terms of GPL and Apache, but that's how they talk about it.

I think you might be attributing stronger emotional intent than is present. They disagree about whether it's worth fundamentally changing npm's search method to avoid some ../.. paths in your argument to require. require aside, you can express yourself through your code however you like.

All the pain and exhaustion is a sign you're fighting your way uphill instead of downhill. Node works brilliantly if you publish lots of tiny modules in public, @substack style.

Unfortunately, some of us need to live uphill.

I find the tiny module style works pretty well for me, but I need private code. I haven't yet found a private registry solution I like. NPM's lack of support for any "get this module from this registry" directive in package.json forces them to proxy the main registry. They're not good at it. I'm still declaring my dependencies by tarball URL, losing semantic version specs, e.g. "most recent compatible with 4.x".

It strikes me as unlikely now to change in any way other than "here, use my paid-for private registry", because shareholders. That makes me unhappy, but not unhappy enough to ditch the public Node ecosystem and go back to what I was using before. It had its own uphill, and living there was harder.

I'm not. To the degree famo.us is wonderful, its about page gives a misleadingly bad impression on my default mobile browser.

On my landscape iPad Air, the hamburger menu on the first link flapped state during scrolling and selection. I genuinely had no idea, when I tapped Docs, whether I'd got that or Demo. Scrolling the next page moved the content up, but also the header, while leaving the left side navigation in place.

I'm glad to see the sparklines. I'm worried that the CPU sparklines in particular are likely to mislead due to the lack of a common vertical axis scale. I suspect Tufte might advise two graphs: one with a fixed 0…100 axis scale, one "zoomed". The former would help you compare CPU history between apps, and sport a shaded background region to indicate the range of the latter.

As an alternative to checking in your dependencies: have your build server 'npm install' your module for testing, then archive the directory tree. Deploy from the archive.

Nice, and crazy comprehensive. I especially love redefining the wrapper using eval to match the signature of the original.

Docker doesn't prevent use of ZFS.

It's common and easy to mount your host FS into the container, putting mutating data where you can take full advantage of the superior architecture and ops capabilities of whichever FS you prefer.

The images' internal AUFS/BTRFS layers are then only for keeping your binaries-at-rest and static configuration straight. They may as well be in highly indexed ZIP files, for all you care.