Con el detector de actualizaciones de FileHippo (vía menéame) que acabo de re-descubrir (se me había olvidado) me ha dado por hacer un experimento: actualizar todo el soft instalado en el portátil.

Ciertamente el detector de actualizaciones agiliza la tarea. Sólo hay que ejecutarlo e ir instalando una a una las cosas que haya detectado. Desgraciadamente, hay que irles dando una a una: primero descargar el instalador de turno, luego ejecutarlo, y luego darle las veces necesarias al botón de "continuar" de turno.

Resultados finales Windows XP:

Número de programas: 35
Clicks: 328
Descarga: 691MB
Tiempo dedicado: 1 hora 42 minutos

Para contrastar, el mismo experimento en Kubuntu:

Número de paquetes: 419
Clicks: 7
Descarga: 130MB
Tiempo dedicado: 35 segundos

Vamos, ni yo me esperaba tanta diferencia, simplemente flipante. Como para ir actualizando todos los días, ¡ja!

Tras los últimos problemas de disco duro, en los que por suerte no he perdido nada importante gracias al RAID que tengo montado, he decidido dar un poco más en la configuración de discos.

Esta vez: journals cruzados para aumentar la velocidad.

La parte más compleja de esta configuración, realmente está sobre el papel. Una vez decidido dónde van los journals, es todo mucho más simple que el paso de root a RAID.

El journal se graba de forma síncrona en disco, lo que significa que para cada operación en disco se debe primero grabar los datos del journal en una posición, y luego desplazar el cabezal del disco a la posición donde se graban los datos en sí. Dado que la mayor pérdida de tiempo en los discos duros viene por los tiempos de acceso, situar el journal en un disco diferente hace que el rendimiento aumente de forma espectacular.

Es más, al usar el modo "data=ordered" (opción por defecto al crear ext3), se requiere otro desplazamiento más, pues la secuencia es: desplazar cabezal, grabar datos a disco (sin sobreescribir), desplazar cabezal, grabar metadatos al journal, desplazar cabezal, grabar metadatos al disco.

Dado que la cantidad de metadatos a grabar es bastante pequeña, y es lo único que se graba de forma síncrona (en modo ordered) se puede lograr incluso un mayor aumento de rendimiento usando una memoria USB cualquiera. Aunque su velocidad de lectura/grabación sea bastante inferior a la de un disco duro, las velocidades de acceso suelen ser varios órdenes de magnitud superiores a las de estos.

En este caso sin embargo, he optado por una configuración en la que no tenga que conectar nada "externo" al equipo. La pérdida de un journal externo requiere reconfigurar los discos antes de poder seguir usándolos, cosa que preferiría que no ocurriese por algo tan tonto como quitar una memoria USB. Tal vez si pudiese ponerla dentro de la caja del PC... pero no me quedan más puertos libres en la placa base.

Pasos a seguir, en el post ampliado.

Read more »

Hace poco me he pasado de Mandriva a Kubuntu, y una de las primeras cosas que he notado ha sido la falta de botones para cambiar rápidamente entre modos de vista.

Bueno, realmente ahora no tengo tiempo para escribirlo en condiciones. Ahí van unos apuntes en sucio para quien le interese.

This is a dynamic list of actions. You can move it, but if you remove it you won't be able to re-add it.


~/.kde/share/apps/konqueror/konqueror.rc
...
<gui>
 <MenuBar>
  ...
 </MenuBar>
 ...
 <ToolBar newline="true" noMerge="1" name="locationToolBar" fullWidth="true" >
  <text>Location Toolbar</text>
  <Action name="back" />
  <Action name="forward" />
  <Action name="up" />
  <Action name="home" />
  <Action name="reload_stop" />
  <ActionList name="viewmode_toolbar" />
  <Action name="clear_location" />
  <Action name="toolbar_url_combo" />
  <Action name="go_url" />
 </ToolBar>
 ...
</gui>


http://en.archive.ubuntu.com/ubuntu/pool/main/k/kdebase/kdebase_3.5.6.orig.tar.gz
http://en.archive.ubuntu.com/ubuntu/pool/main/k/kdebase/kdebase_3.5.6-0ubuntu20.diff.gz


patch -p1 < kdebase_3.5.6-0ubuntu20.diff


kdebase-3.5.6/debian/patches/kubuntu_84_group_toolbar_viewmode_icons.diff


+++ kdebase-3.5.4.new/konqueror/iconview/konq_iconview.desktop  2006-09-26 19:12:13.000000000 +0200
@@ -81,8 +81,5 @@
 X-KDE-BrowserView-AllowAsDefault=true
 X-KDE-BrowserView-HideFromMenus=true
 X-KDE-BrowserView-Args=IconView
-X-KDE-BrowserView-ModeProperty=viewMode
-X-KDE-BrowserView-ModePropertyValue=IconView
-X-KDE-BrowserView-Built-Into=konqueror
 Icon=view_icon
 InitialPreference=10


sudo vi /usr/share/services/konq_iconview.desktop
	X-KDE-BrowserView-ModeProperty=viewMode
	X-KDE-BrowserView-ModePropertyValue=IconView
	X-KDE-BrowserView-Built-Into=konqueror

