jbergstroem

Twitch? Github? Lots of "social" going on over there, last I checked. I feel the definition of social is just getting laundered in the article to fit the authors size.

The beauty of the Internet has always been the way sub-nieches grows into their own communities once their parents become too diverse. For me, Facebook always felt like the last monolith that "tried to do it all". It now acquires sub-niches instead.

Logging in to machines to update configs doesn't scale well. You often end up building your own framework/api "only" to edit the config file.

Or paying $2500/instance/year for nginx plus.

One key missing piece in nginx is a way to interact with the configuration without having to edit the config file. This is such a vital piece of a modern infrastructure; where backends are added/removed on demand.

You can interact with haproxy via lua[1] or use etcd to have traefik load its configuration[2].

Seeing how [as others also mentioned] nginx seems to favor pro customers in terms of functionality, it would only seem wise to choose another proxy/load balancer for your next project.

[1]: http://www.arpalert.org/src/haproxy-lua-api/1.7/#Proxy.serve...

[2]: https://docs.traefik.io/toml/#etcd-backend

Some web servers[1] additionally stores cache information in cookies. The same author that (co-)wrote your linked draft implemented it as a primer to the draft. If only CDN's supported it :-)

[1]: https://h2o.examp1e.net/configure/http2_directives.html#http...

> nginx hacked

This caught my eye as well. Not sure what to do about it other than link/read the cloudflare blog post/incident report. FUD, etc.

