Skip to content

Commit

Permalink
Bi-monthly Update
Browse files Browse the repository at this point in the history
  • Loading branch information
joshgarde committed Mar 26, 2017
1 parent a970ee3 commit 4d30f89
Show file tree
Hide file tree
Showing 48 changed files with 1,783 additions and 0 deletions.
6 changes: 6 additions & 0 deletions Gemfile
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
source "https://rubygems.org"
gem "github-pages", group: :jekyll_plugins
group :jekyll_plugins do
gem "jekyll-feed"
gem "jekyll-paginate"
end
202 changes: 202 additions & 0 deletions Gemfile.lock
Original file line number Diff line number Diff line change
@@ -0,0 +1,202 @@
GEM
remote: https://rubygems.org/
specs:
activesupport (4.2.7)
i18n (~> 0.7)
json (~> 1.7, >= 1.7.7)
minitest (~> 5.1)
thread_safe (~> 0.3, >= 0.3.4)
tzinfo (~> 1.1)
addressable (2.5.0)
public_suffix (~> 2.0, >= 2.0.2)
coffee-script (2.4.1)
coffee-script-source
execjs
coffee-script-source (1.12.2)
colorator (1.1.0)
ethon (0.10.1)
ffi (>= 1.3.0)
execjs (2.7.0)
faraday (0.10.1)
multipart-post (>= 1.2, < 3)
ffi (1.9.14)
forwardable-extended (2.6.0)
gemoji (2.1.0)
github-pages (112)
activesupport (= 4.2.7)
github-pages-health-check (= 1.3.0)
jekyll (= 3.3.1)
jekyll-avatar (= 0.4.2)
jekyll-coffeescript (= 1.0.1)
jekyll-default-layout (= 0.1.4)
jekyll-feed (= 0.8.0)
jekyll-gist (= 1.4.0)
jekyll-github-metadata (= 2.2.0)
jekyll-mentions (= 1.2.0)
jekyll-optional-front-matter (= 0.1.2)
jekyll-paginate (= 1.1.0)
jekyll-readme-index (= 0.0.3)
jekyll-redirect-from (= 0.11.0)
jekyll-relative-links (= 0.2.1)
jekyll-sass-converter (= 1.3.0)
jekyll-seo-tag (= 2.1.0)
jekyll-sitemap (= 0.12.0)
jekyll-swiss (= 0.4.0)
jekyll-theme-architect (= 0.0.3)
jekyll-theme-cayman (= 0.0.3)
jekyll-theme-dinky (= 0.0.3)
jekyll-theme-hacker (= 0.0.3)
jekyll-theme-leap-day (= 0.0.3)
jekyll-theme-merlot (= 0.0.3)
jekyll-theme-midnight (= 0.0.3)
jekyll-theme-minimal (= 0.0.3)
jekyll-theme-modernist (= 0.0.3)
jekyll-theme-primer (= 0.1.5)
jekyll-theme-slate (= 0.0.3)
jekyll-theme-tactile (= 0.0.3)
jekyll-theme-time-machine (= 0.0.3)
jekyll-titles-from-headings (= 0.1.3)
jemoji (= 0.7.0)
kramdown (= 1.11.1)
liquid (= 3.0.6)
listen (= 3.0.6)
mercenary (~> 0.3)
minima (= 2.0.0)
rouge (= 1.11.1)
terminal-table (~> 1.4)
github-pages-health-check (1.3.0)
addressable (~> 2.3)
net-dns (~> 0.8)
octokit (~> 4.0)
public_suffix (~> 2.0)
typhoeus (~> 0.7)
html-pipeline (2.4.2)
activesupport (>= 2)
nokogiri (>= 1.4)
i18n (0.7.0)
jekyll (3.3.1)
addressable (~> 2.4)
colorator (~> 1.0)
jekyll-sass-converter (~> 1.0)
jekyll-watch (~> 1.1)
kramdown (~> 1.3)
liquid (~> 3.0)
mercenary (~> 0.3.3)
pathutil (~> 0.9)
rouge (~> 1.7)
safe_yaml (~> 1.0)
jekyll-avatar (0.4.2)
jekyll (~> 3.0)
jekyll-coffeescript (1.0.1)
coffee-script (~> 2.2)
jekyll-default-layout (0.1.4)
jekyll (~> 3.0)
jekyll-feed (0.8.0)
jekyll (~> 3.3)
jekyll-gist (1.4.0)
octokit (~> 4.2)
jekyll-github-metadata (2.2.0)
jekyll (~> 3.1)
octokit (~> 4.0, != 4.4.0)
jekyll-mentions (1.2.0)
activesupport (~> 4.0)
html-pipeline (~> 2.3)
jekyll (~> 3.0)
jekyll-optional-front-matter (0.1.2)
jekyll (~> 3.0)
jekyll-paginate (1.1.0)
jekyll-readme-index (0.0.3)
jekyll (~> 3.0)
jekyll-redirect-from (0.11.0)
jekyll (>= 2.0)
jekyll-relative-links (0.2.1)
jekyll (~> 3.3)
jekyll-sass-converter (1.3.0)
sass (~> 3.2)
jekyll-seo-tag (2.1.0)
jekyll (~> 3.3)
jekyll-sitemap (0.12.0)
jekyll (~> 3.3)
jekyll-swiss (0.4.0)
jekyll-theme-architect (0.0.3)
jekyll (~> 3.3)
jekyll-theme-cayman (0.0.3)
jekyll (~> 3.3)
jekyll-theme-dinky (0.0.3)
jekyll (~> 3.3)
jekyll-theme-hacker (0.0.3)
jekyll (~> 3.3)
jekyll-theme-leap-day (0.0.3)
jekyll (~> 3.3)
jekyll-theme-merlot (0.0.3)
jekyll (~> 3.3)
jekyll-theme-midnight (0.0.3)
jekyll (~> 3.3)
jekyll-theme-minimal (0.0.3)
jekyll (~> 3.3)
jekyll-theme-modernist (0.0.3)
jekyll (~> 3.3)
jekyll-theme-primer (0.1.5)
jekyll (~> 3.3)
jekyll-theme-slate (0.0.3)
jekyll (~> 3.3)
jekyll-theme-tactile (0.0.3)
jekyll (~> 3.3)
jekyll-theme-time-machine (0.0.3)
jekyll (~> 3.3)
jekyll-titles-from-headings (0.1.3)
jekyll (~> 3.3)
jekyll-watch (1.5.0)
listen (~> 3.0, < 3.1)
jemoji (0.7.0)
activesupport (~> 4.0)
gemoji (~> 2.0)
html-pipeline (~> 2.2)
jekyll (>= 3.0)
json (1.8.3)
kramdown (1.11.1)
liquid (3.0.6)
listen (3.0.6)
rb-fsevent (>= 0.9.3)
rb-inotify (>= 0.9.7)
mercenary (0.3.6)
mini_portile2 (2.1.0)
minima (2.0.0)
minitest (5.10.1)
multipart-post (2.0.0)
net-dns (0.8.0)
nokogiri (1.6.8.1)
mini_portile2 (~> 2.1.0)
octokit (4.6.2)
sawyer (~> 0.8.0, >= 0.5.3)
pathutil (0.14.0)
forwardable-extended (~> 2.6)
public_suffix (2.0.5)
rb-fsevent (0.9.8)
rb-inotify (0.9.7)
ffi (>= 0.5.0)
rouge (1.11.1)
safe_yaml (1.0.4)
sass (3.4.23)
sawyer (0.8.1)
addressable (>= 2.3.5, < 2.6)
faraday (~> 0.8, < 1.0)
terminal-table (1.7.3)
unicode-display_width (~> 1.1.1)
thread_safe (0.3.5)
typhoeus (0.8.0)
ethon (>= 0.8.0)
tzinfo (1.2.2)
thread_safe (~> 0.1)
unicode-display_width (1.1.2)

