COMO hize funcionar mi impresora HP PSC 1410 All-in-one

Sencillo de realizar.
Bueno de exponer lo que cada uno a aprendido para facilitar el trabajo de otros.
Para poder imprimir y escanear en Ubuntu usando la impresora multifunción HP PSC 1410.

Todo lo que este a continuación de $ debe ser escrito en un terminal/shell .

  1. Yo necesite tener la impresora encendida antes de arrancar Ubuntu.
  2. Instalar los paquetes hpoj, hpijs y xsane:

    $ sudo aptitude install hpoj hpijs xsane

  3. Configurar el escáner:

    $ sudo ptal-init setup (seguir los pasos de la configuración)

  4. Arrancar ptal-init:

    $ sudo ptal-init start

  5. Configurar impresora:

    $ gnome-cups-manager
    (Pinchar en nueva impresora y seguir los pasos para activarla).

  6. Ahora solo queda probarlo todo.

Podemos abrir openoffice e imprimir un documento cualquiera. Para el escáner abrimos xsane y ya podremos escanear nuestra maravillosa mano. Por fin, toda la vida queriendo el escáner para algo útil y lo teníamos tan cerca (también se puede usar la mano de otra persona).

Hay otra aplicación llamada hplip que mejora a hpoj pero cuando lo instalé yo no soportaba la el modelo de HP PSC 1410.

Subversion Server. Howto

Here you can find how to prepare a subversion repository and its integration with Apache 2.

You need apache with webDAV to access repository content using http or https protocol. If you prefer not to use apache, then you should use svnserve (prefered in daemon mode). This will mean using svn protocol.
Be careful with firewalls (see ahead).
And, of course, always better with Debian.

Subversion for repository administrators (using Apache 2)

In order to create a repository you need to follow these steps (do it in a root shell).

Install the needed packages:

  • apache2
  • subversion
  • libapache2-svn

Add next rules to your host in Apache 2. In Debian a mostly equal config (that you should modify) exists under /etc/apache2/mods-available/dav_svn.conf
Configuration sniplet:

< Location /svn>
# Uncomment this to enable the repository,
DAV svn
# Set this to the path to your repository
# SVNPath /var/lib/svn
# SVNParentPath /var/lib/svn/repository
SVNPath /var/lib/svn/repository
# The following allows for basic http authentication. Basic authentication
# should not be considered secure for any particularly rigorous definition of
# secure.
# to create a passwd file
# # rm -f /etc/apache2/dav_svn.passwd
# # htpasswd2 -c /etc/apache2/dav_svn.passwd dwhedon
# New password:
# Re-type new password:
# Adding password for user dwhedon
# #
# configuration for mixed authenticated/anonymous access
Satisfy Any
Require valid-user
# Uncomment the following 3 lines to enable Basic Authentication
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /etc/apache2/dav_svn.passwd
# Uncomment the following line to enable Authz Authentication
# AuthzSVNAccessFile /etc/apache2/dav_svn.authz
# The following three lines allow anonymous read, but make
# committers authenticate themselves.
Require valid-user
< /LimitExcept>

(Important: Don’t use a DocumentRoot setting for this virtual host!”)

Restart apache with or reload apache configuration without finishing open connections with (prefered)

root@maquine:~ $ /etc/init.d/apache2 reload
root@maquine:~ $ apache2ctl graceful (prefered)

Create the repository and create a password file:

root@maquine:~ $ svnadmin create /var/lib/svn/repository
root@maquine:~ $ htpasswd2 -c /etc/subversion/passwd [username]
root@maquine:~ $ chown -R www-data:www-data /home/svn

Don’t forget to make the repository accessible for your web server:

To test it, try accessing it with a browser or try to check out the file:

user@maquine:~ $ lynx http://localhost/svn
user@maquine:~ $ svn co http://server/svn

(You will not be prompted for credentials. That’s normal.)

Voila. The repository is set up.
You can check a ready setup in

Subversion for repository administrators (using subversion protocol)

