Acabo de probar el soporte de escritura de particiones NTFS en Linux usando el driver ntfs-3g y la verdad es que tiene muy buenta pinta.
Hay instrucciones muy claras en esta página en HowToForge y yo lo he hecho siguiendo esas.
También hay información similirar en los foros de Ubuntu (parece que también en español) y en el Wiki de información mantenida por la comunidad de Ubuntu
Hace ya años que practicamente no programo casi nada, hoy me ha entrado vena melancólica así que me he dedicado a buscar algunas pequeñitas contribuciones que hice hace ya tiempo a algunos proyectos de software libre, concretamente GTK y GNOME. Hacía poco que tenía acceso a Internet y estos creo que fueron los primeros parches que envié a un proyecto de software libre allá por 1998, así que lo voy a dejar apuntado aquí para cuando me vuelva a poner melancólico.
Son un par de parches chorras de cuando GTK+ aun estaba en sus comienzos, uno de ellos es de antes de la versión 1.0, pero por algo se empieza. En el
Sun Mar 1 15:18:38 PST 1998 Shawn T. Amundson <amundson @gimp.org>
* Required changes for version change to 0.99.4
* gtk/gtktree.[ch]: patch from J. Bolliet to correct some bugs
* gtk/testgtk.c: added test here from J. Bolliet, removed testtree
* gtk/clist: <a href="ftp://ftp.gimp.org/pub/gtk/patches/outdated/old/1998-02/gtk-abilleira-981602-0.patch.gz"><b>gtk-abilleira-981602-0</b></a>, allows gtk_clist_set_pixmap
and gtk_clist_set_pixtext to not require a mask
* gdk/gdkdraw.c,gdk.h: gtk-trow-980217-0
adds gdk_draw_lines and fixes some things about
gdk_draw_polygon
Hace referencia a este parche con esta descripción
Tue Aug 11 13:07:29 1998 Owen Taylor <otaylor@redhat.com> (<a href="http://ftp.gtk.org/pub/gtk/patches/applied/1998/gtk-abilleira-072198-patch.gz"><b>gtk-abilleira-072198-patch</b></a>) * gtk/gtkwindow.[ch]: Add gtk_window_set_modal() which sets a flag; when set the window does a gtk_grab_add() when the window is shown, and a gtk_grab_remove() when the window is hidden. * gtk/gtkfilesel.[ch]: Test if it is running in modal form and in that case will run "Create Dir","Delete File" and "Rename File" dialogs as modal too. * gtk/testgtk.c: Added a button with an example of creating modal dialog boxes. Including file selection and color selection standard dialogs.
Y este hace referencia a este parche con esta descripción
Para Octubre me habían dado una cuenta en el CVS de gnome y pude subir yo mismo, ya no un parche, sino un nuevo componente pequeñito, que no era otra cosa que un botón para elegir fuente. Este es el envio al repositorio de los ficheros correspondientes. Nada menos que hace 8 años y cinco meses, luego empecé a trabajar y poco a poco dejé casi de programar. Una pena.
1998-10-14 David Abilleira <odaf@nexo.es> * <a href="http://svn.gnome.org/viewcvs/libgnomeui/trunk/libgnomeui/gnome-font-picker.c?view=markup&pathrev=842">gnome-font-picker</a>.[c<a href="http://svn.gnome.org/viewcvs/libgnomeui/trunk/libgnomeui/gnome-font-picker.h?view=markup&pathrev=842">h</a>] New widget for selecting a font from a simple to use button. This is equivalent to gnome-color-picker but to select fonts. * gnome-font-picker-ico.png and .h. Default ico to show inside the button. At this moment header file generation is not automated because I don't want to modify Makefile.am until I know which is the right place to put the icon * libgnomeui.h: Added gnome-font-picker.h to the list of headers. * Makefile.am: Added gnome-font-picker.[ch] to the sources.
Recientemente he leído una noticia referente a importantes desarrolladores del kernel de Linux impulsando el que sea imposible utilizar módulos para el kernel de Linux que no tengan licencia GPL a partir del año 2008.
La opinión sobre algunos desarrolladores del kernel sobre si los drivers No-GPL violan el texto de la licencia GPL v2 que es la que rige las condiciones de distribución y uso del kernel de linux ya la conocía hace tiempo y no es sobre eso sobre lo que que quería comentar hoy.
Lo que me ha llamado positivamente la atención es la opinión que ha expresado al respecto Linus Torvads (ver Linus Torvalds). Es muy interesante, asemeja la actitud hiper-restrictiva que algunas personas dentro de la comunidad intentan imponer sobre el software por medio de las leyes de propiedad intelectual y de las licencias con el la actitud similar de las discográficas que estas mismas personas suelen criticar por abusiva. Mas que comentar es mejor que, quien sepa un poquito de inglés y le interese Linux lea el correo enlazado arriba.
De todos modos, me gustaria citar un pequeño párrafo. El asunto es que la licencia GPL según la FSF considera el hecho de que dos programas enlacen dinámicamente uno con otro como que son un único programa, y traducido al texto de la GPL vendría significar que si un programa es licenciado como GPL el otro se consideraría una modificación de este, un trabajo derivado.
Este es un fragmento del comentario de Linus respecto a si deben intentar poner medidas técnicas para impedir que módulos que no llevan licencia GPL enlacen con el kernel de Linux:
The fact is, the reason I don't think we should force the issue is very simple: copyright law is simply _better_off_ when you honor the admittedly gray issue of "derived work". It's gray. It's not black-and-white. But being gray is _good_. Putting artificial black-and-white technical counter-measures is actually bad. It's bad when the RIAA does it, it's bad when anybody else does it. If a module arguably isn't a derived work, we simply shouldn't try to say that its authors have to conform to our worldview.
Un traducción libre podría ser la siguiente:
El asunto es, la razón por la que no creo que debamos hacer el asunto obligatorio es muy simple: es mejor dejar fuera las leyes de copyright cuando reconocemos el asunto gris de lo que es un “trabajo derivado”. Es gris. No es blanco-o-negro. Pero es bueno que sea gris. Poner por medios técnicos medidas en contra es en realidad malo. Es malo cuando la RIAA lo hace, es malo cuando lo hace cualquier otro.
Si un módulo razonadamente no es un trabajo derivado, nosotros simplemente no debemos intentar decir que sus autores deber conformarse a nuestra visión del mundo
Linus ya ha expresado que no le agradan los drivers propietarios, y que el lugar correcto para un driver que quiera asegurar su funcionamiento es dentro del kernel oficial y con por tanto con la licencia del kernel. Precisamente por eso es bueno saber que en este mundo donde existe una gran tendencia a imponer a los demás, alguien de la influencia de Linus Torvalds renuncia a usar esa influencia para forzar a otros, cuyo trabajo no considera derivado real del suyo, a ver el mundo como él lo ve.
He decidido probar la nueva Ubuntu 5.10 y me está causando una muy buena impresión, aunque he tenido algún pequeño problema.
Uno de ellos está relacionado con el programa de contabilidad Gnucash que al leer el documento con mi contabilidad se comía todos los acentos, eñes y similares.
La causa resultó ser que el pobre Gnucash que anda flojo de desarrollo ultimamente se atraganta con la codificación UTF-8 que es a la que todas las distribuciones tienden y a la que Ubuntu ya ha cambiado. El fichero original fue creado usando el juego de caracteres ISO-8859-15 (Europa Occidental con símbolo de Euro), y al leerlo en una distribución que por defecto utiliza UTF-8 se lia.
¿La solución? Puedes verla en este bug que he reportado en el Launchpad.
¡Qué “traballiño” me ha dado el cambio de servidor esta vez! Por fortuna parece que ahora todo está funcionando bien.
No voy a contar la historia larga, porque me estuvo volviendo loco durante 6 días pero anticipar que he de advertir sobre el kernel intalado con la Mandrakelinux 10.1 y con la transición a udev que ha habido en esta versión.
Cada pocas horas de funcionamiento el servidor dejaba de responder, ninguno de los servicios de red que tenía funcionando respondía. La consola del servidor no respondía a las pulsaciones del teclado, aunque si lo hacían las luces Caps/Num/Scrl Lock. A pesar de eso el kernel seguía enrutando.
Tras tener que reiniciar, al mirar en /var/log/messages, en ninguna de las ocasiones pude ver que el cuelgue dejase algún rastro. Algo superextraño.
Hardware: Me pasé varios días quitando, cambiando, poniendo componentes y volviendo a dejar encendido el ordenador hasta que volvía a colgarse.
Soporte USB: Ya había tenido algún problema con el soporte USB con esta versión y equipos AMD con chipset VIA, por lo que desactivé todo el soporte USB en la BIOS y en el sistema. Sin éxito
Kernel: Cada vez parecía más un problema de kernel, actualizé a la última versión disponible en 10.1 Community (kernel-2.6.8.1.20mdk-1-1mdk).Sin éxito.
Desde el Domingo 7 hasta el Viernes 12 me pasé toda la semana probando cosas, más que las que aparecen arriba, incluso volví a instalar el sistema desde cero en otra partición. Todo sin éxito.
Finalmente probé a descargar la última actualización del kernel disponible para la versión anterior de Mandrakelinux, la 10.0, concretamente el paquete kernel-2.6.3.19mdk-1-1mdk y con eso no volvió a quedarse colgado.
Uno de los cambios entre la Mandrakelinux 10.0 y la 10.1 es el cambio del modulo que crea los ficheros que representan a los dispositivos en /dev automáticamente. En la 10.0 es devfs y la 10.1 udev. Como el último kernel que instalé es para la 10.0 el sistema me arrancó usando devfs y no udev que es lo que usaba hasta ahora. Desconozco si es un problema del kernel en general o de udev en particular, el caso es que: ¡por fin funciona!.
Como consecuencia de todos estos problemas el servidor ha estado caido mucho tiempo durante bastantes días y es probable que haya perdido algo de correo.
Una última batallita, si algún día veis una opción en la BIOS de vuestro PC para que si al arrancar no detecta el ventilador del micro apague el ordenador mucho cuidado con ella. Ayer la activé en este servidor que tanto trabajo me había dado, y lo que conseguí fue que ya no volviese a arrancar porque, por alguna razón no detectaba el giro del ventilador o no lo hacía a tiempo. Todo eso a pesar de que el ventilador marcaba correctamente la velocidad. Con eso empezé una aventura de varias horas en las que casi me cargo la placa base del servidor intentando borrarle la CMOS en una placa cuyo manual no documentaba la manera….. en fin, ¡batallitas!
Las vacaciones se han acabado, de vuelta al trabajo y a las cosas de casa.
En el proceso de preparar el servidor que va a reemplazar a este, me he encontrado con la tarea de configurar el servidor IMAP para el correo. El servidor de correo que he escogido es Courier IMAP y la instalación no supuso demasiados problemas. Bueno alguno debido a que había creado los buzones (los “Maildir”) como root y me olvide de cambiar el dueño a cada usuario.
Lo que me dió algunos problemas más ha sido poder usar el certificado digital que yo quería. En el fichero /etc/courier/imapd-ssl, está la opción TLS_CERTFILE=/usr/share/courier/imapd.pem que indica que fichero contendrá el certificado digital con el que se identificará el servidor.
Algo que desconcierta un poco es que en Apache el certificado está en un fichero y la clave privada está en otro, mientras que Courier IMAP solo te permite decirle un fichero. La explicación es que en ese fichero debes meter las dos cosas. ¿Cómo mezclar los ficheros?.
Es más fácil de lo que parece pero antes una referencia a la única página que encontré esplicando como hacerlo: http://milliwaysconsulting.net/support/systems/courier-ssl.html.
La idea es que openssl por defecto genera los ficheros en formato PEM que es un formato de texto y que un único fichero PEM se puede concatenar el contenido de varios. En la página de arriba lo explica bastante bien.
Algunas cosas que tener en cuenta y de las que uno se puede olvidar son:
Otro sitio donde mirar para ver cómo hacerlo es en el script mkimapdcert que viene con Courier IMAP.
Como nota final y aunque no tiene que ver con SSL le aumenté el nº máximo de conexiones por cliente (MAXPERIP) porque sino Mozilla daba error al intentar establecer demasiadas conexiones con el servidor
El Jueves vio la luz la nueva Mandrakelinux 10.1 Community disponible por ahora solo para los miembros de Mandrakeclub. El mismo jueves la puse a descargar con Bittorrent y este fin de semana la he empezado a probar.
Con el fin de restringir el acceso via bittorrent solo a los miembros del Club, lo que hacen es que cuando te bajes via web el fichero del torrente, para lo cual tendrás que haberte autentificado antes, apuntarán la dirección IP desde la que te conectaste y permitirán la descarga desde esa IP.
La idea es buena pero…. pero está el proxy transparente de Telefonica de España no funciona. La razón es bastante obvia, cuando pedimos una página web el proxy de Telefonica intercepta la petición y la hace él en nuestro lugar para quedarse con una copia del resultado, pero, al hacer esto la dirección que Mandrake registra es la del proxy y la nuestra. Cuando luego queremos descargarno el fichero, como no es una conexión a la web (puerto 80) la conexión es directa desde nuestra dirección y Mandrake nos rechaza porque la dirección no está autorizada.
Esto dio muchos pero muchos quebraderos de cabeza cuando se empezó a usar este sistema. Al final la solución escogida por Mandrakesoft fue habilitar el servidor web en un puerto diferente al estandar, el 8080, y como Telefónica no intercepta las conexiones a ese puerto, la IP que Mandrakesoft registra es la nuestra como siempre debió ser.
Como en Mandrakesoft han estado perezosos al distribuir en esta versión para poner los enlaces alternativos para los que estamos detrás de un proxy transparente, lo que tenemos que hacer es lo siguiente:
Cogemos la dirección a la que apunta el enlace de la descarga, será del estilo de: https://www.mandrakeclub.com/torrent.php?f_=...................................... Ponla en la barra de direcciones y cambiale https por http (sin la s, sin ir cifrado), y añadele al nombre de la máquina :8080 para indicar que se conecte por el puerto 80, o sea algo como: http://www.mandrakeclub.com:8080/torrent.php?f_=..................................
Sencillo quitar la s y añadir :8080 y al descargarse ese fichero de torrente será nuestra dirección IP real la que quede registrada.
Después de terminar la descarga es conveniente y educado el dejar el bittorrent funcionando para compartir con otros lo que te has bajado por lo menos hasta compartir lo mismo que has descargado, así que, yo aun lo tengo compartiendo y lo dejaré unos cuantos días más.
Lo he instalado en mi puesto de trabajo y las primeras impresiones son excelentes, la instalación muy fluida, y el hardware perfectamente detectado. Las nuevas X (xorg-x11-6.7.0) van estupendamente. Creo que ha sido un gran avance el fork obligado por el mal funcionamiento de quienes mantian XFree86. Por lo demás mis primeras impresiones con Gnome 2.6 son muy buenas. El escritorio se nota más ágil que el 2.4 y creo que no tendré problemas en adaptarme a la nueva filosofía de trabajo del gestor de archivos que se integra cada vez más en el propio escritorio.
He tenido algunos pequeños problemillas instalandolo en el equipo del trabajo debido a que aquí es necesario configurar un proxy para acceder a Internet, y aunque lo configuré al instalar, luego tuve que volver a configurarlo en las herramientas de actualización y aun así para configurar las fuentes de actualización lo tube que hacer a mano pro que MandrakeUpdate no funcionaba bien. Por lo demás todo funciona muy bien y con un rendimiento excelente.
Me ha sorprendido gratamente la cantidad de software disponible en la distribución. Una vez se configuran las fuentes de paquetes main y contrib desde un mirror ftp, tienes a tu disposición y ya empaquetado un montón de software. Yo por ejemplo he configurado main y contrib desde el ftp de rediris:
Muchas aplicaciones que antes tenía que descargar y compilar a mano ya están empaquetadas. Por ejemplo, para unir fotografías y crear panorámicas de increible calidad están empaquetados Hugin y enblend.