ende42's comments

It's in the docs … on my servers this fixes things as well:

    S=my_server ; ssh $S 'mkdir -p ~/.terminfo/f/' ; scp /usr/share/terminfo/f/foot $S:~/.terminfo/f/foot

PITA still.

Turns out, Karma isn't a bitch after all.

We recently implemented a simple streaming server based on Openresty and Redis. Redis is used as buffer. We load tested it up to 2000 mountpoints (128kbit mp3 streams) with 15.000 clients.

The architecture has some nice properties. For example the buffer being not in-process means (besides an obvious performance hit) that the streaming server can be seamlessly redeployed without loosing the buffer.

The Openresty Lua implementation is amazing.

I just moved from a late 2014 MBP running Arch to a Precision 5520 (more or less the business variant of the XPS15) running Alpine. Both feature an i7 HQ, 16GB RAM, 512GB SSD. Both where about 2200€.

The Precision is a good laptop but it's my first that isn't better in every way than the one I had before.

On Par:

* Fast (for a laptop) processor.

* Fast SSD. 900MB/sec on the MPB, 400MB/sec on the Precision. Anyway fast enough.

* 16GB RAM. Just enough for me.

Good:

* Linux support. Very important for me. Suspend to RAM on lidclose works reliably. WLAN works. (Display dimming just works (as with the MBP), no coil whining here).

* Display. Native HD (had to use Linux' crappy scaling on the MBP). Non-glare. (And the MBP had the display stain issue)

* 3 years on site guaranty, if on site isn't possible, I can keep the SSD.

* Can change RAM, SSH, battery without voiding guaranty.

Bad:

* Display. I'd prefer 16:10.

* Sound is slightly worse when laptop is used on a table. Sound is dismal when laptop is used... on the lap.

* Keyboard on the new Precision is worse than the one on the 3 years old MBP. Will use the UHK in the office anyway.

Couldn't find a public test-repo on the front page. Anyone wanting a test drive without signup, here you go: https://niko.gitly.io/ruby-shout

I love the speed and the (repo internal) search. Looking forward to the announced missing features.

Note: the "Add Collaborators" link works for anonymous users. Sending the form then fails with a JS error.

Is there a plan for a global repo search?

I was excited for a moment. Then found out neovim doesn't support -x. And this is why: https://github.com/neovim/neovim/issues/694 (tldr; vim encryption is unsecure and thus removed from neovim for the time being). Would have been nice, though.

3. is the reason why NGinX is the recommended proxy in front of webapps with scarce parallelism (for example Ruby with Unicorn; see http://unicorn.bogomips.org/PHILOSOPHY.html for an explanation) when "slow clients" are to be expected. NGinX is protecting the webapp from blocked workers by slow clients and Outlook Webmail seems to behave just like one. I don't know by heart how to tune this behavior if one wants to avoid it but this property is the main reason we use NGinX.

What about Nix (https://nixos.org/nix/)?

Thanks for the upgrade link. I missed that. Great that NCHAN is (almost; besides directive prefix) configuration compatible!

The "Subscribers" section of "Push Module" should include websocket, I think.

Thanks for your work!

Actually we (laut.fm) are using the HTTP Push Module for our public API for a live stream of tracks which get played on our ~ 1500 icecast stations. We offer 3 formats: http://api.laut.fm/song_change.stream.json for a line separated JSON HTTP stream, ws://api.laut.fm/song_change.ws.json for the same as websocket endpoint and http://api.laut.fm/song_change.chunk.json for the last x songs. It's not really high volume, just 6 to 7 per second. But it runs basically unattended for years now and I'm pretty happy with it.

Is there any reason to update to the new one (other than new features; admittedly I haven't really looked into NCHAN)?

We're using a home baked solution using our own config server (https://github.com/niko/goconfd) which evaluates templates POSTed to it. Combined with some trivial shell loops over a blocking POST and a HAProxy restart this does the job sufficiently well. If anybody is interrested in the details I'm happy to elaborate.

Offtopic. But still: Thanks. Nice.

Nice article. Thanks. Does proxying icecast streams with NGINX work when the protocol is not HTTP but ICY?

Nice. Went straight over to verify. And now the best part. I'm on a plan that's not even sold any more (10GB). Which just got "doubled" to 30GB. put.io <3

µBlock is great. I used Ghostery first and then Disconnect. But with µBlock in advanced mode I can block facebook.com on all sites but facebook, twitter.com on all site but twitter, and g+ on all sites but google.

Nice!

Using it as slave of a server side redis would be fun. :)

For scenarios where I felt etcd/gconf/consul is overkill I wrote goconfd (https://github.com/niko/goconfd). Features:

* reads config from a json file * GET requests with deep links into the json tree * POST request with template as body and deep links (using the go template engine, too) * long polling (response has to be triggered explicitly by a PUT request)

I also made a simple docker container running HAProxy - configured by goconfd - to orchestrate docker containers.

Two years ago I implemented something different, but in green: https://github.com/niko/green

I had a juice version in the pipe but I didn't like that I had to use yellow for that. It's hard to use yellow once you get used to green.

But I'm really interested in orange now so I might give carrot a try.

(For us) Docker is not about security or scalability but about (good enough) isolation, separation of concerns and reproducability. Let me elaborate.

* Isolation: Docker enables us to pack any software and let it run with close to none side effects. Different versions of packages, libs and gems needed by apps don't interfere. It's like bundler but for all kind of dependencies not only gems.

* Separation of concerns: For our operations it doesn't matter what's inside a Docker container. We have mid sized Ruby web apps, small Go demons, NGINX with Lua support compiled in, legacy PHP apps neatly packed in Docker containers. They have a well defined interface:

The build script which consistently sums up dependencies and the build process. `docker run` wrappers which clearly state the interface of the running container like exposed ports and mounted volumes.

* Reproducability: We are able to run the same containers in development, staging and production. A dozen containers will easily run on a developers laptop.

As a side effect the Docker architecture makes us think harder about app architecture like which services are stateless and which are not and for what reason.

The fact that containers share a kernel and thus are not 100% isolated or reproducable as with virtualization hasn't been an issue for us (so far).

There are still issues and features we're missing. For example private Docker repos are PITA and building instead of pulling from a repo means you might get fooled by the build cache. And we'd love to have build in support (or at least a common standard or best practices) for orchestration. But all together for our needs it's already pretty useful.