There’s a big announcement today coming from Docker, CoreOS, and other industry leaders around standardizing a software container format.

Fedora CoreOS is a container-focused (mostly) immutable Linux distribution designed to be lightweight and secure. It features Ignition as an early-boot-provisioning systems that alleviates all post-boot configuration, OSTree as an atomic-update mechanism, and podman as a secure and daemon-less container runtime.

If you’ve ever asked yourself WHY you need to SSH in to configure a system, why your cloud server OS comes with inkjet printer packages, or how you can get out of the burden of critical but uninspired kernel updates… then check out Fedora CoreOS!

This is a big deal. We’ve been tracking CoreOS since the beginning — we’re huge fans of Alex, Brandon and the team behind CoreOS.

Red Hat has signed a definitive agreement to acquire CoreOS, Inc., an innovator and leader in Kubernetes and container-native solutions, for a purchase price of $250 million.

Red Hat is a publicly traded company and while this announcement hasn’t really impacted shareholder value (yet), we, the open source community have been immeasurably impacted by the team behind CoreOS.

Also, check out Alex Polvi’s announcement on the CoreOS blog which includes some details and backstory.

Alex Polvi, CEO of CoreOS, joined the show to talk about their new open source product rkt, their App Container Spec, and CoreOS - the container only server OS focused on securing the internet.

We’re talking with Gerhard Lazu, our resident ops and infrastructure expert, about the setup we’ve rolled out for 2019. Late 2016 we relaunched Changelog.com as a new Phoenix/Elixir application and that included a brand new infrastructure and deployment process. 2019’s infrastructure update includes Linode, CoreOS, Docker, CircleCI, Rollbar, Fastly, Netdata, and more — and we talk through all the details on this show.

This show is also an open invite to you and the rest of the community to join us in Slack and learn and contribute to Changelog.com. Head to changelog.com/community to get started.

Talos touts:

• Security: reduce your attack surface by practicing the Principle of Least Privilege (PoLP) and enforcing mutual TLS (mTLS).
• Predictability: remove needless variables and reduce unknown factors from your environment using immutable infrastructure.
• Evolvability: simplify and increase your ability to easily accommodate future changes to your architecture.

Hit up the README if you’re curious about the name, why there’s no shell/ssh access, or how it’s different than CoreOS/RancherOS/Linuxkit

Aaron Turner (UXE at Google) says “WebAssembly is fast” and has conducted a real-world benchmark between WebAssembly and ES6 to showcase Wasm’s performance on different browsers, devices, and cores.

…this benchmark will be utilizing the WasmBoy benchmarking tool (source code). The benchmark features three different cores as of today. AssemblyScript (WebAssembly built with the AssemblyScript compiler), JavaScript (ESNext output by the TypeScript compiler), and the previous JavaScript core except run through Google’s Closure Compiler…

It’s fun to watch the Node.js ecosystem grow so rapidly. As Node matures, the community continues to build out tools around the project to make it easier to deploy more robust web applications.

The latest is Cluster from LearnBoost, an easy way to run a Node.js application across multiple cores. With support for both the 0.2.x and 0.4.x flavors of Node, Cluster offers an impressive list of features:

• Hot restarts with zero downtime
• Hard and graceful shutdown options
• Workers
  • commit suicide when master dies
  • are spawned one per cpu by default
• Plugins including the following out of the box
  • cli: provides a command-line interface for your cluster
  • debug: verbose debugging information
  • logger: master / worker logs
  • pidfiles: writes master / worker pidfiles
  • reload: reloads workers when files change
  • repl: perform real-time administration
  • stats: adds real-time statistics to the repl plugin

As expected, Cluster can be installed via npm:

npm install cluster

To crank up your server in a cluster, create your Node.js server as normal and start with cluster instead:

var cluster = require('cluster')
  , http = require('http');

var server = http.createServer(function(req, res){
  console.log('%s %s', req.method, req.url);
  var body = 'Hello World';
  res.writeHead(200, { 'Content-Length': body.length });
  res.end(body);
});

cluster(server)
  .use(cluster.logger('logs'))
  .use(cluster.stats())
  .use(cluster.pidfiles('pids'))
  .use(cluster.cli())
  .use(cluster.repl(8888))
  .listen(3000);

Got an idea for a plugin? Get forkin’.

[Source on GitHub] [Project home page]

It’s a very Merry Christmas for Mac developers. Rasmus Andersson has open sourced Kod, the “programmers’ editor for OS X.”

Built from the ground to feel like a native OS X app, Kod sports Chrome-style tear-off tabs and aims for full concurrency, taking advantage of additional CPU cores when loading files, performing syntax highlighting, and other intensive tasks.

Even with the provided integrated scripting environment powered by Node.js, perhaps the most impressive feature for the web geek is that Kod is fully themable using CSS3.

So if you’re still waiting on TextMate 2.0 and Vim or emacs isn’t your bag, then give Kod a try.