PLATFORMS
ruby

DEPENDENCIES
github-pages
jekyll-feed
jekyll-paginate

BUNDLED WITH
1.13.7
52 changes: 52 additions & 0 deletions _posts/2014-02-16-System Packages.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
---
layout: post
title: System Packages
date: 2014-02-16T20:40:59Z
author: groundwater
avatar-url: https://avatars.githubusercontent.com/u/538488?v=3&s=128
comments: 7
github-url: https://github.com/NodeOS/NodeOS/issues/16
---
I want to write a blog post about writing services for node-os. Feel free to add your input, or ask questions. I'll do my best to clarify things before making the post.

A system package manager is generally responsible for one of three types of packages.
1. libraries
2. executables
3. services

In the case of node-os, a **library** would be any module which you'd install with `npm install` and then load with `require(...)`. In a system like Ubuntu, a library would probably be a shared lib like _openssl_, or _libxml2_. Typically libraries are pre-compiled, meaning you only download the platform binary when installing. This is often much quicker, and less error prone that downloading and compiling source files.

`npm` handles pure-js libraries quite well, and node-os will not be changing how that works. To install a dependency to your module, call `npm install $dep` from within your modules directory. The story for c++ dependencies is a bit different, but I'm going to save that story for another time.

The second type of system package type are **executable** packages. These place executable files onto your `PATH`, allowing you to call them from the command line. The `package.json` allows you to specify executables quite easily.

