Slashdot Mirror

The main point is performance. Ryan Dahl wanted to write fast, scalable servers easily. We all know for years that threads don't scale but event loops do (see the second chart of memory consumption of apache vs nginx). Of course in order to have a highly concurrent evented server you can't use blocking system calls (which were a big mistake in my opinion to begin with - they are the only reason why you needed threads exposed at the application level for concurrency in the past). OK, so we want a portable, high performance, event-based, async-I/O, scalable, highly concurrent server. The obvious way to write such servers in a portable, OS-independent way was to write them in C using libraries like libev or libevent for event loops and libeio for non-blocking I/O. The result is great. But the problem is that it is not easy. C doesn't have lambdas, anonymous functions, closures or higher-order functions in a real sense, which all would make writing event handlers much easier. So Ryan was looking for a higher level language and found V8, the JavaScript virtual machine written by Google for Chrome. JavaScript has anonymous functions and closures. And V8 is fast. And also when you write JavaScript in the browser then you never use blocking function calls anyway, so people are already familiar with asynchronous I/O, events, callbacks, closures, futures and promises. Hell, you can even use Y combinators in JavaScript if you know your craft. Now, if only JavaScript had lazy evaluation and proper tail call optimization - maybe some day. Watch some talks by Ryan Dahl if you're interested and after 25 years in the field you should be. Oh, and Node doesn't have anything to do with the browser besides the V8 origins. It's all server-side. See the Wikipedia article on Node for more info and code examples. I'm glad that people who have been professionally programing for so many years are still willing to broaden their horizons. As I have written in the past it is not a universal property of programmers unfortunately. Have fun with new tools.

The main point is performance. Ryan Dahl wanted to write fast, scalable servers easily. We all know for years that threads don't scale but event loops do (see the second chart of memory consumption of apache vs nginx). Of course in order to have a highly concurrent evented server you can't use blocking system calls (which were a big mistake in my opinion to begin with - they are the only reason why you needed threads exposed at the application level for concurrency in the past). OK, so we want a portable, high performance, event-based, async-I/O, scalable, highly concurrent server. The obvious way to write such servers in a portable, OS-independent way was to write them in C using libraries like libev or libevent for event loops and libeio for non-blocking I/O. The result is great. But the problem is that it is not easy. C doesn't have lambdas, anonymous functions, closures or higher-order functions in a real sense, which all would make writing event handlers much easier. So Ryan was looking for a higher level language and found V8, the JavaScript virtual machine written by Google for Chrome. JavaScript has anonymous functions and closures. And V8 is fast. And also when you write JavaScript in the browser then you never use blocking function calls anyway, so people are already familiar with asynchronous I/O, events, callbacks, closures, futures and promises. Hell, you can even use Y combinators in JavaScript if you know your craft. Now, if only JavaScript had lazy evaluation and proper tail call optimization - maybe some day. Watch some talks by Ryan Dahl if you're interested and after 25 years in the field you should be. Oh, and Node doesn't have anything to do with the browser besides the V8 origins. It's all server-side. See the Wikipedia article on Node for more info and code examples. I'm glad that people who have been professionally programing for so many years are still willing to broaden their horizons. As I have written in the past it is not a universal property of programmers unfortunately. Have fun with new tools.

AI or small utility... You never know with computers ;)

Judge. It's not perfect, but it works.

I mean, you don't want second rate pictures in your pr0n stash?

I had problems building it back then, let alone writing the scripts for it and the hassle of figuring out which images were duplicates, but this utility seems to fit the bill.

maybe we should, I don't know ... Fork gcc. We could call it .. uhm... the Experimental/Enhanced GNU Compiler System or egcs for short.

You might want to take a look into rxvt-unicode (which is often called urxvt), a blazingly fast unicode-capable terminal emulator written in C++ with support for such goodies as xft (though I don't use it, as it's slowing down things tremendously) and not dependent on GTK[+] at all. It even features tabbing (so your window-manager does not need to do that), and implements a really neat idea of a client/server-model which allows one to spawn new terminals REALLY fast, while making it more lightweight, too.
 
To anybody out there: give it a shot, I bet you'll like it :)

I've just successfully installed Debian sid in my Thinkpad 560 (Pentium 100, ~900MiB HD, 80MiB RAM) through a PLIP cable. With some work I managed to get everything I wanted (X, Emacs, Ruby, and text processing tools (fonts, dictionaries, input methods) for three languages) in less than 400MiB. I'll cut and paste my notes below.

--

Always install and remove software using aptitude install and aptitude remove instead of apt-get. Aptitude keeps a log of what packages are desired by the user and what were installed just to fill dependencies, and remove the later whenever possible. This helped me to remove a lot of perl and library cruft. Be sure to add Aptitude::Recommends-Important "false"; to /etc/apt/apt.conf.

Install localepurge.

To run X you need xfonts-base. xfonts-base need xutils, which contains some font handling tools. xutils also contains that stupid imake thing which nobody uses, and that depends on cpp. Thus my system wants to install cpp in order to have fonts! I forced the installation of xutils without cpp, which broke imake. As if I cared. Imake should be in a separate package.

Grok the X package dependencies. With a careful selection of only the necessary ones you can reduce disk usage a lot. Don't install any "task" packages.

Don't install, use or get near anything with xft in it.

Depending on your tastes, it's possible to not install a full perl distribution and save tens of megabytes. As an user of the "stow" perl program, I was glad to find xstow, a stow rewrite in C++.

A good and fast X terminal emulator with proper i18n is rxvt-unicode, which I've been using for a long time and heartfully recommend. But don't install the perl-enabled weirdly-patched debian version, compile your own and configure it to your taste.

Compile a reduced kernel as soon as possible, remove the generic one and purge anything related to initrds. My initrdless kernel boots up more than 2x faster than linux-2.6-486 with yaird. Remember to not enable the trident framebuffer. Oh, and don't confuse yaird with yard like I did =)