You just need to put on work svn server.

user@maquine:~ $ ls -la /var/lib/svn/
total 1
drwxr-xr-x 4 root www-data 96 2005-06-06 00:45 .
drwxr-xr-x 56 root root 1480 2005-06-03 17:00 ..
drwxr-x— 7 root www-data 224 2003-02-20 00:37 project1
drwxr-x— 7 root www-data 224 2004-11-15 21:23 project2
user@maquine:~ $ svnserve -d -T -r REPOSITORY_DIR (Example 1: /var/lib/svn/project1/ – Example 2: /var/lib/svn/)

(-d: daemon, -T: spawn a thread instead of a process for each connection, -r root: root repository)

Try to check out the file:

user@maquine:~ $ svn co REPOSITORY_URL (Example 1: svn://server/ – Example 2: svn://server/project1/)

Voila. The repository is set up.

Subversion for repository users

To checkout (=download) the files in the repository for the very first time run this command::

user@maquine:~ $ svn co http://server/svn

Don’t worry about other people working on the same files. Just do your changes to the files and when you seem to have a stable state (make sure everything works well enough so not everything will break for others) you should check in(=upload) your work:

user@maquine:~ $ svn ci

(Only when committing your changes you will be prompted for your username and password.)

Run the following command regularly to get the changes from other contributors::

user@maquine:~ $ svn update

If you want to add new files to the repository::

user@maquine:~ $ svn add [filename]

To get a status of which files have changed::

user@maquine:~ $ svn stat

Subversion for local repositories

This type of installation is used when you want subversion to track your local files but don’t want/need to put it on a host. You can create a local repository and access it directly. This repository is not password protected and it’s permissions depend on the filesystem’s permissions.

Install the needed packages (as root or with sudo) and create the repository (with your user):

root@maquine:~ $ apt-get install subversion
root@maquine:~ $ svnadmin create /home/joe/repositorie

The url to your repository is it’s path preceeded with file://. For example to checkout you would do the following:

user@maquine:~ $ svn co file:///home/joe/repositorie

Subversion firewall rules

In order to acces your subversion repository using svn protocol you should reconfigure your firewall or update daemon config.
If you need to access subversion remotely, by default it runs on port 3690 using TCP.

Resources and comments

Original Authors: Christoph Haas, Tiago Cogumbreiro
Modified by: Enrique Garcia

Viewvc (previously viewcvs)

Right now viewcvs is the old version which is available under Debian. I recomend to install the latest viewvc from official website until package gets updated.
For more about it’s history, look up in
Instalation is really simple, it’s only complexity resides in the apache 2 configuration. Which is not really well documented and can cause some headache.


Download here latest stable version from viewvc

I will install everything under /opt because it’s my favourite place (and because it’s standar (LSB rules I think) to put extrange things there).

user@machine:~$ cd /opt
user@machine:~$ wget
user@machine:~$ tar -xvzf viewvc-1.0.3.tar.gz
user@machine:~$ cd viewvc-1.0.3
user@machine:~$ ./viewvc-install

[will be prompted some easy questions] Answer first /opt and then leave it as it is.

Take a look at INSTALL and README. It’s always good to read this stuff, and doesn’t hurt.

user@machine:~$ emacs /opt/viewvc/viewvc.conf
[main changes I made]
user@machine:~$ diff viewvc.conf ../viewvc-1.0.3/viewvc.conf.dist
< #cvs_roots = cvs: /home/cvsroot --- > cvs_roots = cvs: /home/cvsroot
< svn_roots = svn: /var/lib/svn/repository --- > #svn_roots = svn: /home/svnrepos
< default_root = svn --- > default_root = cvs
< mime_types_file = /etc/mime.types --- > #mime_types_file = /usr/local/apache/conf/mime.types
< address = < a href="mailto:svn-admin@XXX.XXX">Administrador del repositorio Subversion< / a>

> address = < a href="">No admin address has been configured< / a>
< languages = es-es, en-us --- > languages = en-us
< docroot = /viewvc-doc --- (LOOK APACHE 2 CONFIG TO EXPLAIN THIS CHANGE) > #docroot = /docroot
< use_enscript = 1 --- > use_enscript = 0
< use_highlight = 1 --- > use_highlight = 0
< use_php = 1 --- > use_php = 0
< allow_tar = 1 --- > allow_tar = 0

For coloured syntax I installed next packages. But I am not really sure they are needed.

user@machine:~$ apt-get install highlight enscript

Apache 2 configuration

Here I put my apache 2 configuration for viewvc. I’ve two versions, both of them work. Again I recomend take a take a look at INSTALL and README for answers. One is the version for cgi and the other for mod_python. I’m using mod_python because it’s known to be faster.


< IfModule !mod_python.c>
< IfModule cgi.c>
# para la instalacion local
ScriptAlias /viewvc /opt/viewvc/bin/cgi/viewvc.cgi
# para el paquete debian
# ScriptAlias /viewsvn /usr/lib/cgi-bin/viewcvs.cgi
< /IfModule>
< /IfModule>


< IfModule mod_python.c>
Alias /viewvc-doc “/opt/viewvc/templates/docroot”
ScriptAlias /viewvc /opt/viewvc/bin/mod_python/
< Location /viewvc>
AddHandler python-program .py
# This appends “our path” to python path
PythonPath “[‘/opt/viewvc/bin/mod_python’] + sys.path”
PythonHandler handler
PythonDebug On
< /Location>
< /IfModule>

Look the result at

Resources and comments

Screen: Guía rápida para empezar

Screen es una herramienta genial para trabajar con varias sesiones a la vez desde una misma terminal.

Yo principalmente lo uso para control remoto de máquinas.
Otro de los usos más comunes es para compartir una consola con otros usuarios, de forma que todos trabajen o vean a la vez la misma línea de comandos.
No obstante, seguro que hay más usos.

De lo más interesante que nos aporta screen es que se pueden recuperar consolas/sesiones. Es como tener una terminal siempre abierta en un equipo remoto. Aunque se corte la conexión y estés haciendo alguna tarea crítica no vas a perder lo que estés haciendo, puedes volver a conectarte y allí estará todo tal y como estaba antes de la desconexión .
Un buen ejemplo de uso es si estas administrando remotamente una máquina. Se te ocurre hacer un apt-get install y se corta la conexión. Pues luego ándate con ojo, que lo mismo algo se ha quedado a medias y tienes dependencias rotas o que se yo.
No hablemos si haces cualquier otra cosa un poco más crítica, como un formateo de disco o una copia o desplazamiento de ficheros….

Ejemplo de uso

Bien, para empezar de forma rápida a usarlo un ejemplo.
Conectamos con la máquina remota, ejecutamos:

user@host $: screen -U

-U es para tener soporte para unicode uft-8
Para salir de screen y dejarlo corriendo tecleamos la secuencia < Control > + a d. Os saldrá lo siguiente:

user@host $: screen -U

Pues para recuperar screen hacemos:

user@host $: screen -r -d

-r -d Reattach a session and if necessary detach it first.. Recuperamos la sesión seguro.

El último comando que recomiendo es el maestro de maestros, para no memorizar nada, tenemos la fantástica ayuda instantánea de la secuencia < Control > + a ? que nos mostrará todos los atajos.

Accesos rápidos

Key Action Notes
Ctrl+a c new window
Ctrl+a n next window I bind F12 to this
Ctrl+a p previous window I bind F11 to this
Ctrl+a ” select window from list I have window list in the status line
Ctrl+a Ctrl+a previous window viewed
Ctrl+a S split terminal horizontally into regions Ctrl+a c to create new window there
Ctrl+a :resize rezize region
Ctrl+a :remove remove region Ctrl+a X is the same
Ctrl+a tab Move to next region
Ctrl+a d detach screen from terminal Start screen with -r option to reattach
Ctrl+a A set window title
Ctrl+a x lock session Enter user password to unlock
Ctrl+a [ enter scrollback/copy mode Enter to start and end copy region. Ctrl+a ] to leave this mode
Ctrl+a ] paste buffer Supports pasting between windows
Ctrl+a > write paste buffer to file useful for copying between screens
Ctrl+a < read paste buffer from file useful for pasting between screens
Ctrl+a ? show key bindings/command names Note unbound commands only in man page
Ctrl+a : goto screen command prompt up shows last command entered