``` json
{
"name": "bender-rodriguez",
"bin": {
"destroy-all-humans": "destroy-all-humans.js"
}
}
```

While `npm install -g bender-rodriguez` would install this package, and link it's executables, it's better on node-os to use `npkg install bender-rodriguez`.

Finally that brings us to **services**. Services are long-running daemons, like web-servers, databases, ssh-servers, etc. The `package.json` doesn't really have a _service_ key, but it does have a `scripts:start` key. Define a service in your `package.json` file as such:

``` json
{
"name": "planet-express-server",
"scripts": {
"start": "node server.js"
}
}
```

You can start the package with `npm start`, but that isn't really a solution for starting services managed by the system. To install and run a service the _node-os way_
1. install the package with `npkg install $service`
2. start the package through _init_ with `npkg start $service`

A job stanza will be generated by _npkg_ and sent to _init_. Your service will be long-running, and restarted if it exits abnormally.

Creating services in detail will be _yet another post_.

32 changes: 32 additions & 0 deletions _posts/2014-02-17-CoreOS + NodeOS = Win.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
layout: post
title: CoreOS + NodeOS = Win
date: 2014-02-18T06:24:38Z
author: groundwater
avatar-url: https://avatars.githubusercontent.com/u/538488?v=3&s=128
comments: 16
github-url: https://github.com/NodeOS/NodeOS/issues/17
---
I've had a number of people who've tried to run node-os, but run into problems deploying docker. See NodeOS/NodeOS-Docker#5

I'm exploring using CoreOS as the base system.
1. it comes with docker
2. it's lightweight
3. it has a one-step vagrantbox ready to go
- https://coreos.com/blog/coreos-vagrant-images/

Assuming you have Vagrant installed, you can get node-os running with

``` bash
$ git clone https://github.com/coreos/coreos-vagrant/
$ cd coreos-vagrant
$ vagrant up
$ vagrant ssh
core $ docker run nodeos/nodeos
```
- @jtenner this should side-step all those ubuntu/docker pains.

I haven't really explored CoreOS much yet, but it looks promising. Basically CoreOS treats Docker as its package manager, which is pretty sweet. I think these two compliment each other well. To use _docker-speak_ CoreOS is the lightweight cargo ship, and node-os is the lightweight container.

I'm going to explore this more, and hopefully turn this into a blog post.

36 changes: 36 additions & 0 deletions _posts/2014-02-20-Filesystem Layout.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
layout: post
title: Filesystem Layout
date: 2014-02-21T03:43:54Z
author: groundwater
avatar-url: https://avatars.githubusercontent.com/u/538488?v=3&s=128
comments: 31
github-url: https://github.com/NodeOS/NodeOS/issues/19
---
I should explain the filesystem layout of node-os a little bit, because it's a slight depart form what you'll find on Ubuntu, Redhat, Arch, etc.

I think requiring root privileges in order to install a package is lame. I've ditched the concept of _global_ or _system_ packages altogether, the only global executable is `node` located at `/bin/node`. The directories `/etc`, `/lib`, and `/usr` contain a few files necessary for node to run. I would love to reduce the number of extra files laying about, but one step at a time.

Any time you run `npgk install`, the new module will be downloaded into `$HOME/lib/node_modules`, and executables will be linked into `$HOME/bin`. Every user experiences a unique system, and every user has access to `npkg`. You do not need root privileges to install packages.

For example, if there are two users on the system `bob` and `kim`, and bob runs `npkg install ncurl`, the filesystem will look roughly like:

```
/home/
bob/
bin/ncurl --> ../lib/node_modules/ncurl/ncurl.js
lib/node_modules/ncurl
kim/
bin/
lib/node_modules/
```
### root and init

