The script

Stash it in /usr/lib/nagios/plugins of the Dirvish backup machine, naming it check_dirvish. This script assumes that your Dirvish vaults are in /mnt/backup, so tune it if that isn’t true in your case:

#!/bin/bash

for a in /mnt/backup/* ; do if [ -f ls -d "$a/"* 2> /dev/null | grep -v /dirvish | sort -g | tail -1/rsync_error ] ; then echo "CRITICAL: latest backup in vault $a failed" exit 2 else /bin/true fi done echo "OK: All backups OK"

The security setup

Create a nagios user on your Dirvish backup machine, and set up SSH passwordless authentication.

Now, if your Dirvish vaults are accessible only to root, set up sudo to allow Nagios to run this script as root:

nagios ALL = NOPASSWD: /usr/lib/nagios/plugins/check_dirvish

The Nagios setup

Finally, set Nagios up:

define command{
        command_name    ssh_dirvish_sudo
        command_line    /usr/lib/nagios/plugins/check_by_ssh -t 29 -H $HOSTADDRESS$ -C 'sudo /usr/lib/nagios/plugins/check_dirvish'
        }
define service{
        use                             generic-service
        host_name                       gabriela
        service_description             Backups
        check_command                   ssh_dirvish_sudo
        }

Of course, the sudo call is only needed if the Dirvish vaults are restricted for the nagios user.

What you’re about to read is a short, true story that details how I went from idea to solution, using the “UNIX way” (divide a problem in little pieces, then jump each hurdle with the help of a domain-specific solution, and finally combine each response).

The story is — honest! — more about the underlying thought process than the technology I used — in fact, while I do know Python and I’ve grown white hairs using Linux, most of the stuff you’ll see here I taught myself in the course of this challenge.

TorrentFlux: what it is, how it works

TorrentFlux is a very interesting Web application you can install on your Web server. Once installed, it lets you in to a nice interface like any other BitTorrent program where you get to add .torrent files so the torrent gets downloaded directly in your Web server. Here it is:

Advantages of using TorrentFlux

The reasons to use such a program instead of a normal desktop BitTorrent client are varied:

• you would like to have a particular, big file (think Linux distro) right away on the server instead of uploading it through your ISP’s connection
• your ISP throttles or blocks BitTorrent (think Comcast)
• you would like to avoid downloading through 50 TCP connections at home, and just use one (think speedier Web browsing)
• you want to take advantage of the (usually) higher bandwidths available in your Web server during the day, and you’d like to download the file once it’s done, from beginning to end (think videos)
• you would like to queue up a download while away from home (think vacations)

Disadvantages

The disadvantages, compared to a regular BitTorrent client, are that:

• if you want the download in your PC, you need to queue it up separately in a download manager on your PC through FTP,
• you need to check TorrentFlux periodically to see if the torrent is done downloading, because you can’t download a torrent to your PC until the torrent is done,
• you can’t queue up downloads from TorrentFlux to your home PC if you’re away from your computer, can you?
• disk space might be limited in your Web server.

What we’ll do in this article is destroy these disadvantages.

The problem in a nutshell

From the aforementioned disadvantages we can clearly see what the problem is. Being the lazy bastards we are, we want the downloads in our home computer ASAP, without manual intervention. Our ultimate goal is to:

1. queue up a BitTorrent download in TorrentFlux, and
2. as soon as it’s finished, have our home PC automatically “check it out from the counter”, and then
3. erase the file from the TorrentFlux server.

Let’s go do it.

How I solved it

Remoting my server

How am I going to talk to my server? This question crossed my mind many times. In the end, I chose SSH, because it’s extremely easy to automate and have it work securely without constant interruptions — remember, we don’t want to be interrupted with password prompts or anything like it.

I wrote the code that more or less provided enough help for it to work. As programming languages go, Python is by far the best for the task at hand, so I used it. OK, I’ll admit it, I’m a Python junkie:

#!/usr/bin/env python

from subprocess import Popen,PIPE,STDOUT,call import fcntl import re import os import sys import signal

def getstdout(cmdline): p = Popen(cmdline,stdout=PIPE) output = p.communicate()[0] if p.returncode != 0: raise Exception, "Command %s return code %s"%(cmdline,p.returncode) return output def getstdoutstderr(cmdline,inp=None): # return stoud and stderr in a single string object p = Popen(cmdline,stdin=PIPE,stdout=PIPE,stderr=STDOUT) output = p.communicate(inp)[0] if p.returncode != 0: raise Exception, "Command %s return code %s"%(cmdline,p.returncode) return output def passthru(cmdline): return call(cmdline) # return status code, pass the outputs thru def getssh(cmd): return getstdout(["ssh","-o","BatchMode yes","-o","ForwardX11 no",torrentflux_server] + [cmd]) # return stdout of ssh. doesn't return stderr def sshpassthru(cmd): return call(["ssh","-o","BatchMode yes","-o","ForwardX11 no",torrentflux_server] + [cmd]) # return status code from a command executed using ssh

Interesting, isn’t it? Now I have two functions:

• one that gets me the text of a command executed by SSH, and
• another that discards the text but returns the return value of the executed command — which, if you know the UNIX convention, it’s zero for success, and anything else for errors.

Determining which torrents are done

The first hurdle I need to surpass: which torrents from the torrent list are already done? After a little poking around the Web, I discovered that with the help of a command called fluxcli that ships with TorrentFlux, I can get a list of active torrents in text form.

So that’s solved. All I needed is some code that parses the rows returned, selects only those rows that say Done or Seeding in the status column, and that should return the name of each torrent that’s ready to download.

The code in question is this:

def get_finished_torrents():
        stdout = getssh("%s transfers"%fluxcli)
        stdout = stdout.splitlines()[2:-5]
        stdout = [ re.match("^- (.+) - [0123456789.]+ MB - (Seeding|Done)",line) for line in stdout ]
        return [ match.group(1) for match in stdout if match ]

Stupidly simple, and it makes use of the SSH remoting functions (dare I say hacks?) I wrote before. And, may I say, only three lines, really. It returns a list with the names of the torrents.

Next up, getting the file names inside the torrents.

Dicho de otra forma, este oficial tuvo la desfachatez de comentar que “los computadores de los usuarios se infectan con malware porque los usuarios son estúpidos”.

¿Te consideras tú, estimado lector, estúpido como para caer en el engaño del virus y el e-mail tramposo? ¿Eres tú, atento lector, lo suficientemente estúpido para instalar un virus en tu ordenador? ¿Eres tú, querido lector, lo bastante estúpido para ser inconsciente de que el último salvapantallas que has descargado contiene spyware?

Pues no. Nadie es suficientemente estúpido como para contagiar su computador de virus. Hoy te voy a explicar la razón por la cual los virus “aparecen por arte de magia” en tu computador, y tú te quedas rascándote la cabeza, preguntándote “¿qué hice mal?” y sintiéndote ignorante.

Lo siguiente que voy a relatar es una cadena completamente compuesta — no de “opiniones de expertos”, sino — de hechos de ingeniería de software:

• Para aquellos que no saben de ingeniería del software: un bug (defecto) es una condición en un programa de ordenador, resultado de un error humano en la etapa de creación del software.
• Normalmente, los bugs sólo disminuyen tu productividad. Sin embargo, algunos bugs pueden — por su naturaleza — acabar dando a software malicioso e indeseable (virus y demás) acceso completo a tu computador.
• Los ordenadores modernos, y sus sistemas operativos, utilizan distintas técnicas para mantener separados los programas. Los bugs modernos son las puertas por las que los virus y otros programas llegan a donde no deberían.

Esa es la verdad — en la ingeniería de software no existe el “por arte de magia”. El malware llega a tu computadora cuando el software que ésta tiene está lleno de bugs, ni más, ni menos. Sin bugs no es posible la actividad maliciosa. En otras palabras: con un sistema adecuadamente construido, sin bugs, ningún ataque de virus es posible, y (como en el triste caso de Microsoft Windows) no es posible obtener el control del ordenador o de la información que éste tiene. Es más: la única misión de los virus (programas maliciosos automáticos) y de los crackers (hackers malintencionados) es usar esos bugs para provecho propio. Sin bugs, no hay virus. Sin bugs, no hay hackers.

Lograr software 100% libre de bugs es muy difícil (algunos dicen que imposible), pero construir un sistema seguro es posible. Tan posible es, que ya ha sido logrado. Esto no es solo mi opinión o un deseo utópico. Esto es algo real, derivado directamente de las más vanguardistas técnicas científicas y de ingeniería de software.

El malware (software malicioso) continúa siendo un problema hoy en día. El único vehículo para que el malware continúe siéndolo es la poca calidad y las actitudes irresponsables de las empresas de software propietario (con su buque insignia: el sistema operativo Microsoft Windows).

Hoy, el Emperador está desnudo. Le han “fabricado un atuendo” totalmente transparente — y nadie se atreve a decirlo en voz alta. ¿Será que nadie lo quiere aceptar?

Las casas fabricantes de software propietario han logrado convencer al planeta entero de que la difusión del malware es responsabilidad de todos los usuarios de computadoras, a través de un esfuerzo concertado de relaciones públicas en los medios de comunicación principales, con actos como la corta cita del oficial de seguridad de Microsoft que mencioné antes.

Ellos han llevado al mundo a creer que los bugs de su software no solo son una inconveniencia inevitable, sino que además, tienes que pagar extra para protegerte con antivirus y antispyware. Y encima de todo, es “tu culpa” cuando un virus entra en tu ordenador.

Por supuesto, la extensión de una vulgar mentira como esta es sólo posible porque una microscópica parte de la población entiende la ingeniería del software. No tiene nada de malo no saber computación. Yo no sé nada sobre reparación de motores. ¿Y por qué debería saber?

Pero el argumento es simple: los ordenadores (como los hornos microondas) son la “magia negra” postmoderna — hocus pocus — y la gente, en ausencia de conocimiento, siempre tiende a creer lo que dice el “mago experto”. No hace mucho, la gente creía que una piedra de diez libras caía diez veces más rápido que una de una libra. Por supuesto, hoy, los “magos modernos” de la computación han logrado convencer a los demás de que los fallos de sus programas son “inevitables” y un “mal necesario”.

Por dentro, Microsoft Windows y programas afines tienen decenas de miles de bugs conocidos y (juzgando por las estadísticas disponibles) muchos más aún que permanecen desconocidos. Son pocos los días que pasan entre entre descubrimientos de bugs anteriormente desconocidos, bugs que los programas maliciosos usan continuamente para destruir tu trabajo y poner en peligro tu vida personal.

Querido lector: ¿tienes esperanza de estar sobre aviso ante el siguiente bug de Microsoft Windows? Lo siento, pero jamás lo sabrás porque ellos no te dejarán que mires por dentro. Jamás. Después de todo, no les conviene que sepas — iría en contra de sus intereses: romperte las piernas para luego venderte muletas, cada par más “efectivo” que el anterior.

¿Cómo ha podido Microsoft y las otras compañías de software propietario popularizar semejante patraña? Muy simple. Porque no has tenido otra opción que creer a los “expertos”. Jamás podrás probar que ellos están equivocados, porque ellos tienen el código fuente, y tú no.

Afortunadamente, tienes opciones. Usa software libre (open source). Usa Linux (te recomiendo Ubuntu, es completo, gratis y fácil de instalar y usar), Firefox, OpenOffice.org (a estos últimos dos los puedes probar en Windows también). Las auténticas innovaciones de seguridad y los avances más vanguardistas de la tecnología están ocurriendo en nuestro campo, no en el del software propietario.

El software libre es, simplemente, mejor. No quiero hacer de gurú ni de mago moderno. Por favor no me creas — compruébalo por ti mismo.

Let me quote from his article:

I’m often asked why I’m so obsessed with backward compatibility and, as a result, why I’ve made the issue such a central part of the LSB over the past year. Yes, it’s hard, particularly in the Linux world, because there are thousands of developers building the components that make up the platform, and it just takes one to break compatibility and make our lives difficult. Even worse, the idea of keeping extraneous stuff around for the long term “just” for the sake of compatibility is anathema to most engineers. Elegance of design is a much higher calling than the pedestrian task of making sure things don’t break.

Ian’s concern is simple: he wants backwards compatibility. In the vernacular, this means old applications must not malfunction in new systems. He recognizes, at the same time, that backwards compatibility is perceived as a rather laborious and unrewarding task, especially impeded due to the nature of our distributed development efforts.

He’s right about that, and I’m thankful that he’s pushing for more backwards compatibility. Let’s understand why.

A worthwhile goal it is

There are people out there who entertain this notion (or some variant thereof): Why shouldn’t an old application malfunction in a newer system? After all, “it’s just a matter of recompiling the old app on the new system”, right?

They couldn’t possibly be more mistaken.

Three fronts of compatibility

There are several main compatibility concerns:

1. ABI compatibility: Programs that use external (dynamic linking) libraries should have guarantees that updated (minor versions of) libraries won’t stop working in the future. Otherwise, a single library can yield an entire system unusable.
2. API compatibility: Applications written against a particular library (and version) should always compile against the latest (minor) version of that library.
3. Formats and protocols: Newer (foundational) developments shouldn’t break other, older applications that depend on them.

Sometimes, it’s impossible to “just recompile”

There are dozens of thousands of applications for Linux out there. Do you honestly think their users have access to the source code, or the required skills, to update them and make them work with newer Linux systems?

I didn’t think so, either. Gentooers comprise a minuscule share of Linux users. The rest of us want to install a package in seconds, and have it not break when another package is upgraded.

The huge hidden costs of not maintaining compatibility

Face it: eschewing compatibility in favor of the “new fashionable thing” saves a little time for the developer. But it makes everyone else incur in exploding hidden costs, which only increase with time.

Software isn’t like a car. Stable software applications tend to break only when the underlying set of assumptions (in general, “operating system and system-level apps”) change. Therefore, it’s vital that the underlying system stays as stable as possible.

Stability isn’t just “no blue screens”, you know?

Read it on my Turbocharged blog: Building a true home page into your WordPress blog

Después me agradecen

Yes, I’m aware that we could do the same with (at least) GTK+ buttons with a few layout containers packed in. Now, where’s the easy-to-use implementation in a vein similar to the Response abstractions in GTK+?

While doing routine tuning and checking of my weblog, I discovered a rather nasty slowdown with WordPress page generation. Taking the “scientific” route, I deactivated nearly all non-essential plugins in my Supercharged weblog (more than 40) and proceeded to activate them one by one, interspersing activations with ApacheBench tests.

A short plug: This post is brought to you by Supercharged. If you want to get these plugins in one package, consider getting Supercharged for your blog.

Really quick conclusions:

• WordPress (with the baseline plugins installed) is slow. On my server (not exactly the fastest thing in the planet, but dedicated to Web and database serving, and not bound by swapping or memory limits), it can’t pipe more than 1.5 front page views per second. I don’t think the load from ApacheBench accounts for more than 10% of the CPU usage.
• Do not install My Tube under any circumstances. Further investigation is pending.
• These plugins add negligible amounts of overhead. None of the plugins (except for My Tube) added detectable performance losses.
• bsuite seems to introduce a small slowdown.

The chart above shows the (rather unscientific, but effective) results of my short benchmark, in a nice bar chart (the taller, the better). This table represents the average KB/s for page generation after activating each plugin. Note that plugins were never deactivated after beig activated (except for My Tube, which I kicked out of the circuit). Thus, in a perfectly repeatable test scenario, you should see a ladder in the bar chart. Since you don’t see one, I can conclude that stacking my 40 plugins introduces negligible page generation performance overhead.

Caveats:

• I started with a plugin baseline of Akismet, Fold Page List, Fold Category List, PHP Markdown Extra, Redirectify, Software shop for WordPress, del.icio.us widget, Sidebar Widgets, WordPress allow dashes, WordPress AutoLink, Permalink redirect. There’s simply no way I can afford to turn these off in my live site.
• I hit my site with 100 requests using ab -n 1000 http://rudd-o.com/ executing on the Web host. Whenever I saw dramatic performance drops, I checked to see whether the load average was high, then waited for all other running processes to finish, and then re-tested
• As you can see, I only tested front page views.
• The base WordPress installation is a vanilla 2.0.3 + bug fixes setup. No caching options were modified or set.
• This is not a scientific test. Standard deviation is not reported. Since I was only looking major performance drops, minor differences (+/- 0.1 requests per second) can be accounted for the fact that tests were performed on the live site. Yes, that includes apparent “performance boosts” with some plugins active.
• Plugins that add template tags or widgets were added to the template/widget configuration for accurate representation.
• This benchmark does not measure page responsiveness or ancillary object loading times (JavaScript, images)

Here is the collected data:

baseline: Akismet, Fold Page List, Fold Category List, PHP Markdown Extra, Redirectify, Software shop for WordPress, del.icio.us widget, Sidebar Widgets, WordPress allow dashes, WordPress AutoLink, Permalink redirect:
Requests per second: 1.56 [#/sec] (mean)
Time per request: 642.467 [ms] (mean)
Transfer rate: 50.06 [Kbytes/sec] received

add: Canary Comment
Requests per second: 1.54 [#/sec] (mean)
Time per request: 649.238 [ms] (mean)
Transfer rate: 52.48 [Kbytes/sec] received

add Cache-Flush
Requests per second: 1.58 [#/sec] (mean)
Time per request: 634.240 [ms] (mean)
Transfer rate: 53.72 [Kbytes/sec] received

add Creative Commons Configurator
Requests per second: 1.54 [#/sec] (mean)
Time per request: 648.789 [ms] (mean)
Transfer rate: 54.52 [Kbytes/sec] received

add: Digg This
Requests per second: 1.47 [#/sec] (mean)
Time per request: 678.475 [ms] (mean)
Transfer rate: 52.13 [Kbytes/sec] received

add: Days Since Birth and Gravatars
Requests per second: 1.49 [#/sec] (mean)
Time per request: 669.963 [ms] (mean)
Transfer rate: 52.82 [Kbytes/sec] received

add: Inline ajax more
Requests per second: 1.67 [#/sec] (mean)
Time per request: 597.525 [ms] (mean)
Transfer rate: 61.60 [Kbytes/sec] received

add: In Series
Requests per second: 1.41 [#/sec] (mean)
Time per request: 707.612 [ms] (mean)
Transfer rate: 52.02 [Kbytes/sec] received

add: iG:CoComment
Requests per second: 1.61 [#/sec] (mean)
Time per request: 621.901 [ms] (mean)
Transfer rate: 59.19 [Kbytes/sec] received

add: Bread Crumb Trail Generator
Requests per second: 1.60 [#/sec] (mean)
Time per request: 623.195 [ms] (mean)
Transfer rate: 59.47 [Kbytes/sec] received

add: LMB^Box FilePress
Requests per second: 1.55 [#/sec] (mean)
Time per request: 646.917 [ms] (mean)
Transfer rate: 57.29 [Kbytes/sec] received

add: LMB^Box Comment Quicktags
Requests per second: 1.73 [#/sec] (mean)
Time per request: 577.145 [ms] (mean)
Transfer rate: 64.21 [Kbytes/sec] received

add: My Tube
Requests per second: 0.49 [#/sec] (mean)
Time per request: 2025.577 [ms] (mean)
Transfer rate: 18.39 [Kbytes/sec] received (at this point, I’m disabling My Tube)

remove: My Tube
Requests per second: 1.71 [#/sec] (mean)
Time per request: 585.946 [ms] (mean)
Transfer rate: 63.25 [Kbytes/sec] received

add: Optimal Title
Requests per second: 1.49 [#/sec] (mean)
Time per request: 671.295 [ms] (mean)
Transfer rate: 55.21 [Kbytes/sec] received

add: Related Posts
Requests per second: 1.73 [#/sec] (mean)
Time per request: 577.798 [ms] (mean)
Transfer rate: 64.14 [Kbytes/sec] received

add: Taragana’s Del.icio.us mp3 Player Plugin
Requests per second: 1.55 [#/sec] (mean)
Time per request: 646.751 [ms] (mean)
Transfer rate: 57.41 [Kbytes/sec] received

add: FancyTooltips
Requests per second: 1.51 [#/sec] (mean)
Time per request: 660.859 [ms] (mean)
Transfer rate: 56.59 [Kbytes/sec] received

add: Recent Comments (my edition adds a ‘Recent comments with excerpts’ widget)
Requests per second: 1.51 [#/sec] (mean)
Time per request: 664.122 [ms] (mean)
Transfer rate: 58.38 [Kbytes/sec] received

add: Sociable
Requests per second: 1.53 [#/sec] (mean)
Time per request: 652.300 [ms] (mean)
Transfer rate: 59.62 [Kbytes/sec] received

add: Subscribe me
Requests per second: 1.52 [#/sec] (mean)
Time per request: 659.224 [ms] (mean)
Transfer rate: 61.01 [Kbytes/sec] received

add: Search Meter
Requests per second: 1.49 [#/sec] (mean)
Time per request: 670.161 [ms] (mean)
Transfer rate: 60.02 [Kbytes/sec] received

add: Search Reloaded
Requests per second: 1.43 [#/sec] (mean)
Time per request: 699.615 [ms] (mean)
Transfer rate: 57.49 [Kbytes/sec] received

add: Text Link Ads
Requests per second: 1.43 [#/sec] (mean)
Time per request: 699.958 [ms] (mean)
Transfer rate: 57.46 [Kbytes/sec] received

add: WP Lightbox 2
Requests per second: 1.41 [#/sec] (mean)
Time per request: 706.736 [ms] (mean)
Transfer rate: 57.67 [Kbytes/sec] received

add: Write Post Find and Rudd-O’s Wordspew
Requests per second: 1.44 [#/sec] (mean)
Time per request: 695.128 [ms] (mean)
Transfer rate: 59.01 [Kbytes/sec] received

add: BlogSpy for WordPress
Requests per second: 1.45 [#/sec] (mean)
Time per request: 688.703 [ms] (mean)
Transfer rate: 59.66 [Kbytes/sec] received

add: XFish Meta
Requests per second: 1.40 [#/sec] (mean)
Time per request: 714.832 [ms] (mean)
Transfer rate: 57.57 [Kbytes/sec] received

add: WP-SlimStat
Requests per second: 1.41 [#/sec] (mean)
Time per request: 708.787 [ms] (mean)
Transfer rate: 58.06 [Kbytes/sec] received

add: AutoMeta
Requests per second: 1.38 [#/sec] (mean)
Time per request: 725.395 [ms] (mean)
Transfer rate: 56.73 [Kbytes/sec] received

add: bsuite (my edition has some bug fixes by me)
Requests per second: 1.21 [#/sec] (mean)
Time per request: 827.565 [ms] (mean)
Transfer rate: 49.72 [Kbytes/sec] received

Nonces alone sound very stupid to me. Instead of having implemented nonces alone, what the WP team should have been doing all along is obvious: every action that is not idempotent should be done through POST. Technically, it’s quite simple. Programmatically, it’s harder to do than GETs. But surely coding GETs + nonces must be much harder than simply coding POSTs.

No one is discussing how useful nonces are. They are useful. But in the context of the greater picture, they’re used to avoid WP admins from being tricked — which is exactly why POSTs should be used as well. Sure, POSTs alone don’t buy us a whole lotta security. But they surely do buy us some.

(Please don’t tell me I haven’t read the whole thread. The fact that nonces were introduced does not contradict one iota the fact that POSTs should be used for destructive operations, and that’s it.)

Update: to visitors from the #wordpress channel: I updated the article, correcting statements of fact. I’m very glad to see that you’re receptive to the POST idea. It’s no surprise that it has been floated before as an issue.

<?php

/* Plugin Name: BlogSpy for WordPress Version: 0.0.1 Plugin URI: http://rudd-o.com/ Description: Automates inclusion in the BlogSpy network Author: Manuel Amador (Rudd-O) Author URI: http://rudd-o.com/ */