Referencias y enlaces:

Probando FlowPlayer

Ahora que está tan de moda (y es que mola) lo de poner vídeos que se reproducen rápidamente he decidido incluir el mío propio.
No tanta mierda de ni leches. Si google se quiere gastar más de 1000 millones de €…, será porque les cuesta poco ganarlos.
¿Para qué depender de otros cuando lo puedes hacer tú mismo? Bastante censura me aplico, como para que de repente me dejen sin vídeo porque no entra en su política de contenidos.

Encima FlowPlayer, que es como se llama el bicho, mola más.
Sólo falta que gnash termine de funcionar para poder mandar al carajo a macromedia y su flash plugin. Y es que en mis pruebas, gnash mostraba una especie de garabatos que más bien parecían Picassos en movimiento que vídeos.

Por supuesto flowplayer no es mío, pero como si lo fuera, porque tiene licencia Apache 2.0 (otra licencia de código libre, casi compatible con GPL). Página web del proyecto FlowPlayer

Estaremos en fase de pruebas, dependiendo del ancho de banda que me consuma.

¿Cómo usarlo?

Los ejemplos son de su página. Parece todo bastante fácil.

Lo primero, transformar el vídeo al formato de vídeo flash, el FLV.
Para transformar una película en formato FLV (desde un original: .mp4 .mov .mpg .3gp .mpeg .wmv .avi), seguir los siguientes pasos:

El comando flvtool2 añade la duración del vídeo en los metadatos del archivo FLV. FlowPlayer lee la información de duración del archivo FLV y la muestra. Así pues, los metadatos del archivo FLV se pueden insertar mediante flvtool2.

ffmpeg -i movie.[avi] -s 320×240 -ar 44100 -r 12 movie.flv
cat movie.flv | flvtool2 -U stdin movie.flv

Yo concretamente me voy a estrenar con el vídeo de la ocupación multitudinaria y molona de Ikea en Barcelona.

Para instalar flvtool2 he utilizado el directorio /opt, que para eso está.

$ ruby setup.rb config –prefix=/opt –siterubyver=/opt/lib/site_ruby/1.8
$ ruby setup.rb setup
$ ruby setup.rb install

(Para instalar, según los permisos que tengas en opt, puedes necesitar ser superusuario)

Para ejecutar flvtool2, al no usar directorios estándar que suelen estar en los $PATH, … se me ha ocurrido crear un miniscript conteniendo:

ruby -I /opt/lib/site_ruby/1.8 /opt/bin/flvtool2.ruby $@

El script de bash lo he llamado flvtool2 y el archivo flvtool2 lo he renombrado a flvtool2.ruby

Tras eso he creado el archivo…

ffmpeg -i -s 320×240 -ar 44100 -r 12 ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv

cat ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv | flvtool2 -U stdin ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv

Vaya, me sale el error:

/opt/lib/site_ruby/1.8/flv/amf_string_buffer.rb:163: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [i486-linux]
/opt/bin/flvtool2: line 2: 14262 Abortado ruby -I /opt/lib/site_ruby/1.8 /opt/bin/flvtool2.ruby $@

Pues mi buscador me dice que mire en Using Lighttpd, Mplayer/Mencoder and Flvtool2 to Implement Flash Video Streaming
y allí me indican sustituya en /opt/lib/site_ruby/1.8/flv/amf_string_buffer.rb la línea 163 :

    write [(time.to_i * 1000.0)].pack('G')
    write [(time.to_f * 1000.0)].pack('G')