I reckon h2 push (https://beta.golang.org/doc/go1.8#h2push) support will be big for web servers like caddy and traefik.

Caddy already has a few interesting ideas on how to use this: https://github.com/mholt/caddy/pull/1215#issuecomment-256360...

Well, you can still utilize it. For instance, if you serve `/static.css` from your CDN; you would (should) also add `Link` headers to all same-domain assets tied to it.

The point here is to re-use the already open http2 connection; so I'd argue that you should strive for same-domain transport.

Another (actually, the first) implementation of "http2-casper" (referenced in the article) can be found in h2o [https://github.com/h2o/h2o]: https://h2o.examp1e.net/configure/http2_directives.html#http...

The main author – Kazuho Oku – is to me a http2 wizard (and just now joined Fastly). You can read his thoughts on the matter: https://github.com/h2o/h2o/issues/421

Nosh seems to progress nicely - it just doesn't get a lot of public attention. If you follow the FreeBSD or debian mailing-lists you will find a new email announcement about releases every 3-4 weeks.

Init still seems to be undecided in FreeBSD land; my hope is that FreeBSD 11 or 12 at least makes a decision about considering to switch (or not).

Latest freebsd quarterly update: https://www.freebsd.org/news/status/report-2015-10-2015-12.h...

Latest release notes (jan 14th, 2017): https://lists.debian.org/debian-user/2017/01/msg00519.html

I think this is the dilemma of semver versus "market" versioning. If true semver is confusing, perhaps stick with the LTS releases which are named differently (one of the reasons being clear communication)?

The LTS versions are named after the periodic table of elements, starting at a and moving forward. First one was "Argon" (4.x), second "Boron" (6.x).

You can read more on LTS and naming here: https://github.com/nodejs/LTS

Expect a blog post shortly, but from v8 we get these language changes:

- await/async behind flag (already covered in thread)

- Exponentiation operator:

  > console.log(60**2*24);
  86400

- Object.{values,entries}:

  > o = { a: 1, b: 2}
  > Object.values(o);
  [ 1, 2 ]

- Object.getOwnPropertyDescriptor(s):

  > o = { a: 1 }
  > Object.getOwnPropertyDescriptors(o);
  { a: { value: 1, writable: true, enumerable: true, configurable: true } }

Additionally, there's a lot of pretty impressive optimization work done by the v8 team. You can read more about that on their blog: http://v8project.blogspot.com

Finally, one of my favorite things about Node.js 7.0 is the WhatWG http parser: https://github.com/nodejs/node/pull/7448.

edit: elaborated on exponentiation operator

..and here I thought we solved the config library war :( https://github.com/vstakhov/libucl

I do something similar to @diggan, but expand with globbing because I'm probably lazy:

  NODE_PATH=$(dirname ~/.nvm/versions/node/v6*/bin/node)
  export PATH="\
  ${NODE_PATH}:\
  ...

  export NVM_DIR="/Users/jbergstroem/.nvm"
  [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"

Also, the delay that a lot of you may be experiencing has to do with npm, not nvm.

It's not uncommon for Apple to have private branches that are merged back to their OSS projects after features/changes/devices have been announced -- it's been occurring a few times in LLVM and Clang-land. Taking a quick glance over the git history seems to point to commits referencing 3.0 though?

No snapshotting yet, can't boot, no migration tools for existing setups (time machine, filevault, fusion). It'd be interesting to see whether their permission changes introduced in 10.11 will travel further down the fs. Also, I don't see any mention of compression like lz4. Lots of work until release in 2017!

This here is unfortunately why services like these are a bad idea. If you don't control the MX pointer you need to accept that these mails can be lost. A lot of mail providers seems to support the + syntax and similarly so MTA's like postfix. I would suggest you direct your attention there instead.

For people that want something much smaller (dependency-wise), I can recommend letsencrypt.sh which – together with cron – achieves the same goal: https://github.com/lukas2511/letsencrypt.sh

Might be worth noting that if you're using the ppa's from jenkins (http://pkg.jenkins-ci.org/debian/) you will 'get 2.0 for free' next time you update. It makes sense but I wasn't really prepared for this.

You likely want debian-stable instead: http://pkg.jenkins-ci.org/debian-stable/

Just wanted to bring libucl into the game in case you are exploring json-like syntax: https://github.com/vstakhov/libucl#improvements-to-the-json-...

In my eyes pretty much the perfect configuration library and syntax. Nginx-alike, number suffixes (1min, 2gb, ..), macros, variables, includes with priority, etc. Boom! Problem solved.

It's a package called 'metrics' you can disable through Preferences -> Packages. Been in there from the get-go.

Edit: Not saying I like this "freedom advancement" much either; even databases like InfluxDB defaults to phoning home nowadays -- but this one is pretty simple to both find and disable.

I've had pretty good success with feature requests in Github – but I agree that it at least _feels_ like it depends on who is replying to you (or even what state of mind they're in; copy paste responses has been had).

Anyway, a good example of a successful feature request – shared since it might help others in their quest for success – included me attempting to reduce the problem, scoping it and suggesting a solution. If you can find examples of this problem over multiple open source repositories (in my case nodejs) it seems to contribute to it getting fixed.

Pageload - Remote - Full time

Pageload (pageload.io) is a new service that aims to make websites faster by acting as a transparent proxy between the origin and a CDN. Pageload is based in Sydney, Australia but has a global customer base and aims to be a global service when publicly launched. Pageload recenly aquired venture captial to accelerate the global rollout. We strongly believe that everyone who wants to work with us does it because it's an area they like to spend time in, be it jpeg headers or shaving cpu cycles off css minifacation. We don't have requirements as to when or from where you work -- that's most often best decided by yourself.

Our platform is [at the moment] built with nodejs. We are (currently) looking for one position:

- nodejs developer: your main job will be to expand the functionality of pageload in terms of what we can optimise (for size or speed) as well as generally improving the application, its resiliency and infrastructure. A strong background in javascript/nodejs as well as experience with C is preferred since that's where you will do most of your work (unless you can convince the team there's a better tool for the job). Experience with Amazon infrastructure is also a plus.

Feel free to shoot us an email to [jobs at pageload.io] or ping me on IRC (jbergstroem@freenode) if you'd like to talk. Looking forward to hearing from you.

Pageload - Remote - Full time

Pageload (pageload.io) is a new service that aims to make websites faster by acting as a transparent proxy between the origin and a CDN. Pageload is based in Sydney, Australia but has a global customer base and aims to be a global service when publicly launched. Pageload recenly aquired venture captial to accelerate the global rollout. We strongly believe that everyone who wants to work with us does it because it's an area they like to spend time in, be it jpeg headers or shaving cpu cycles off css minifacation. We don't have requirements as to when or from where you work -- that's most often best decided by yourself.

Our platform is [at the moment] mostly built with nodejs.

We are (currently) looking for two positions:

- dev ops: we're looking for someone that wants to help us build a globally distributed, fault-tolerant and auto scaling containerised platform. Since pageload's job is to make other websites faster, reducing latency in every step of the stack will be your highest priority. Experience with amazon, docker and nginx is required. Experience in writing javascript/nodejs is a strong plus since you most likely also will be contributing to the backend of pageload. Varnish is also a plus.

- backend engineer: your main job will be to expand the functionality of pageload in terms of what we can optimise (for size or speed) as well as generally improving the application, its resiliency and infrastructure. A strong background in javascript/nodejs as well as experience with C is preferred since that's where you will do most of your work (unless you can convince the team there's a better tool for the job). Experience with Amazon infrastructure is also a plus.

Feel free to shoot us an email to [jobs at pageload.io] or ping me on IRC (jbergstroem@freenode) if you'd like to talk. Looking forward to hearing from you.

Was just referring to the set of tools and libraries I surround myself with.

Conveniently enough the first python extension landed in head 10 days ago: https://github.com/vstakhov/libucl/pull/68

I just want to add another library in here which – at least in my world – is replacing json as the number one configuration and serialisation format. It's called libucl and it's main consumer is probably the new package tool in FreeBSD: `pkg`

Its syntax is nginx-like but can also parse strict json. It's pretty fast too.

More info here: https://github.com/vstakhov/libucl

I think Antirez said it best: "A darwinian selection will work to make sure we have the best Redis possible."

Last time I checked, Charles Darwin didn't take notes about a voting process amongst animals, rather how leaders were "chosen" by leading.

The title is misleading (currently: Io.js is one step closer to ARM). io.js already supports armv{6,7}. You can download these binaries here: https://iojs.org/dist/v1.4.2/

This change introduces preliminary support for armv8 (aarch64) which was merged to pave way for the upcoming upgrade to openssl 1.0.2 -- well, at least merged at this point in time.

The "bigger news" is that ARM has contacted io.js, offering additional architectures for io.js to build on (where specifically armv8 was introduced). Read more here: https://github.com/iojs/evangelism/blob/master/weekly-update...

The fact that opinions like these are still a thing says more about the opinion than his commitment to the node/io/libuv community. edit: obvious commit statistics below/above.