[Source on GitHub] [Web site]

Even Facebook Open Source stands upon the shoulders of giants. The Facebook Database Engineering Team just released RocksDB, a persistent key-value store for flash storage, based on LevelDB by Sanjay Ghemawat and Jeff Dean at Google.

RocksDB builds on LevelDB to be scalable to run on servers with many CPU cores, to efficiently use fast storage, to support IO-bound, in-memory and write-once workloads, and to be flexible to allow for innovation.

Daniel Lindsley, of
django-haystack,
django-tastypie, and
itty fame, just launched a
small but useful project.

Littleworkers.

This extremely minimal Python module allows you to set a list of command
strings to be executed by the system, and it eats through them in a process pool.

Example usage:

from littleworkers import Pool

# Define your commands.
commands = [
    'ls -al',
    'cd /tmp && mkdir foo',
    'date',
    'echo "Hello There."',
    'sleep 2 && echo "Done."'
]

# Setup a pool. Since I have two cores, I'll use two workers.
lil = Pool(workers=2)

# Run!
lil.run(commands)

Simple. Pythonic.

It is 100% compatible with HAProxy, and takes full advantage of the ACL functionality of HAProxy to provide fine-grained caching policy based on the content of request, response or server status.

The feature list is long. Click through to see ’em all.

Nuster is very fast, some test shows nuster is almost three times faster than nginx when both using single core, and nearly two times faster than nginx and three times faster than varnish when using all cores.

Here’s a detailed benchmark backing up these claims.

Head JS is a 2.3kb script that speeds up, simplifies and modernizes your site. Currently, Head JS is at an early alpha stage, but is promised to get more stable this week.

The HEAD section is the worst place to load scripts. It’s painfully slow. The more and the bigger the worse it gets. When you move your scripts to the end of the document you aren’t able to use HTML5 or CSS3 safely or you run into dependency problems.

That’s where Head JS comes into play.

So what’s the problem with loading on top?

A huge majority of the sites you visit everyday often have many SCRIPT tags in the HEAD section of the document.

Let’s take a peek at apple.com:

<script src="http://images.apple.com/global/scripts/lib/prototype.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/lib/scriptaculous.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/browserdetect.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/apple_core.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/search_decorator.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/promomanager.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/home/scripts/ticker.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/home/scripts/promotracker.js" type="text/javascript" charset="utf-8"></script>

Apple is loading 11 scripts in total, but when you first hit the page you’ll have to wait for all these scripts to be loaded before the rest of the page gets rendered. In programming this is called blocking.

The total weight for the scripts on the Apple homepage comes in at 361.60kb.

It can get even worse. Older browsers such as Firefox 3.5 load these scripts in sequence. The next script starts loading only after the previous script is fully loaded. This means that the first page render will be painfully slow.

A common solution to this is to move the script tags to the bottom of the document, just before the end of BODY tag.

So what’s the problem with loading on bottom?

When all scripts are included on the bottom of the page you’ll end up fighting with these issues:

• HTML5 and CSS3 can’t be used and sad side effect is the treacherous FOUC (Flash of Unstyled Content). To avoid this ugly FOUC effect you need to load the script on top.
• JavaScript organization gets hard and you can’t do scripting that depend on these scripts before they are included.

How does Head JS solve these problems?

The single best solution to these universal problems is to include Head JS on top of the page and load rest of the scripts with it and make it the only SCRIPT in your HEAD.

A small job with following benefits:

• The page continues to load after the small 2kb head.min.js file is loaded
• You can use the latest CSS3 techniques and provide alternate CSS for IE and other old school browsers
• You can safely use HTML5 tags even with IE
• You can define JavaScript code on the middle of the page that depend on the scripts on the bottom
• You’ll have a fast, parallel, non-blocking script loader at your disposal

In addition, you can:

• Target CSS for specific screen widths, browsers, paths, etc.
• Style your pages differently depending on the application state, such as whether the user is logged or not

How do you use Head JS?

All script loading is done with head.js()

// the most simple case. load and execute single script without blocking. 
head.js("/path/to/file.js");

// load a script and execute a function after it has been loaded
head.js("/path/to/file.js", function() {
  ...
});

// load files in parallel but execute them in sequence
head.js("file1.js", "file2.js", ... "file10.js");

// execute function after all scripts have been loaded
head.js("file1.js", "file2.js", function() {
  ...
});

// files are loaded in parallel and executed in order they arrive
head.js("file1.js");
head.js("file2.js");
head.js("file3.js");

// the previous can also be written as 
head.js("file1.js").js("file1.js").js("file3.js");

There are even more examples in the usage section at the Head JS homepage that cover:

• Script organization
• Labeling scripts
• CSS3 feature detection
• Screen size detection
• Browser detection
• CSS Routing
• JavaScript feature detection

[Source on GitHub] [Homepage]