Repito lo mismo

cat ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv | flvtool2 -U stdin ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv

Ahora ya no da ningún error.

Como colofón quiero incluir el modo que tiene que muestra también una lista de imágenes en miniatura de diferentes instantes del vídeo. Pero no va. A ver si me contesta el autor cómo va el tema este.
El comando usado para empotrar en el flv las miniaturas se supone que es el siguiente.

flvtool2 -AUt tags.xml ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv

El contenido del fichero tags.xml

En último lugar edito el ejemplo de código html que se debe poner en la web para adaptarlo a mi caso particular:

<object type=”application/x-shockwave-flash” data=”/wordpress/wp-content/plugins/flowplayer/FlowPlayerLP.swf” width=”420″ height=”340″ id=”FlowPlayer”>
<param name=”allowScriptAccess” value=”sameDomain” />
<param name=”movie” value=”/wordpress/wp-content/plugins/flowplayer/FlowPlayerLP.swf” />
<param name=”quality” value=”high” />
<param name=”scale” value=”noScale” />
<param name=”wmode” value=”transparent” />
<param name=”flashvars” value=”baseURL=/wordpress/wp-content/archivos/&videoFile=ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv&thumbsOnFLV=true&loop=false” />

El resultado final:



Página web del proyecto flvtool2
Página web del proyecto FlowPlayer

Firewall en Debian/Linux. Guardog vs Firestarter

Hace tiempo leía yo en algún lugar

On Tue, 30 Mar 2004, XXX YY wrote:
> Listeros, unas preguntas. Estoy recibiendo estos mensajes en consola :
> Mar 30 11:20:22 mail kernel: martian source 192.168.x.x from 192.168.x.x, on dev eth1
> Mar 30 11:20:22 mail kernel: ll header: ff:ff:ff:ff:ff:ff:00:0b:db:18:fe:3d:08:00
> ¿Qué son?

En todo caso, lo que está diciendo es que por la interfaz eth1 se recibió un paquete cuya dirección de origen es _imposible_ a la luz de la actual configuración de interfaces/tabla de rutas; en otras palabras, por esa interfaz nunca podría venir un paquete con la dirección que vino, por tanto es un paquete “marciano” que, de paso, es obvio con sólo mirar el encabezado “extraño” [3].

Quizás alguien está haciendo spoofing, o bien alguna máquina tiene una muy mala configuración IP.

> ¿Son un problema?

Si, paquetes inesperados que llegan por un camino por el cual no pueden llegar indica algún problema de audacia (cracker), indolencia (administrador que no configuró correctamente los segmentos IP) o incoherencia (interfaces/tablas de rutas no cónsonas con la necesidad).

Usando paquetes como éstos se pueden atacar vulnerabilidades remotas en stacks TCP/IP (¿cuáles?, ahora no se me ocurre ninguna particular, pero las hay). Usando las IP que ocultaste, la MAC que aparece presentada en el encabezado, un sniffer, arping y otras herramientas similares puedes determinar cuál es la máquina que está generando esos paquetes y golpear al dueño con algún objeto contundente.

Por eso es un paquete marciano.

> ¿Cómo puedo correjir el problema?

Revisa las tres posibilidades anteriores: spoofing, mala configuración IP en los clientes, mala configuración IP en el servidor.

