Acelerar el comienzo de las XWindows
Hola, aqui os adjunto un documento sacado de "www.planetalinux.com.ar" acerca de como acelerar el comienzo de las XWindows que además incluye un poquitillo de "Hacking", confieso que lo he probado con óptimos resultados en mi sistema FreeBSD 4.4, así que os recomiendo seguir detalladamente los pasos. Si tienen problemas con el arranque de las XW. pueden escribirme a: [email protected] que prometo intentar ayudaros a resolver los problemillas. Sin mas os dejo con el autor de dicho documento que es Dardo A. Valdez, un estudiante de ingeniería informática de Jujuy, Rca. Argentina. Saludos a todos los camaradas que día a día, trabajan por una internet mejor.
*Icarokar-Wolfstonecraft*
La idea de escribir estas líneas tuvo origen en el hecho de no encontrar casi ningún texto en castellano sobre los temas que trata el artículo; en general todo lo que explico aquí lo leí en inglés. Espero que le sirva a los que gustan de hackear X.
Si bien X Window es rápido para ejecutar aplicaciones, en general tarda un poco en iniciarse (aunque es difícil notarlo en máquinas con configuraciones no tan antiguas); también se puede agregar que las distintas distribuciones aportaron lo suyo, y en su afán de simplificarle la vida al usuario, han puesto a correr en background (de fondo, sin que se vea nada), demonios (residentes) de dudosa utilidad real para el usuario en general.
Un poco de teoría...
X es rápido teniendo en cuenta la carga de imágenes, íconos varios y otros agregados de los entornos modernos (GNOME, KDE, etc.) al Window Manager de los viejos tiempos. Solo suele ser un poco lento a la hora de iniciarse, esto es porque al hacerlo hay muchos procesos (programas) que deben ejecutarse y sucede que X al iniciarse no se comporta como una aplicación multithread (multihilo) ...[Pausa]
¿Qué es multihilo?
En pocas palabras quiere decir que un programa es capaz de ejecutar separadamente distintos procesos (varios programas), es algo más técnico que eso, pero por ahora basta con esa aclaración.
[Play]...
Cuando iniciamos un entorno, digamos GNOME, hay varias aplicaciones que intentan iniciarse simultáneamente: un Window Manager, un panel de menu, íconos del administrador de archivos, la imagen del fondo de escritorio, distintos demonios en background: hotkeys, portapapeles (p/cortar y pegar), sonido, salvapantallas, etc. Y cómo X Window no se comporta al iniciar aplicaciones como multihilo, intenta ejecutarlos a todos al mismo tiempo dando y quitando tiempo de ejecución a cada uno de ellos, lo que aumenta apreciablemente el tiempo de ejecución individual (de cada aplicación) y por lo tanto el tiempo total que tarda X en cargarse...
Ahí es donde nos ponemos a pensar... entonces una Xterm que ejecutemos al inicio de X tarda más en iniciarse que si la cargamos luego de iniciado X (en realidad, cargarla al inicio de X es lo que hace que tarde más,)...
En programación un método para acelerar la ejecución de varios procesos (o programas) por parte de una aplicación no multihilo es hacer que los ejecute uno por uno, mejor dicho uno DESPUES del otro (secuencialmente)...
Conclusión: Para acelerar el inicio de X Window vamos a ejecutar los programas que se inician habitualmente, pero secuencialmente, uno después del otro.
Hackeando el inicio de X (lo básico)
Lo vamos a hacer desde la consola, para poder iniciar y apagar X mientras vemos cómo aumentamos la velocidad a la que se carga. Tenemos opciones, o entramos directamente en modo consola (si sabés cómo), o si entraste en modo gráfico saltamos al modo consola así:
CTRL + ALT + F1 [Enter]
(con esto saltamos desde el entorno gráfico a una consola)
Logeate como root, luego hacé:
init 3 [Enter]
(esto te manda al modo consola, si querés más datos, fijáte al final del artículo el anexo Niveles de Inicio)
Recomiendo el uso de Midnight Commander para trabajar con agilidad en la consola, para ejecutarlo hacé (en la consola):
mc [Enter]
y para ver y ocultar la línea de comando (con MC ejecutándose):
CTRL + O [Enter]
Para crear un archivo nuevo (y vacío):
touch nombre_del_archivo_nuevo [Enter]
(a la carga...)
Para acelerar el inicio de X usaremos una aplicación de línea de comando llamada Xtoolwait. Resumiendo medianamente bien lo que explica la página man de xtoolwait (que está en inglés), esta aplicación sirve para ejecutar, durante el inicio de X un proceso detrás de otro (los programas a ejecutar se leen de un archivo) dejando para ejecutar al final un determinado programa... o sea, lo nosotros estamos buscando hacer:
(mi archivo para Xtoolwait)
A & wmpid=$!
xtoolwait B
xtoolwait C
wait $wmpid
Puse las comillas de más arriba pues Xtoolwait más bien deja en espera el proceso y sigue con los demás, básicamente hace lo mismo que en un inicio normal pero a su manera (o sea, más rápido).
Más o menos esa es la idea (pero la sintaxis del archivo es la correcta). Créase o no, este tipo de inicio acelera espectacular y apreciablemente (no exagero), la velocidad con que se inicia X. Ver más información sobre Xtoolwait en el anexo al final del artículo.
Cómo se inicia X desde la consola normalmente (sin xtoolwait)
Básicamente con:
startx [Enter]
En pocas palabras, lo que hace startx (que es un script ubicado en /usr/X11R6/bin ), es iniciar el servidor X y luego cargar todos los programas habituales (como dije antes): un Window Manager, un panel de menu, íconos del administrador de archivos, la imagen del fondo de escritorio, distintos demonios en background: hotkeys, portapapeles (p/cortar y pegar), sonido, salvapantallas, etc.
Para crear tu propio inicio acelerado (un script en realidad), usaremos otro comando: xinit, que tiene una utilidad parecida a startx y más tarde combinaremos su uso con xtoolwait.
Lo que hace xinit es lanzar (ejecutar) el servidor X y luego carga una serie de programas que va leyendo línea por línea desde un archivo llamado .xinitrc , obviamente vos podés crear uno personalizado en tu directorio de usuario pero si no lo tenés existe uno por defecto en /etc/X11/xinit. La manera de usar xinit es:
xinit [Enter]
(lo que ejecuta el .xinitrc que exista: si tenés uno personalizado, ese, sino el que está por defecto).
Un archivo .xinitrc personalizado de ejemplo:
xsetroot -solid black &
gmc --no-windows &
sawfish
Nota muy importante: como se ve, al final de cada línea (excepto la última), hay un ampersand (el símbolo en el teclado es &), este signo hace que los programas iniciados se ejecuten en background (de fondo), solo el último programa se ejecuta normalmente. Esto tiene un fin: al finalizar el programa que no está en background (que no tiene &) finalizamos la sesion X, por lo general siempre se coloca al final al binario que inicia el Window Manager (pero puede haber excepciones).
Para probar cremos el .xinitrc de ejemplo en nuestro directorio de usuario (HOME); desde la consola cambiamos a él rápidamente con:
cd $HOME [Enter]
Otra nota importante: xinit aparte de leer por defecto el archivo .xinitrc que exista, soporta leer cualquier archivo que le indiquemos (funciona, obviamente si el archivo en cuestión tiene una sintaxis apropiada, como en el ejemplo). Creemos un archivo xin.personal y copiemos el .xinitrc de ejemplo que vimos antes:
touch xin.personal [Enter]
Luego desde MC (Midnight Commander), nos posicionamos sobre él y lo editamos (haciendo F4), tipeamos las líneas del ejemplo, grabamos (F2) y salimos (ESC). Ahora ejecutemos nuestro inicio personalizado:
xinit ~/xin.personal [Enter]
Listo. Como se puede apreciar, X Window no es más que un conjunto de programas que brindan un entorno gráfico para trabajar (y otras cosas).
¿Cómo sería ejecutar X Window sin ningún programa?
Primero salí de tu sesión actual eligiendo la opción Salir del menú de Sawfish o sino haciendo:
CTRL + ALT + Backspace [Enter]
(con esta combinación de teclas matás al servidor X y por ende a cualquier programa que esté corriendo en X Window).
Para ver X sin ningún otro programa (X Window solo):
X [Enter]
(sí, va en mayúsculas; no, no funciona en minúsculas)
Tocando un poco al GNOME
¿Qué onda con GNOME? ¿Por qué acelerar su inicio si prende rápido? Yo digo porqué no...
Mirando un poco por el sistema, y en el CD de instalación del Linux que uso (Linux-Mandrake 8.0), revisando el listado de archivos que contienen los rpm (lo hacés con rpm -ql nombre_del rpm o gráficamente con KPackage o GNOrpm), que forman el GNOME y los directorios de instalación (ver en los mismos rpm), vemos que el susodicho está formado por muchos binarios, y hay un par con nombres sospechosos como panel o gnome-session...
Bueno, la deducción rápida es que el inicio por defecto de GNOME lo hace un binario (ejecutable) llamado gnome-session que ejecuta (pero no muy rápido, o no tanto como nos gustaría), todas las aplicaciones básicas del entorno GNOME (panel, fondo de escritorio, íconos, etc.). Lo podemos ejecutar a mano con un .xinitrc, cremos uno:
cd $HOME [Enter]
touch xin.gno [Enter]
Editamos con el MC (igual que hicimos antes), pero solo agregamos (al archivo vacio) una línea con gnome-session, nada más. Quedaría así:
gnome-session
Para ver si funcionó, lo ejecutamos (con el comando xinit):
xinit ~/xin.gno [Enter]
Y ahí vemos como se inicia normalmente el entorno, luego salimos para seguir de juerga...
Objetivos
Si lo que queremos es iniciar a mano un entorno gráfico (o un Window Manager sólo incluso), nos proponemos implícitamente la necesidad de ejecutar (al menos):
El Window Manager (Sawfish, WindowMaker, AfterStep, IceWm, Blackbox, etc.)
El fondo de escritorio (una imagen)
El salvapantallas (xscreensaver es el programa que usa Linux para esto...)
y además podríamos ejecutar otros chiches:
Iconos de escritorio (que serían los del gmc, nautilus, dfm, etc.)
Un panel de menu
Encender el Numlock del teclado numérico (Mandrake 7.x y 8.0)
Alguna aplicación que querramos que se inicie automáticamente al iniciar X, etc.
Manos al GNOME
Entonces creemos un .xinitrc personalizado para iniciar el GNOME a mano:
cd $HOME [Enter]
touch xin.GNOME-pers [Enter]
Editamos con MC (luego grabamos los cambios con F2)
xsetroot -solid black &
xscreensaver --no-splash &
gmc --no-windows &
enable_X11_numlock &
sawfish &
panel
Si no lo notaron, se los cuento: en este .xinitrc personalizado para iniciar el GNOME a mano pusimos en último lugar al panel en vez de al Window Manager. ¿Por qué? Porque, como dije antes, el último programa (el que no lleva &), es el que al finalizarlo cierra la sesion X (apaga X Window junto con todos los demás programas que se están ejecutando en él), y a nosotros nos interesa que el GNOME a mano se apague al cerrar el Panel de Menu, por eso lo ponemos al final.
Ahora probamos...
xinit ~/xin.GNOME-pers [Enter]
...Y así encendemos GNOME apenas un poquito ms rápido que de costumbre.
Acelerando el inicio de GNOME
Los .xinitrc que estuvimos creando tienen, pese a prender un poco más rápido, tienen el mismo problema de startx: no se llevan bien con la ejecución no multihilo del inicio de X Window y hacen lenta su inicialización. Si convertimos al xin.GNOME-pers a la sintaxis de xtoolwait quedaría así:
panel & wmpid=$!
xtoolwait sawfish &
xtoolwait xsetroot -solid black &
xtoolwait xscreensaver --no-splash &
xtoolwait gmc --no-windows &
xtoolwait enable_X11_numlock &
wait $wmpid
probamos como antes:
xinit ~/xin.GNOME-pers [Enter]
Y listo. Si quieren contar los segundos menos que tarda GNOME en iniciarse... Yo les cuento que en mi máquina X tarda:
Con startx: 11 a 12.5 seg.
Con .xinitrc (sin xtoolwait): 8 a 10 seg.
Con .xinitrc (con xtoolwait): 5 a 5.5 seg.
Pueden variar de máquina a máquina según el hardware y las optimizaciones personales al sistema. Con el resto de los Window Managers que probé el incremento en la velocidad de carga de X es mayor inclusive.
Notas sobre el inicio acelerado
Es necesario tener en cuenta dos cosas (sin relación entre sí):
Para que el panel de GNOME se inicie sin dar problemas debe ejecutarse antes que él (el porqué de las comillas tiene que ver con cuestiones técnicas del xtoolwait, ver página man del mismo), un Window Manager compatible con GNOME. Para lograrlo en el script con xtoolwait ejecutamos en background (poniendo un ampersand, &, al final de la línea), de esta manera en el momento de correr el panel, ya tenemos al Sawfish ejecutándose. El error que daría de no hacerlo es que nos diría que es necesario correr un Window Manager compatible junto con el panel y luego se iniciaría sin problemas el Sawfish!
También debemos considerar que el inicio normal de GNOME, ejecuta ciertas funciones y librerías que no se ejecutarán si solo corremos el panel y el gmc, por lo que determinadas funciones de personalización (los tipos MIME principalmente), no suelen estar disponibles (no funcionan o si funcionan no se pueden modificar) en el inicio acelerado. Por supuesto no se alteran los seteos hechos antes del inicio acelerado, es más si queremos cambiar algo que no está disponible de esa manera solo debemos hacer un inicio normal de GNOME, realizar los cambios, y luego al iniciarlo acelerado los cambios serán seteados normalmente. Esto también suele aplicarse al Sawfish y otras aplicaciones vinculadas internamente a GNOME.
Anexos
Están relacionados con el artículo, así que si leen algo que parece hablar de algo ya mencionado se refiere seguramente al mencionado texto.
xtoolwait (cómo, dónde, etc.)
Es un programa útil, pero por lo general no se instala por defecto en ninguna distribución, a pesar de que la mayoría lo incluye entre los paquetes disponibles para instalar. Últimamente, la mayoría de las distribuciones suele incluirlo en el disco de instalación. Pueden buscar xtoolwait (y en general cualquier programa de Linux del cual conozcan el nombre), así:
En los Cds de instalación: particularmente el Linux-Mandrake 8.0 lo trae en el CD 2, probablemente otras distribuciones lo tengan en ese CD.
Pueden buscar en Internet: en los depósitos de .rpms (www.rpmfind.net y mirrors) en Search (buscar) pongan xtoolwait, les aparecerá una lista de los paquetes .rpm que poseen los caracteres xtoolwait en el nombre (son los que estamos buscando...). Elijan el que les corresponda según la distribución que usen, si ninguno corresponde a la suya elijan alguno que sea del Red Hat 6.2 (distros de antes de 2000 por lo general) o 7.x (si su distro es MUY nueva...), que seguro será compatible con la que tienen.
Otra manera de buscar en Internet es en cualquier buscador (prefiero www.google.com): en la caja de búsqueda pongan xtoolwait homepage y seguro que entre los primeros sitios encontrados figurará la página del programa desde donde pueden descargar la última versión disponible y también pueden consultar documentación actualizada y adicional (pues los .rpm solo traen una escueta man page, aparte del binario). Este último método para buscar sirve para cualquier programa de Linux.
Una cuarta manera sería ir a www.freshmeat.net, o a www.linuxapps.com y buscar (en la caja de búqueda Search), por el nombre xtoolwait.
Niveles de inicio (runlevels)
Los niveles de inicio nos importan por el llamado inicio con X y sin X. Bien, Linux posee varios niveles de inicio (por lo general 6), los que nos interesan a nosotros son el 3 y el 5. El nivel 3 inicia Linux con todos los servicios (básicos y de red) pero SIN iniciar automáticamente X Window. El nivel 5 inicia las misma cosas que el nivel 3 pero con X Window.
En las distintas distribuciones hay varias formas de cambiar el runlevel de inicio por defecto (Linuxconf, Webmin, el Panel de Control de Mandrake, el YAST en SuSE, etc.). Nosotros vamos a ver una que sirve para la mayoría de las distros...
Como usuario root editamos el archivo /etc/inittab (con MC si querés). Lo que vemos es esto (yo traduje el archivo de un Linux-Mandrake 8.0, pero el tuyo debe ser parecido y casi seguro, un 99.9 %, está en inglés ):
Fijáte en el medio más o menos para ver cómo cambiar de runlevel.
id:3:initdefault:
x:5:respawn:/etc/X11/prefdm -nodaemon
Para más información:
man inittab [Enter]
Salvapantallas
El viejo salvapantallas está representado en Linux por una aplicación llamada xscreensaver que nos permite tener a nuestra disposición una variada lista de screensavers (salvapantallas) para mantener nuestro monitor funcional por muchos años o hasta que se queme en un corte de Luz :-).
Les cuento: el programa posee dos binarios: xscreensaver y xscreensaver-demo. El primero nos permite cargar como demonio (residente) el salvapantallas y como es usual al cabo de tanto tiempo de inactividad del mouse y del teclado activar un salvapantallas al azar. El segundo nos permite probar los distintos salvapantallas con que cuenta el programa y ajustar los parámetros de tiempo correspondientes. Sin embargo es conveniente setear desde el inicio (en el .xinitrc) estos parámetros (por ejemplo...):
xscreensaver -timeout 1 -cycle 2 -no-splash &
Lo quiere decir: iniciar xscreensaver, activarlo al cabo de 1 minuto de inactividad, cambiar el salvapantallas cada 2 minutos, e iniciar sin mostrar la pantalla de presentación del programa.
Desde ya les cuento que existe un problema (cuya explicación traducida nunca encontré y en inglés no se entiende mucho), por el que no se ejecuta correctamente si iniciamos una sesión como root (es un problema de seguridad por lo que entendí), si vos entendés más el tema, abajo al final está mi mail, por favor contame.
Si quieren más datos (que estos) hagan:
man xscreensaver [Enter]
Fondo de escritorio
Lo que parece algo tan simple bien podría ser una pequeña pesadilla si no tenemos muchas ideas en las que basarnos. Un fondo de escritorio, en Linux se setea de 2 maneras:
Una es con el entorno gráfico y/o Window Manager que estemos usando, ya sea que permita elegir la imagen a mostrar y cómo mostrarla (KDE, GNOME, XFCE) o que permita setearlo por medio de themes o temas, que son como las skins del Winamp (o del XMMS), pero para los Window Managers (Window Maker, Blackbox, Icewm, Sawfish, AfterStep, etc.).
La otra manera es poner un fondo nosotros mismos (en un archivo .xinitrc), por medio de un comando que nos lo permita, por ejemplo:
xsetroot
wmsetbg
xv
qiv
bsetroot
bsetroot2
Para ver cómo funciona cada uno simplemente necesitamos una consola en una sesión X ya iniciada (no importa qué Window Manager usemos) e ir probando uno por uno sus parámetros teniendo la idea de que permiten (en general): centrar una imagen, escalar una imagen, hacer un mosaico con una imagen, difuminar una imagen, iluminar/oscurecer una imagen, etc.
La idea de sintaxis para cualquiera de los comandos antes mencionados es ésta:
comando -parámetros /path/al/archivo/archivo_de_imagen [Enter]
Las imágenes pueden estar en formato .jpg, .png, .gif, etc. Los .bmp y .pcx no suelen estar soportados. Para ver cuales son los posibles parámetros hacer (en una consola):
Algunos ejemplos:
wmsetbg -S -a ~/.blackbox/backgrounds/Avengelyne.jpg
bsetroot2 -mod 4 4 -bg rgb:00/34/46 -fg rgb:11/48/59
xv -root -smooth -max -quit ~/.blackbox/backgrounds/bin.jpg
xv -root -max -quit ~/.blackbox/backgrounds/project9.jpg
Para encontrar mas ejemplos te recomiendo fijarte en las últimas líneas de los "themes" de Window Maker que están en:
/usr/X11R6/share/WindowMaker/Themes
/home/usuario/GNUStep/Library/WindowMaker/Themes/
y en las últimas líneas de los "themes" del Blackbox que están en:
/usr/share/blackbox/themes
/usr/share/blackbox/styles
/home/usuario/.blackbox/themes
Si no tenés "themes" fijáte en www.themes.org. (p/KDE,KDE2.x,GNOME, Sawfish, WindowMaker, etc.).
Cómo sería iniciar un Window Manager (que no sea un entorno como GNOME)
Iniciaremos ahora un Window Manager distinto a Sawfish (el de GNOME). Ahí vamos de nuevo... Trataremos de iniciar Blackbox, que es famoso por su bajo consumo de recursos y su buena apariencia. En este caso, el Window Manager va al final porque es el programa que al finalizar, cierre X.
Creamos un archivo .xinitrc personal en el directorio de usuario:
cd $HOME [Enter]
touch xin.blackbox [Enter]
xsetroot -solid black &
xscreensaver --no-splash &
gmc --no-windows &
enable_X11_numlock &
blackbox
Y para ver...
xinit ~/xin.blackbox [Enter]
Optimizado con xtoolwait, quedaría así:
blackbox & wmpid=$!
xtoolwait xsetroot -solid black &
xtoolwait xscreensaver --no-splash &
xtoolwait gmc --no-windows
xtoolwait enable_X11_numlock &
wait $wmpid
Otra vez...
xinit ~/xin.blackbox [Enter]
Y Uds. me como va la velocidad de carga...
Nombres de binarios útiles
Un listado breve con los nombres de los binarios que inician los Window Manager más usados:
Afterstep: afterstep
Window Maker: wmaker
Blackbox: blackbox
Enlightenment: enlightenment
Sawfish: sawfish
XFCE: startxfce
ICEwm: icewm
KWM: kwm (solo funciona para las versiones 1.1.2 y anteriores de KDE)
Hacking al KDE 2 (funcionó en KDE 2.1.x)
Realizado en Linux-Mandrake 8.0, seguramente será similar en otras distros, pero no doy un 100% de seguridad de que funcione bien.
KDE2 (2.1.x) NO ARRANCA RÁPIDO, y es una de las preocupaciones más importantes en la lista de deseos para los desarrolladores, pero mientras ellos buscan la manera de iniciar más rápido por su lado nosotros vamos a hackearlo por el otro. De todas maneras recientemente, se descubrió la manera de acelerar KDE2 hasta un 50%, lo que probablemente veamos implementado en las versiones 2.2.0 y posteriores, así prepárence para el download...
Para empezar les cuento que el script que arranca KDE2 se llama startkde y está ubicado en /usr/bin; siguiendo en la línea de los .xinitrc les muestro cómo es un correcto inicio del KDE2. Creamos un archivo .xinitrc para el experimento:
cd $HOME [Enter]
touch xin.kde2 [Enter]
Lo editamos con MC (Midnight...) agregamos lo que sigue (nada más por ahora)
startkde
y grabamos luego con F2. Ahora lo probamos:
xinit ~/xin.kde2 [Enter]
Se inició bien, ¿no? ¿Podría ser más rápido tal vez? Veamos... startkde es un script, o sea una serie de instrucciones que se ejecutan (en general) línea por línea. Editemóslo, pero no al original sino a una copia de él:
cd /usr/bin [Enter]
cp startkde /home/usuario [Enter]
(también podés copiarlo usando MC)
Luego lo editamos (F2 desde el MC estando sobre el archivo). Oops! Son muchas líneas, ¿no? Pero no nos dejemos apabullar por su aparente complejidad porque esos grandes bloques de letras de color rojo (si estás en una consola FUERA de X son de ese color), son comentarios que nos explican (en inglés) paso a paso que es lo que hace el script.
Si leeemos con atención los comentarios de Dadou (el que los escribió para Linux-Mandrake 8.0) nos damos cuenta de que la mayoría de las líneas (hasta Boot Sequence), sólo son imprescindibles en el primer arranque del KDE2 y otras son reaseguros por si agregamos fuentes nuevas o por si decidimos cambiar de lugar nuestras carpetas KDE (desktop, etc.), también hay unas líneas que se encargan de agregar determinados íconos (los del Mandrake) a nuestro Escritorio, etc.
Así, un arranque correcto solo sería necesario de vez en cuando, al hacer algún cambio muy radical en nuestra configuración del KDE2 (no, no me refiero a cambiarle las fuentes, el theme y/o el style, ni a la activación).
Así que podríamos borrar (o mejor aún, comentar) las líneas sobrantes para evitar que se ejecuten cada vez que entramos a KDE. Es recomendable modificar sólo la copia que ya tenemos en nuestro directorio de usuario y dejar el original en /usr/bin INTACTO.
Fijénse que hay unos cuantos comentarios explicativos (en castellano digo):
xsetroot -cursor_name left_ptr -solid #666699
xmodmap -e 'keycode 115=F13'
xmodmap -e 'keycode 117=Menu'
rm -f $HOME/.ICEauthority
rm -f $HOME/.DCOPserver
---------aca hay algo comentado---------
---------hasta aca------------------
---------aca hay algo comentado---------
---------hasta aca--------------
------y todo el resto queda igual-----
lnusertemp tmp >/dev/null
lnusertemp socket >/dev/null
ksplash
LD_BIND_NOW=true kdeinit +kcminit
knotify
exec ksmserver --restore
Luego de todo, si cronometramos los tiempos de inicio del script original contra el script tocado no vemos diferencias significativas (!!!). Paciencia. Llegó la hora de nuestro amigo xtoolwait, y veamos que puede hacer para que se inicie más rápido el KDE.
Revisando y probando lo que funcionó fue esto (que por supuesto va dentro de un .xinitrc personalizado:
rm -f $HOME/.ICEauthority
rm -f $HOME/.DCOPserver
kwin & wmpid=$!
xtoolwait xsetroot -cursor_name left_ptr -solid '#666699'
xtoolwait xmodmap -e 'keycode 115=F13'
xtoolwait xmodmap -e 'keycode 117=Menu'
xtoolwait kdesktop
xtoolwait kicker
xtoolwait khotkeys
wait $wmpid
Copiemos esto en un .xinitrc personalizado y ejecutemos...
Se prendió más rápido, ¿no? Pero no hay antialiasing de fuentes, eso todavía no lo pude hacer funcionar; pero fuera de eso, mis tiempos de inicio fueron:
Tipo de "startkde" / Tiempo
Original: 26 a 39 segundos
Modificado: 24 a 25 segundos
Modificado (con xtoolwait): 14 a 15 segundos
Pueden variar de máquina a máquina según el hardware y las optimizaciones personales al sistema.
Notas sobre el inicio acelerado de KDE
Como vimos existen dos maneras de iniciar KDE aparte del modo normal, la primera nos permite omitir (no realizar), ciertas tareas que por lo general solo son necesarias la primera vez que el usuario ejecuta el KDE o luego de realizar personalizaciones muy específicas (por ejemplo: modificar el directorio por defecto donde se ubicarn los íconos del escritorio) es el modo "acelerado sin xtoolwait". El segundo modo implica el uso de xtoolwait . Por esto si hacemos cambios radicales o muy amplios en la interfaz (no, no me refiero a cambiar themes y styles), vinculados con fuentes nuevas, cambio de los directorios por defecto, etc. es necesario que iniciemos normalmente el KDE la primera vez luego de realizados los cambios, también sería apropiado que esos mismos cambios los hagamos desde un KDE iniciado normalmente.
Como ven, el entorno KDE tiene similitudes funcionales con el GNOME.
En el modo "acelerado por xtoolwait", debemos acotar algo, si tenemos seteado el KDE para usar fuentes con antialiasing, éstas se verán normalmente, es decir sin antialiasing. No se preocupen, si iniciamos en modo normal o "acelerado sin xtoolwait" eso no sucede, es más podemos iniciar alternativamente en uno y otro modo, y nuestras queridas fuentes con antialiasing volverán siempre si iniciamos normalmente o "acelerado sin xtoolwait".
Sigan probando a ver si conseguimos fuentes con antialiasing...
[email protected]