/* Code licensed under the GNU GPL v2 */

function blogspy_footer() { print '<script src="http://spy.foxcorp.org/spy.js" type="text/javascript"></script>'; }

add_action("wp_footer","blogspy_footer");

?>

Graba este código en un archivo llamado blogspy.php y colócalo en tu directorio wp-content/plugins en tu Web host de WordPress. Actívalo a través de la pantalla de administración de plugins de WordPress, and that’s it! Ya estás en BlogSpy.

En algún momento lo haré un plugin propiamente dicho, disponible para descargar. Por lo pronto, que te aproveche.

Of course, the (now quite old) debate between Linus Torvalds and Andy Tanenbaum is an amusing read. But let’s not confuse “amusing read” with statement of fact. Both Linus and Andy were “stating the obvious while standing on their camp”. Both were stating facts to defend their position, but they rarely (if at all) discussed their assumptions that led each one to choose their strategies and defend their facts as true.

Let’s recall:

• Linus Torvalds reminds Andy Tanenbaum that monolithic kernels are both faster and easier to develop for
• Andy Tanenbaun advocates microkernels because they have much stronger fault isolation between “servers”

(in microkernel parlance, the word “server” is used to describe a set of related responsibilities running as an independent process or thread).

Again, let’s state the obvious… we’ll talk about the consequences of each kernel design philosophy right after this:

• Monolithic kernels have one distinguishing characteristic: all kernel processes share the same address space. In layman’s terms, this means that one kernel process can directly manipulate kernel data or code.
• Microkernels divide responsibilities among different processes in different address spaces (”hybrid” microkernels can, however, share one address space, but then what’s the point of doing a microkernel?). No “server” can touch other servers’ memory, and they’re forced to communicate among each other by passing messages.

Now, let’s discuss the consequences of each different approach.