sudo vi /usr/share/services/konq_multicolumnview.desktop
	X-KDE-BrowserView-ModeProperty=viewMode
	X-KDE-BrowserView-ModePropertyValue=MultiColumnView
	X-KDE-BrowserView-Built-Into=konqueror

/usr/share/services/konq_*
	/usr/share/services/konq_detailedlistview.desktop
	/usr/share/services/konq_iconview.desktop
	/usr/share/services/konq_infolistview.desktop
	/usr/share/services/konq_multicolumnview.desktop
	/usr/share/services/konq_textview.desktop
	/usr/share/services/konq_treeview.desktop

sudo vi /usr/share/services/konq_treeview.desktop
	X-KDE-BrowserView-ModeProperty=viewMode
	X-KDE-BrowserView-ModePropertyValue=TreeView
	X-KDE-BrowserView-Built-Into=konqueror


http://changelogs.ubuntu.com/changelogs/pool/main/k/kdebase/kdebase_3.5.6-0ubuntu20/changelog

Con la instalación del "mandriva-kde-config-common-2007.1-7mdv2007.1", o lo que es lo mismo la configuración de PowerPack de Mandriva, no se les ha ocurrido mejor cosa que hacer, que tocar las narices al personal con un "icono de inicio personalizado".

Mandriva


KDE

Sería razonablemente comprensible... si no fuera por dos detalles:

1. es enorme, casi 4 veces más ancho que el icono de KDE
2. no hay forma fácil de quitarlo por menús o asistentes (que haya visto)

Tal vez vaya siendo momento de ir abandonando Mandriva, que parece alejarse cada vez más del público de escritorio. Grave fallo, me parece a mí (para servidor sigue siendo mejor Debian/Ubuntu o Gentoo).

En fin, para quitar el molesto icono, se puede hacer en dos pasos y de dos formas diferentes (para todos los usuarios, o para un usuario concreto).

Todos los usuarios

Primero, editar el fichero de kickerrc del nuevo tema:

/var/lib/mandriva/kde-profiles/powerpackplus/share/config/kickerrc

# KMenuIcon=mdv_kmenu
KMenuIcon=kmenu

Y lueg, reiniciar kicker; matándolo a pelo y arrancando a mano (Alt+F2 y "kicker"), reiniciando las X, o por medio de DCOP:

dcop kicker kicker restart

Esta configuración se aplicará a todos los usuarios, pero en la siguiente actualización del theme de Mandriva es posible que se pierdan los cambios.

Un solo usuario

Si queremos forzar la configuración en el usuario, evitando que se pierda en las actualizaciones, tendremos que editar la configuración personalizada de kicker del usuario (kickerrc). Pero antes de modificar este fichero, tenemos que parar kicker para que no lo sobreescriba al cerrarse:

kill kicker

Ahora, editamos:

~/share/config/kickerrc

[KMenu]
KMenuIcon=kmenu

Y arrancamos kicker:

kicker

De esa forma ya no aparecerá la monstruosidad de icono... en los próximos tiempos, hasta que inventen alguna otra forma de meterlo.

Apéndice

También es posible cambiar el KMenuIcon a cualquier otro icono o imagen que nos guste. El fichero en concreto se encuentra en múltiples resoluciones en:

/var/lib/mandriva/kde-profiles/powerpackplus

./share/icons/crystalsvg/16x16/apps/mdv_kmenu.png
./share/icons/crystalsvg/22x22/apps/mdv_kmenu.png
./share/icons/crystalsvg/32x32/apps/mdv_kmenu.png
./share/icons/crystalsvg/48x48/apps/mdv_kmenu.png
./share/icons/crystalsvg/64x64/apps/mdv_kmenu.png
./share/icons/crystalsvg/128x128/apps/mdv_kmenu.png

Basta añadir los ficheros que queramos usar en los directorios correspondientes, poner el nombre en KMenuIcon... y a disfrutar.

Como siempre, voy con retraso en los posts, dejando cosas apuntadas para "pulirlas" más tarde... y ahí se quedan, muertas de risa.

Por ejemplo esta: la semana pasada, he vuelto a batir mi propio record de uptime, esta vez casi duplicándolo:

Fecha: 24 de Enero de 2007, a las 19:53:14
Uptime: 82 días, 1 hora y 29 minutos

A punto ha estado de llegar a los 90 días, casi 3 meses redondos

Todo esto se lo debo principalmente al SAI, un MGE Merlin Ellipse 500 que lleva ya unos cuantos años protegiendo al servidor de apagones inesperados. La primera causa son micro-cortes debidos a rayos, suficientes como para apagar la luz un instante (unos 100ms) y reiniciar cualquier cosa que no esté protegida, como los monitores.

Sin embargo, no estaría aquí hablando de un nuevo "récord", si no fuese porque el servidor por fin estiró la pata. Se quedó colgado totalmente, aparentemente encendido pero con la pantalla en negro y el teclado sin responder. Tras numerosas pruebas de arranque, unidas a que tengo aquí al lado un PC prácticamente igual (PII/800), sospecho que puede haber sido culpa de unos condensadores reventados en la placa base, ¡otra vez!

