Josh Gillies joshgillies

Intro Notes

I wrote this guide because after getting my CubieBoard 1 I followed the Arch Linux ARM instructions and was suprised to be left with a system that albeit working, had missing RAM and no fbconsole at all.

This guide gets Arch Linux ARM into your 1GB Cubieboard 1 with the minimum functionality one would expect. It is not intended to be an all encompassing document, focusing instead on saving your time having to read through the forum to get functionality that otherwise every other Linux distribution brings out of box.

You will have to adjust these instructions if you have a 512M Cubieboard.

Step 1 - Format disk your SD Card

At a minimum, you need to create the first partition on an SD card to store the bootloader files and kernel uImage. For the root filesystem you can choose to use either a second partition on the SD card, USB or SATA. This guide however only covers SD. Replace instances of /dev/mmcblkX with the appropriate device name registered on your system.

I've known people at nodejitsu for years, since before the company even existed. I still consider many of them friends. That said, somebody over there has lost their mind.

Trademarks are an important part of open source. They protect the integrity of the trust that is built by any project. A classic example of why this is the case is Firefox. Suppose that a malware producer takes the Firefox codebase, which is free and open source, packages up their malware with it and then releases it as "Firefox". Then they buy search advertising and suddenly their bad and malicious version of Firefox is the first result on search engines across the web. This is clearly a bad thing for Firefox and open source everywhere, but what can Mozilla do to protect their community of users?

They can't enforce a software license since the use is permitted under the Mozilla Public License. They can, however, enforce on these hypothetical bad actors using their trademark on the word "Fi

[In reply to https://news.ycombinator.com/item?id=7219005]

Here's the history, hope it helps.

I wrote the original version of the npm registry in a day or two on top of CouchDB. I built it quickly and didn't think much about scale.

Isaacs continued to improve and maintain that code. At one point he even wrote up an open standard for generic js package registries for CommonJS but they didn't seem to care (they were too busy arguing about promises).

At the time I wrote the initial code I was employed at CouchOne and we had a small CouchDB hosting platform operated by Jason Smith which is where we ran the registry free of charge. Later on, after CouchOne was aquired by Membase and became Couchbase, it decided to break off the hosting company and give/sell it to Jason Smith, which became IrisCouch.

Virtual DOM and diffing algorithm

There was a [great article][1] about how react implements it's virtual DOM. There are some really interesting ideas in there but they are deeply buried in the implementation of the React framework.

However, it's possible to implement just the virtual DOM and diff algorithm on it's own as a set of independent modules.

Prerequisites

Somewhat modern version of OpenSSH
Server you have SSH access to in the region you want to stream from.

Bummed about region lock? Start up your terminal and do this:

$ ssh -N -D 9999 yourserver.com

	var connect = require('multilevel-connect');

	var db = connect('password@host:port');

	db.createReadStream()
	.on('data', function(kv){
	console.log(JSON.stringify(kv));
	})
	.on('end', function(){
	process.exit(0)

	{
	// The block has begun, we're in a new block scope. The TDZ for the "a" binding has begun

	var f = function() {
	// 2. Because f() is evaluated before `a` is actually declared,
	// an exception will be thrown indicating to the author that
	// `a` is not yet defined.
	console.log(a);
	};

	"use strict";

	function processNodeList(list, target) {
	list.forEach(function(node) {
	processNode(node, target);
	});
	}

	function processNode(node, target) {
	switch (node._type) {

	So, I'm gonna make a book. It's gonna start off as a document in sphinx-doc, so I just
	publish as a flat file HTML, and then maybe figure out funding it if there's enough
	interest in the output. The subject of the book would be an open source project that can
	be completely viewed on it's own, and the idea is that the book would go through the
	technologies involved, the decision process, and how it's all structured together to
	build a self sufficient Frontend client.


	Key ideas are a structure of modular components, that means when you end up with shit
	going out of date, you don't have to change everything to adapt. Give new technology

	// module a

	b = require("./b")

	module.exports = function() {
	console.log("I'm in module a")
	}

	b()