[1] Las máquinas en una red IP _nunca_ deben llamarse como “lo que hacen” sino con un nombre único, preferiblemente siguiendo un tema. Lo que haces no es más que un “rol”, y como los roles cambian pero los nombres no, se utiliza un alias (CNAME en DNS) para asociar roles a nombres. Eso permite comenzar con una sola máquina que tenga todos los roles, y luego agregar máquinas y cambiar roles… pero el resto de la configuración puede quedar exactamente igual, en particular para los clientes y sus aplicaciones que suelen ser los más afectados cuando hay cambios de máquinas servidoras.
[2] El syslog acompaña cada mensaje con el nombre de la máquina origen, porque puede configurarse para que reciba todos los mensajes de todas las máquinas, cosa que es más práctica porque así hay un sólo sitio donde estudiar logs.
[3] La primera parte del encabezado (ff:ff:ff:ff:ff:ff) corresponde a la dirección MAC origen, que corresponde al broadcast local. Digo que es muy obvio porque _nunca_ se usa ese tipo de direcciones en un intercambio Ethernet:
a. Cuando el origen conoce al destino, ambos serán MACs específicas.
b. Cuando el origen no conoce al destino, el origen será una MAC específica y el destino será ff:ff:ff:ff:ff:ff (esto es un caso de ARP).
c. Cuando el origen no conoce su dirección IP y quiere averiguarla, el origen será 00:00:00:00:00:00 y el destino será ff:ff:ff:ff:ff:ff (esto es RARP, BOOTP y/o DHCP).
d. No hay otro caso.
El kernel sabe tanto IP e Ethernet como el Comer, así que puede sacar la misma conclusión que yo y decir que hay algo anormal en el paquete, en consecuencia la notificación.

*** Fin correo electrónico de la persona XXX YY

De Cortafuegos y Firewalls

Aunque GNU/Linux goza de buena salud en seguridad y velocidad de respuesta para cerrar fallos nunca está demás configurar un Cortafuegos (firewall).
Los eruditos dicen que *BSD son más seguros. Más rápidos es corregir fallos. Presumen de ello. Yo no digo que si, ¿ni que no?, porque aun no he probado a usar un sistema *BSD.

Yo conozco dos grandes soluciones para el diseño de los mismos. Guardog y Firestarter. Porque aquí tu puedes diseñar tu cortafuegos, quieres saber lo que hace.

Uno me permite diseños complejos de enrutado, etc. Es Guardog que se usa junto con Guidedog para permitir NAT o redireccionamiento de puertos, creo, yo lo uso únicamente para NAT.
La pareja Guardog-Guidedog es mágica. Te permite diseñar redes pensando en zonas. Tal y como se diseñan las redes. El día que se configure mediante dibujos (tal y como lo explican en la Universidad) será la bomba.

Pantallazos de Guardog y Guidedog:

Otro me permite blindar una sola máquina. Firestarter. También tiene interfaz de monitorización.

Pantallazos de Firestarter:

Existe otro programa que permite control remoto e interactividad en tiempo real. No recuerdo el nombre pero si que estaba en Debian. Si alguien se interesa lo puedo buscar o lo puede buscar (ya sabiendo que existe).
Permite interactividad con las reglas según llegan los paquetes a las colas de recepción y envio. Pero no es tan bonito y “usable” como los de “esto que pase, esto que no” destinados a window$. Además que lo de tu si vale, se termina haciendo pesado y muchas veces ni prestas atención con tal de que desaparezca el mensajito.

A los especialistas y los puristas estos artilugios les incomodan. A mi me mola, porque lo de las reglas de los cortafuegos me parece un coñazo sobervio. Quisiera saber mucho más del tema, pero quiesiera ser especialista en tantas cosas que no me cunde el tiempo.
Estas herramientas son muy cómodas por tanto.

Referencias y enlaces

Otra vez GNU/Linux y su coste estimado de desarrollo.

Ya hablé hace tiempo del coste estimado de desarrollo de GNU/Linux pero me pareció que los datos que aportaba no eran de suficiente actualidad.

He tardado mucho en publicar esta entrada, la tenía guardada desde hace muchos meses.

Leía poco después en las listas de un estudio realizado por profesores de la Universidad Politécnica de Madrid y la Universidad Rey Juan Carlos de riguroso interés.
Son 4 páginas de las que resalto algunos detalles interesantes

Los cálculos se han estimado sólo para la rama main (no se ha considerado ni contrib ni nonfree).

La verdad es que los ojos te hacen chirivitas. :shock_tb:

A día 6 de Junio de 2005:

La distribución Debian es producida por el proyecto Debian, un grupo de cerca de 1499 voluntarios.