Hace ya unos años, por estas mismas fechas, tuve que jubilar al viejo PII/350 por esta misma causa. En esa ocasión los condensadores llegaron a chorrear literalmente por toda la placa, dejando marcas corrosivas en pistas e integrados. Un espectáculo dantesco. Esta vez sólo he localizado cuatro condensadores algo reventados por arriba, que llevaban así más de medio año, así que no sé si será realmente esa la causa.

19 Julio 2006

24 Enero 2007

A primera vista no parece haber mucha diferencia

Aparte de eso, también resultó que estaba tocada la tarjeta gráfica, pasando a mostrar el color rojo sólo en bloques de líneas alternos. Posiblemente sea cosa de alguna parte de un DAC o chip de memoria o algo. Aparte de eso parece funcionar correctamente -especialmente teniendo en cuenta que apenas se usa, y eso sólo en modo texto- pero claro, ahora ya cualquiera se fía para dejarla 24h/365d.

Por lo menos no pasó nada con la memoria (768MB SDRAM) ni los discos duros, así que ahora el nuevo servidor va sobre un RAID-1 con 3 discos... que probablemente sean el siguiente punto que salte por los aires

En el mundo *NIX -por ejemplo Linux- los permisos de acceso a ficheros se controlan -sin entrar en ACLs- por medio de las maścaras de permisos de usuarios y grupos.

El funcionamiento parece bastante intuitivo; cada usuario o tiene o no tiene un determinado tipo de permiso (escritura, lectura, ejecución) sobre un determinado fichero, en función de si el fichero es propiedad del usuario, o si el usuario es miembro del grupo al que pertenece el fichero, o ninguna de las dos.

Lo que no suele ser tan intuitivo, es que los grupos pueden ser tanto grupos de usuarios como grupos de ficheros. De hecho, el uso más común de los grupos es este segundo.

Grupos positivos (~ de ficheros)

Por ponerle algún nombre, se podría considerar "positivos" o "aditivos" a los grupos que añaden permisos a usuarios que de otra forma no los tendrían sobre determinados ficheros.

Ejemplo: rwxr-x--x evaristo informes

Un usuario "marta" no podría leer el contenido del fichero sino sólo ejecutarlo, de forma que al añadirle al grupo "informes" ya podría leerlo, aunque sólo evaristo podría modificarlo.

Desde este punto de vista, cada usuario tendría acceso a todos los ficheros cuyo grupo fuese cualquiera de aquellos a los que perteneciese el usuario.

Grupos negativos (~ de usuarios)

En vez de usarlos para añadir permisos, los grupos también pueden servir para quitarlos.

Ejemplo: rwx---r-- evaristo usuarios

Dado que los permisos se evalúan en la primera coincidencia de usuario, grupo u otros (por este orden), un usuario "marta" que perteneciese al grupo "usuarios" no podría leer este fichero del usuario "evaristo". Sin embargo, usuarios como "apache" -no perteneciente al grupo "usuarios" sino tal vez al de "demonios"- sí podrían acceder en modo lectura a este fichero.

Visto de esta forma, se pueden crear grupos de exclusión mutua de usuarios pertenecientes a ellos, permitiendo el acceso sólo a los propietarios y a todos los demás usuarios (demonios, auditoría, etc.).

Para controlar correctamente las reglas de exclusión, y aunque suene un poco contradictorio, cada usuario debe pertenecer a todos los grupos de los que deba estar excluido.

Grupos mixtos (zanahoria y palo)

También es posible mezclar ambas interpretaciones de los grupos, permitiendo a los usuarios miembros acceder a determinados ficheros pero al mismo tiempo excluyendo el acceso mutuo a otros.

Se puede interpretar esta estrategia como un "algo a cambio de algo"; permitir acceder a determinadas herramientas o documentos, a cambio de ser excluido del acceso a los datos de los demás usuarios con acceso a esas mismas herramientas o documentos.

No es la mejor estrategia para gestionar un sistema fácilmente mantenible, pues normalmente es recomendable mantener los grupos de adición y de exclusión separados para tener una mayor claridad en la gestión, pero no deja de ser una posibilidad en un momento concreto.

O mejor dicho: ¿cómo subir vídeos a YouTube sin que vuelva a recomprimirlos?

Los FLV por dentro son H.263 o VP6 para vídeo y MP3 para audio, así que no se puede meter un MPEG o DivX a pelo, hay que recomprimir. Sin embargo, Lo que sí se puede hacer en YouTube es convertir las cosas a FLV antes de subirlas para evitar que las recomprima, consiguiendo de paso que los vídeos se publiquen casi al instante sin tener que esperar a la recompresión.

Las opciones de mencoder que suelo usar son:

mencoder origen -o destino.flv \
-vf scale=320:240 \
-ffourcc FLV1 \
-of lavf -lavfopts i_certify_that_my_video_stream_does_not_use_b_frames \
-ovc lavc -lavcopts vcodec=flv:acodec=mp3:abitrate=56 \
-srate 22050 \
-oac lavc


También podría servir con el avi2swf de swftools o, claro está, con el conversor de vídeos de Flash.