When the kernel is ready, it will start init as PID 1. In node-os, init is located in `/root/bin/init`. Init is a module like any other executable. It is available on npm, and can be updated with `npkg install`. Modules in `/root` come pre-installed with node-os. They are the necessary modules to boot the system into a usable state.

An example set of default modules might be:
- [init](https://github.com/nodeos/nodeos-init)
- [npkg](https://github.com/nodeos/nodeos-npkg)
- [wssh](https://github.com/groundwater/node-wssh)
- [nsh](https://github.com/groundwater/node-bin-nsh)

11 changes: 11 additions & 0 deletions _posts/2014-10-14-Keynote on NodeJsMadrid group.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
---
layout: post
title: Keynote on NodeJsMadrid group
date: 2014-10-14T10:01:56Z
author: piranna
avatar-url: https://avatars.githubusercontent.com/u/532414?v=3&s=128
comments: 17
github-url: https://github.com/NodeOS/NodeOS/issues/73
---
They have [just accepted](https://github.com/NodeJsMadrid/talks/issues/1) that I do a keynote about NodeOS, so I'll need to prepare something... :-) Not a hurry, probably it will be in some months, there are other ones on the queue and I'm a bit bussy at this moment, but it's a step :-)

22 changes: 22 additions & 0 deletions _posts/2015-03-12-Starting GitBlog.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
---
layout: post
title: Starting GitBlog
date: 2015-03-12T22:42:23Z
author: piranna
avatar-url: https://avatars.githubusercontent.com/u/532414?v=3&s=128
comments: 3
github-url: https://github.com/NodeOS/NodeOS/issues/115
---
In the last days there has been few work here at NodeOS, but that's because [we has been worked on a side open source project](https://github.com/NodeOS/NodeOS/issues/105): thanks to the awesome work of @formula1, now GitBlog is a reality :-D [GitBlog](https://github.com/NodeOS/GitBlog) is a blogging system that use GitHub issues as engine, so it integrate directly with our current work flow based on them :-) We'll store the content of the [legacy blog](http://node-os.com/blog/) for historical purposses and reference. In the next days maybe there would be some updates, but at this moment is production ready, and in fact this will be the first post there :-D

But GitBlog hasn't been the only thing we have been working on... the most important one has been a re-design of the overlay layers inspired by [this IBM article](http://www.ibm.com/developerworks/linux/library/l-mount-namespaces/index.html) that have bring us trhee important things:
- root home folder moved to the users filesystem
- users has their own local filesystem hierarchy...
- ...and root filesystem now it's read-only :-D

This has the great advantage that will be easier to generate ISO disk images and to port to other platforms, since the root filesystem is minimal. So minimal, that now it only host the `resolv.conf` and terminfo files, so in a future iteration we'll remove them at all. No root filesystem, only the initramfs to boot the system and everything stored in the users home! :-D A too drastical design? Yes, but we are not willing to create a POSIX system here, but instead only the required parts to create an environment were Node.js apps could feel like at home :-) This give us more flexibility to optimize CPU & memory resources (specially disk space) and increase security by having less components in the system. It needs still some work to clean-up the final users filesystem and about automatically assign a filesystem namespace to new process (at this moment they are all mount on boot...), but seems promising :-)

In other things, some people think that a graphical interface is important for an OS. I don't think so, and in fact it complicate the overall system so we decided to [split NodeOS and have several flavours](https://github.com/NodeOS/NodeOS/issues/106), but it's true that would be cool to be able to use NodeOS to play some games... :-P and that's why [there has been some progress towards FbDev support](https://github.com/NodeOS/NodeOS/issues/39#issuecomment-76904769). We have it by default thanks to Linux kernel default configuration, so why not use it? We were thinking about writting a wrapper library and use it as basis to implement the [Canvas API](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API) on top of it, but the fact is that [node-canvas](https://github.com/Automattic/node-canvas) (the most popular Canvas API library for Node.js) has surpassed us and now [it start to support FbDev natively](https://github.com/Automattic/node-canvas/issues/533) thanks to our comments :-D It's cool when your work can help to move forward other projects... :-)

And last but no least... now we have a [Facebook page](https://www.facebook.com/NodeOperatingSystem) :-P It's not active yet but we'll try to fill it soon :-)

Loading

0 comments on commit 4d30f89

Please sign in to comment.