…hay más de 8,600 paquetes fuente. El release completo comprende cerca de 15,300 paquetes de binarios…

La siguiente tabla de resumen por lenguajes de programación del número de líneas de código de Debian Sarge.

Lenguaje Lineas de código fuente Porcentaje (%)
C   130,847,000 57
C++ 38,602,000 16.8
Shell 20,763,000 9
LISP 6,919,000 3
Perl 6,415,000 2.8
Python 4,129,000 1.8
Java 3,679,000 1.6
FORTRAN 2,724,000 1.2
PHP 2,144,000 0.93
Pascal 1,423,000 0.62
Ada 1,401,000 0.61
Totales 229,496,000 100

Below 0.5% there are some other languages such as Objective C (0.37%), ML (0.31%), Yacc (0.29%), Ruby (0.26%), C# (0.23%) or Lex (0.10%). A number of other languages score less than 0.1%.

COCOMO model are as follows:
Total physical SLOC count: 229.495.824
Estimated effort: 714.440,52 person-months (59.536,71 person-years). Formula: 2,4 * (KSLOC^1,05)
Estimated schedule: 105,84 months (8,82 years). Formula:2.5 * (Effort^0,38)
Estimated cost to develop: 8,043,000,000 USD
To reach these figures, each project was estimated as though it had been developed independently, which is true for nearly all cases.
For calculating the cost estimation, we have used the mean salary for a full-time systems programmer in 2000 according to Computer World – 56,286 USD per year – and an overhead factor of 2.4.

Gráfico. Tamaño de paquetes frente a líneas de código representadas en escala logarítmica para Debian 3.1 Sarge.

Sistema Operativo Lineas de código fuente
Microsoft Windows 3.1 (Abril 1992) 3,000,000
Sun Solaris (Octubre 1998) 7,500,000
Microsoft Windows 95 (Agosto 1995) 15,000,000
Red Hat Linux 6.2 (Marzo 2000) 17,000,000
Microsoft Windows 2000 (Febrero 2000) 29,000,000
Red Hat Linux 7.1 (Abril 2001) 30,000,000
Microsoft Windows XP (2002) 40,000,000
Red Hat Linux 8.0 (Septiembre 2002) 50,000,000
Fedora Core 4 (versión previa; Mayo 2005) 76,000,000
Debian 3.0 (Julio 2002) 105,000,000
Debian 3.1 (Junio 2005) 229,500,000

El número de paquetes continua creciendo y doblándose casi cada dos años

También encontré desde aquel momento a esta parte otra página dedicada a estimaciones de Debian, supongo que del mismo grupo de investigadores.
General Statistics for Debian Sarge Code Counting
SLOCCount Web for Debian Sarge: Packages
SLOCCount Web for Debian Sarge: General Graphs

El artículo en formato PDF “Measuring Libre Software Using Debian 3.1 Sarge as a case study”

Algunas de las referencias del artículo:

Y eso que es de hace más de un año. ¿Cómo andará la cosa ahora?

Crear imágenes de disquetes

Hoy vamos a crear una imagen de un disquete.

Hoy nos ponemos un poquito retro.
Ahora que las disqueteras no las usa ni su inventor, pues nosotros las sacamos a relucir.

Tan sólo tenemos que tener… todas las herramientas necesarias.

Primero hay que crear una imagen vacía. La llamaremos “disquete.img”

usuario@maquina:~$ dd if=/dev/zero of=disquete.img bs=512 count=2880

Ahora hay que preparar la imagen para ser montada como dispositivo loopback.

root@maquina:~$ losetup /dev/loop0 disquete.img

Se crea el sistema de ficheros, por ejemplo como MSDOS.

root@maquina:~$ mkdosfs /dev/loop0

Finalmente se monta en /mnt/midisquetera

root@maquina:~$ mkdir /mnt/midisquetera
root@maquina:~$ mount -t msdos /dev/loop0 /mnt/midisquetera