Creo que cualquiera se sentiría incomodo con esto, mas viendo que en idle se mantiene alrededor de los 72°. Así que me puse a investigar causas y me encontre con la fantastica noticia que esto era un problema generado por la BIOS en el algoritmo que controla las revoluciones del cooler.

Compaq sugiere actualizar la bios ya que las versiones mas recientes tienen mejorado el algoritmo del cooler.

Pero como la solucion no me convencia, primero porque el echo de una eventual falla en la actualizacion de la bios me hiba a dejar sin PC por unos dias cosa que por esta epoca no me puedo permitir. Y segundo, porque mas alla de que suponiendo que efectivamente se haya corregido el algoritmo de control del cooler, hay una diferencia de unos 30°C entre lo que obtenia con los kernels de la serie 2.6.24 a la actual 2.6.26 se puede preveer que el problema venia por otro lado.

Encontre una solucion modificando los trip points que se encontraban demaciado altos, pero esta otra solucion, es incluso mas arriesgada que la actualizacion de la bios, ya que en el caso de que nos falle algo, podemos dejar al procesador directamente sin ventilacion forzada.

Siguiendo con la cronica, y ya cansado de buscar, preparandome para darle alguna solucion compleja al problema, casi de casualidad encontre por ahi un comentario sin justificacion. Poner como parametro del kernel “nohz=off”

El parametro “magico”:

Bueno un poquito exagerada la descripcion, pero dan ganas de ponerle ese nombre.

La documentacion del kernel dice lo siguiente:

“[KNL] Boottime enable/disable dynamic ticks”

No encontre una explicacion mas clara de que hace esto, pero funciona.

Si instalaron siguiendo la guia de este mismo blog, les recomiendo cambien todos los parametros (noapic nolapic pcinommconf=off idle=poll) por este “nohz=off”

la temperatura se redujo en mi caso a 55°C en uso normal, con picos de 70°C con el micro al 100% por un tiempo prolongado.

Tras esto se puede escuchar los incrementos de velocidad del cooler a medida que va subiendo la temperatura cosa que no habia notado anteriormente y si monitoreando el uso del procesador, note que el uso de este se ve reducido cuando no se esta usando la pc.

Espero que les sirva.

En esta parte nos vamos a enfocar a eliminar demonios innecesarios agregar los que necesitemos y customizar los runlevels medio a la “red hat”.

Todas estas guías están orientadas desktops, así que esta no va a ser la excepción.

Empecemos, aclaremos conceptos por las dudas

Que son los demonios: Son los que que los servicios a windows, son programas que corren en segundo plano ofreciendo alguna funcion cuando esta se necesite.
Vamos a ser sacrílegos y dividirlos en 2 clases: Locales y de red.

Los locales son procesos que no interesa usar en una red, por ejemplo acpi, kill, reboot, etc
Los de red, son servicios que nos interesa usar en red o que por lo menos lo admiten como una función. por ejemplo los display managers, apache o samba.

Haciendo esta división vamos a decir que los demonios locales son los que mas nos interesaría conservar en un escritorio, y los de red son los que podemos elegir quitar o no, cuidado con quitar cosas indiscriminadamente, ya que no todos los demonios se pueden definir asi y existen dependencias que en el caso de no cumplirse evitaran que otro demonio arranque.

Para ver los demonios instalados listamos el contenido de /etc/init.d
Y nos informamos de cada cosa con las paginas del manual
por ejemplo man acpid, man exim4, etc.

Antes de ponernos a desisntalar podemos pararlos para ver cuanto influye en la performance de la maquina, para lo cual podemos hacer por ejemplo
/etc/init.d/gdm stop

Todos estos demonios admiten siempre 2 o mas parámetros:
Start y stop
Y adicionalmente hay otros que adminten comandos tales como
status, restart, force-start force-stop, etc.

Cuando tenemos identificado lo que no nos interesa tener instalado simplemente lo desinstalamos, por ejemplo exim4.

Hasta acá esto es una huevada. Así que vamos a ver si lo ponemos mas interesante.

Los runlevels nos definen el estado de la maquina iniciando o parando servicios según corresponda, de esta forma en la misma maquina y con los mismos servicios podemos tener varios modos de funcionamiento.
Por defecto en debian los runlevels vienen preconfigurados de la siguiente manera:

Runlevel 0: Halt. En este estado todos los servicios se encuentran apagados.
Runlevel 1: Single user: Se usa para solucionar problemas, en este estado solamente tendremos corriendo el shell
Runlevel 2: El sistema se encuentra cargado completamente, entorno gráfico, red, etc. Este es el runlevel por defecto en debian.
Runlevel 3, 4 y 5: Son por defecto iguales al 2, en algunas otras distribuciones algunos de estos runlevels inician todo menos entorno gráfico, o servicios de red.
Runlevel 6: Reboot. En este estado el sistema apaga todos los demonios y reinicia la maquina.

Ya que esta guia esta orientada a pcs de escritorios, vamos a evitar trabajar directamente con los archivos para por un lado evitar errores por typeo o sintaxis, y por otro, para no ahondar en esto demasiado ya que init, mas allá de ser uno de los sistemas mas simples y confiables, esta quedando viejo y sera, no dentro de mucho tiempo, remplazado muy probablemente por initng, que no se configura de la misma manera.

A modo de ejemplo, voy a configurar los runlevels 3 y 4 para mi notebook usando ksysv. Para lo cual considero que necesito:
Un runlevel donde funcione todo excepto los servicios de red. (para usar en conexiones no seguras con wifi)
Un runlevel donde no haya muchas cosas cargadas para acelerar la compilación.

La primera vez que arranquemos ksysv nos preguntara el sistema operativo y la distribución y luego llegamos a la parte de la configuración. Cuando estemos ahí veremos que el programa tiene por cada runlevel 2 recuadros, uno para iniciar demonios y el otro para Detenerlos.

Ubicamos el runlevel 3 por ejemplo, y con el mouse arrastramos los demonios desde la sección de inicio hacia donde los la de detencion y cuando pregunte le indicamos que los queremos mover.
Por ejemplo, en mi caso, exim4, apache2 y samba.

En el runlevel 4 Paro los display manager para no arrancar Xorg automáticamente y exim4 (ya que no voy a mandar mails desde la consola aunque se puede me resulta incomodo) para ahorrar recursos a la hora de compilar. Osea muevo de la “iniciar” de arranque a la sección de “Detener” los demonios kdm, gdm exim4.

Cuando tengamos todo configurado a nuestro gusto guardamos la configuración y nos disponemos a probarla.

Para cambiar de runlevels usamos el comando telinit con el numero de runlevel al que querríamos pasar. Por ejemplo y si configuramos como comente anteriormente para deshabilitar los servicios de red, tecleamos en la consola:
sudo telinit 3

Cambiando runlevel por defecto:
Para modificar de manera permanente el runlevel de inicio editamos /etc/inittab
En la primera linea no comentada remplazamos el 2 por el runlevel deseado:
id:3:initdefault:

Seleccionando runlevel al arranque.
Una opción muy cómoda por lo menos en mi caso es arrancar la notebook en determinado runlevel, y seleccionarlo por menú para no tener que teclear el cambio de runlevel en donde este. Es mas un capricho que una necesidad real pero me queda realmente muy cómodo.
Para esto editamos /bootgrub/menu.lst y en la entrada de nuestro núcleo indicamos el runlevel a arrancar, por ejemplo
Duplicamos la entrada de nuestro kernel tantas veces como querramos arrancar y le agregamos junto con los parametros del kernel el runlevel en el cual se arranca.
Original:
title Debian GNU/Linux, kernel 2.6.25
root (hd0,2)
kernel /boot/vmlinuz-2.6.25 root=/dev/sda3 ro quiet noapic nolapic pci=nommconf idle=poll
initrd /boot/initrd.img-2.6.25


Modificado:
title Debian GNU/Linux, kernel 2.6.25, Default
root (hd0,2)
kernel /boot/vmlinuz-2.6.25 2 root=/dev/sda3 ro quiet noapic nolapic pci=nommconf idle=poll
initrd /boot/initrd.img-2.6.25

title Debian GNU/Linux, kernel 2.6.25 rlvl3: sin servicios de red
root (hd0,2)
kernel /boot/vmlinuz-2.6.25 3 root=/dev/sda3 ro quiet noapic nolapic pci=nommconf idle=poll
initrd /boot/initrd.img-2.6.25

title Debian GNU/Linux, kernel 2.6.25 rlvl 4: Sin entorno grafico
root (hd0,2)
kernel /boot/vmlinuz-2.6.25 4 root=/dev/sda3 ro quiet noapic nolapic pci=nommconf idle=poll
initrd /boot/initrd.img-2.6.25

Necesitamos descargar

Obviamente el kernel 2.6.25
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.tar.bz2

Si necesitan guía para compilar e instalar el kernel pueden usar esta de este mismo blog

Driver para tarjetas Nvidia:
http://us.download.nvidia.com/XFree86/Linux-x86_64/169.12/NVIDIA-Linux-x86_64-169.12-pkg2.run

Parche para kernels 2.6.25.rc (funcionara aunque este ya no sea un rc)

http://www.nvnews.net/vbulletin/attachment.php?attachmentid=30771&d=1205875946

guardamos ambos en el mismo directorio, nos situamos en el y aplicamos el patch de la siguiente manera.

# sh NVIDIA-Linux-x86_64-169.12-pkg2.run --apply-patch NVIDIA-Linux-x86_64-169.12-pkg2.run
Lo que nos dara como resultado un nuevo archivo llamado:
#sh NVIDIA-Linux-x86_64-169.12-pkg2-custom.run

Compilamos el kernel con las opciones que mas nos gusten y lo instalamos, volvemos a configurar los parámetros de arranque de grup en /boot/grub/menu.lst y antes de reiniciar la maquina, desactivamos la aceleración gráfica (por las dudas si algo falla seguimos teniendo entorno grafico para salir del paso) en /etc/X11/xorg.conf
Buscamos la linea donde dice
Driver "nvidia"
Y la remplazamos por:
Driver "nv"

Ahora si, reiniciamos y pasamos a consola con ctrl + alt + F1, logeamos como root y paramos el entorno gráfico.
/etc/init.d/gdm stop
O si usan kdm
/etc/init.d/kdm stop

O a la antiguita:
killall gdm, killall kdm, o killall el dm q esten usando.

Ejecutamos el instalador CUSTOM que creamos, el cual detectara si tienen un driver anterior y lo desinstalara, e instalara el driver sobre el kernel 2.6.25 Que si bien nvidia no nos da garantías de que funcione correctamente, por mi parte lo vengo castigando bastante y, de momento, parece funcionar mejor con este kernel que con el anterior el cual estaba plenamente soportado.

En cuanto tengamos instalado el driver, solamente queda volver habilitar el el driver de aceleración gráfica en xorg.conf (osea volvemos a poner nvidia donde antes lo remplazamos por nv) y volvemos a arrancar el display manager.
/etc/init.d/gdm start o kdm start o el dm q esten usando.

Mucha de la gente con la que hable de este tema sostienen que su sistema anda, que no sabrían como compilarlo, que para que, hay muchas escusas.

Los principales ventajas de compilar nuestro propio núcleo son que logramos optimizar el código de lo es el proceso mas demandante del sistema. Si nos ponemos a ver el kernel corre desde que arrancamos la maquina hasta que la apagamos, y entra en funcionamiento tanto en tiempo de usuario como en tiempo de sistema, administra todo.
Los núcleos precompilados que vienen con la distribución contienen muchas funciones que no necesitamos, drivers para hardware que no tenemos y difícilmente tendremos, soporte a filesystems que no usamos. Código no optimizado para nuestro micro en particular, y formas de administrar los recursos con las que no podemos llegar a estar de acuerdo.

Las contras:
Como no encuentro alguna contra real, como para poner alguna, vamos a decir que se toma un rato bastante largo en compilarse. Y en el caso de que llegara a fallar porque no pusimos algo que necesitábamos vamos a tener que compilar todo de vuelta.

Pero bueno, en cuanto nos decidamos pasamos al siguiente paso:
Podemos hacer 2 cosas, primero podemos bajar un kernel desde kernel.org para tener lo ultimo de lo ultimo.O podemos usar los fuentes del núcleo de nuestra distribución.

Desde mi punto de vista, en desktops pcs, creo que lo que conviene es complicarse la vida lo justo y necesario, así que mientras todo funcione, y no nos muestren las ventajas de un núcleo nuevo no creo que sea conveniente usarlo, principalmente porque como ya dije el tiempo de compilación es alto y entre versiones cercanas posiblemente no ganemos mucho.

Ya que vamos a compilar nuestro núcleo, para empezar lo mejor sera arrancar con el ultimo núcleo estable. Así que nos vamos a www.kernel.org y nos bajamos los fuentes del núcleo.

Movemos los fuentes a /usr/src/ y lo descomprimimos

linkeamos el directorio de los fuentes a /usr/src/linux. Por ejemplo en el caso del nucleo 2.6.24.4 (ultimo estable a la fecha) el comando seria
ln -s /usr/src/linux-2.6.24.4 /usr/src/linux
Y entramos en el directorio /usr/src/linux

Ahora toca configurar que vamos a compilar. Para lo cual lo mejor es partir de la configuración actual y modificarla según nuestras necesidades.
Copiamos nuestra configuración actual, el nombre del archivo de configuración dependerá del kernel que estemos usando.
Como ejemplo vamos a copiar la configuración del núcleo 2.4.24.1 que es el ultimo que viene con debian a la hora de escribir esto.

cp /boot/config-2.6.24-1-amd64 /usr/src/.config

Entramos al directorio de los fuentes y los vamos a configurar.
cd /usr/src/linux

Intentamos configurarlo usando xconfig
sudo make xconfig
Esta es sin dudas la forma mas practica de configurar el núcleo.

Si no disponemos de entorno gráfico
sudo make menuconfig

Y por ultimo si disponemos de un sistema mínimo y no tenemos instaladas ni las librerías ncurses.
sudo make config

En todos los casos las opciones a configurar son las mismas, pero por comodidad y tiempo siempre conviene xconfig o menuconfig antes que make config. Ya que esta ultima manera nos va a preguntar ítem por ítem que hacer sin posibilidad de volver a cambiar algo.

Para optimizarlo hacen falta solamente 2 cosas.

Primero.
Procesor type and features
En donde seleccionamos nuestra plataforma y acomodamos las características que posea el micro.

Y en segundo termino los módulos:

Lo que hace a linux mas estable es el soporte de módulos, lo que permite al sistema seguir funcionando hasta en muchas ocasiones con fallos en el hardware.
Que es esto, veamos, si tenemos por ejemplo una red inalámbrica, he incluimos el soporte de hardware para esta placa dentro del núcleo, ganaremos algo de latencia (prácticamente nada para las latencias propias de este tipo de dispositivos) pero, en el caso que por algún fallo, bug o xploit, esta sección de código falle, al estar incluida en el núcleo va a arrastrar el resto del núcleo con ella. Ahora, si lo ponemos como modulo, en el caso de fallar el modulo se descarga y puede cargarse nuevamente sin ningún problema.

Por otro lado, si compilamos algo que se necesite al momento de arrancar como modulo, el modulo debe estar incluido en initrd, de lo contrario el sistema no arrancara.

Por mi parte, lo óptimo me parece que es incluir el soporte al fs que usemos en nuestro disco (en la parte de linux solamente) dentro del núcleo, de hardware evitemos todo lo posible, para que una falla en un dispositivo no arrastre el resto del sistema, soporte de networking (lo configuramos según el hardware que tengamos) al núcleo Y el resto, como módulos.

Cuando tengamos todo configurado, compilamos

make-kpkg --initrd kernel_image kernel_headers kernel_manual

Los últimos 2 targets son opcionales, pero útiles.

kernel headers compilara las cabeceras del núcleo, estas sirven para compilar módulos adicionales como pueden ser controladores propietarios, módulos para maquinas virtuales (virtualbox, qemu, vmware),etc

kernel_manual compila las paginas del manual del núcleo.

Tras todo esto solamente queda instalarlo.

dpkg -i linux-headers-2.6.24.4_2.6.24.4-10.00.Custom_amd64.deb linux-image-2.6.24.4_2.6.24.4-10.00.Custom_amd64.deb

Tras esto solamente queda volver a configurar los parámetro de arranque del núcleo en /boot/grub/menu.lst

Y reiniciamos la maquina para comprobar que todo funcione.

Ya que tenemos a disposición el código fuente de todo programa libre que instalamos, vamos a ubicar procesos a optimizar según nuestras necesidades, y a priori vamos a hacer una optimización “liviana” usando apt-build.

Consideraciones. Tengamos en cuenta que las herramientas para crear paquetes automáticamente están muy lejos de ser perfectas. Así que lo que en principio puede parecer algo simple puede no serlo tanto. Pero como considero que usar apt-get en un sistema de escritorio es mas un capricho que una necesidad no voy a abarcar problemas puntuales con algun paquete que no compila, por lo pronto vamos a suponer que todo compila y se instala sin problemas. Para los que necesiten el paquete compilado si o si, siempre queda la alternativa de bajar los fuentes, y compilarlo de forma manual.

Optimizaciones Obvias:
Dependiendo del rol que tenga nuestro sistema, ya sabemos que procesos tenemos corriendo y cuales son los mas demandantes.

Por ejemplo, si fuera desktop estamos hablando que los puntos a optimizar son xorg, gnome, kde, browser, nuestro reproductor multimedia, nuestra suite ofimática, etc.

Si el rol de nuestro sistema fuera servir base de datos… es mas fácil todavía. El motor de base de datos y punto.

Si por ejemplo servimos terminales gráficas, creo que tendríamos que optimizar todo :S.

Igual siempre es preferible ser selectivo con esto, ya que el proceso de construir cada paquete se toma su buen tiempo y muchas veces el resultado no es el esperado.

Por lo pronto instalamos apt-build
sudo apt-get install aptbuild

Una vez instalado el script de configuracion nos preguntar el nivel de optimizacion, 1 optimizacion baja, 2 Media, 3 Agresiva.

La primera es una buena opción para procesos críticos y no tan demandantes.
La segunda es probablemente la mas interesante ya que nos brinda una optimización bastante alta y una perdida de estabilidad del paquete relativamente baja.
La tercera puede producir en ocasiones resultados un tanto inestables. Asi que no creo que convenga para ningún proceso critico salvo que estén muy justos de procesador.

Cuando querramos reconfigurar ya sea para cambiar el nivel de optimizacion como para cambiar el procesador:
dpkg-reconfigure apt-build

Probamos con un paquete superfluo pero complejo para ver si todo funciona como debe

sudo apt-buil install tuxrace
O si ya esta instalado tuxrace:
sudo apt-install --reinstall tuxrace

Si todo funciona bien pasados unos minutos tendremos tuxrace compilado y optimizado para nuestra plataforma.

Según los propios autores de apt-build, lo único que no se recomienda para nada recompilar son las librerías libc6 y gcc.

Buscando procesos críticos
Dependiendo del uso que le demos a la pc necesitaremos optimizar tal o cual paquete asi que veamos la forma de investigar que usa mas tiempo de CPU.

Vista rápida a la tabla de procesos.

Para los que no se quieran complicar demasiado la existencia usamos “top”
Usamos la pc normalmente por un buen rato, despues abrimos un terminal y tecleamos top, luego “T” (para ordenar por tiempo de cpu).

Los procesos que tengan mas tiempo de cpu acumulado, son obviamente, los que mas necesitaron de la cpu y por lo tanto nuestros candidatos a actualizar. Solamente queda tener en cuenta que para que los procesos sean vistos en top, el proceso tiene que estar “vivo”.

Asi que, podemos ejecutar top y dejarlo corriendo. Viendolo cada tanto para ir identificando procesos procesos a actualizar en todo momento.

apt-build world
Suena gentoo no? Y se le parece un poco en realidad.
Con esto, en teoría, podemos recompilar el sistema completo y dejar absolutamente todo optimizado.
En la practica, hacerlo puede llevar literalmente días para que termine de compilar (bien gentoo xD). Sumado a que muchas veces apt-build falla compilando y podemos llegar a perder unas cuantas horas.

En el caso de querer recompilar todos los paquetes que tenemos instalados:
dpkg --get-selections | awk '{if ($2 == "install") print $1}' > /etc/apt/apt-build.list

luego, editamos y sacamos gcc en todas sus verciones, y libc6
Me parece bastante tonto compilar el kernel de esta forma, ya que haciéndolo a mano logramos una optimización mucho mas alta ya que podemos elegir que ponemos en el núcleo y que como módulos.

Para los que quieran probar esto, lean al final un par de consejos para optimizar el optimizador.

atp-build mundito

Si nos ponemos a ver, lo que hace el comando dpkg –get-selection es listar los paquetes que están instalados y los que fueron removidos, el segundo comando filtra los removidos para dejar solamente los instalados.
Entonces, podemos deducir que el archivo apt-build.list no es mas que una simple lista de paquetes para poner a funcionar a apt-build en “modo batch”.

Por lo que podemos hacernos un “mundito” mas chico para que nos resulte mas practico.
Por ejemplo, si queremos recompilar todo xorg incluyendo los drivers podemos usar:
dpkg --get-selections | awk '{if ($2 == "install") print $1}'|grep xorg >/etc/apt/apt-build.list

Le sumamos por ejemplo, xine con todos sus plugins
dpkg --get-selections | awk '{if ($2 == "install") print $1}'|grep xine >>/etc/apt/apt-build.list

Optimizamos compresores bz* (aca se nota mucho la diferencia)
dpkg --get-selections | awk '{if ($2 == "install") print $1}'|grep bz >>/etc/apt/apt-build.list

Para todo lo que no podamos definir con expresiones regulares, editamos el archivo y
agregamos a mano los paquetes.

Cuando tengamos nuestro pequeño mundito, corremos:
apt-build world

Y ahora sera cosa de esperar un muy largo rato y tendremos nuestra selección compilada. Muy largo rato suena mejor que algunos días.

Optimizando el proceso de optimizado
Me estoy dando cuenta que todas mis guías vienen con bonus track xD

Como acelerar el proceso de compilación.

Antes de compilar una gran (o no tan gran) colección de paquetes, podemos mejorar algunas cositas.

Optimizando herramientas:
Compilamos nuestro propias herramientas de compilación y manejo de archivo, por lo menos las mas criticas pero seguras.

apt-build install --reinstall apt-build make tar

Cuando se ponga a compilar en batch se puede salir del entorno gráfico y compilarse desde la consola. Con esto se acelera muchísimo la compilación. No basta con pasa a una consola virtual ya que xorg sigue corriendo. Hay que matar gdm, kdm o lo que se use, o bien, cambiar el runlevel (proximamente guia).

Minimizar la cantidad de paquetes.
Antes de seleccionar los paquetes a compilar (mas si se quiere compilar todo el sistema) se puede limpiar los paquetes que no usemos con.
apt-get autoremove

Antes de empezar hay que decidirse en nuestra política sobre el software libre.
Por un lado podemos seguir a rajatabla los consejos de Richard Stallman, y evitar a toda costa caer en alguna solucion propietaria. Dependiendo del uso que pretendamos darle a nuestra computadora esto se torna mas o menos complicado, y hay que relegar mas o menos funciones.

Por otro, podemos conformarnos con utilizar una mezcla de software libre, licencias no libres pero mas permisivas, quizás algún shareware,y productos freeware.

Personalmente, tengo una filosofía un tanto intermedia y un poco mas practica. Uso lo que considero que mejor anda. Si es GNU, mejor, si es una solución propietaria, mala suerte, lo usare hasta que encuentre una alternativa que me quede realmente cómoda.

Pero bueno, basta de política del software, y arranquemos por lo básico

“Customizando” repositorios:

Los repositorios de debian son muy completos, aunque, por la inmensa cantidad de software que hay disponible, obviamente no podemos encontrar todo en los repositorios oficiales. En algunos casos tambien podemos llegar a querer utilizar algun software en fase alpha o beta contra un release estable para ganar asi en funcionalidad.

Abrimos la consola y editamos sources.list

En en mirror que usemos de los repositorios oficiales, podemos agregar “non-free”, pongo los que tengo actualmente instalados, pero a los que no son de argentina muy probablemente les convendrá usar los repositorios que tengan geograficamente mas cercanos

#CD o DVD de debian: Comentado tanto por comodidad como porque tengo el netinstall

#deb cdrom:[Debian GNU/Linux testing _Lenny_ - Official Snapshot amd64 NETINST Binary-1 20080316-10:39]/ lenny main

#Repositorios Oficiales: Les convendría seleccionar los mirrors en base a la ubicación geográfica y a la velocidad que obtengan de cada uno. Un mirror lento, hace que toda la actualización del sistema y la instalación de nuevos paquetes sea algo muy tedioso. Agregamos contrib y non-free

#Original

#deb http://debian.logiclinux.com/debian/ lenny main
#deb-src http://debian.logiclinux.com/debian/ lenny main
#deb http://security.debian.org/ lenny/updates main

#Agregados contrib y non-free

deb http://debian.logiclinux.com/debian/ lenny main contrib non-free
deb-src http://debian.logiclinux.com/debian/ lenny main contrib
deb http://security.debian.org/ lenny/updates main contrib non-free

#Debian multimedia
deb http://www.debian-multimedia.org lenny main
deb-src http://www.debian-multimedia.org lenny main

#instalar llaves de debian multimedia (Ver mas adelante)
#apt-get install debian-multimedia-keyring

#Versiones Testing de compiz fusion (En caso de querer usar los releases estables, estan incluidos en los repositorios de lenny de debian, solamente hace falta comentar la linea)
deb http://download.tuxfamily.org/shames/debian-lenny/desktopfx/unstable/ ./

#llaves
#wget http://download.tuxfamily.org/shames/A42A6CF5.gpg -O- | apt-key add -

#Opera
deb http://deb.opera.com/opera/ lenny non-free

#llaves
#wget -O – http://deb.opera.com/archive.key | sudo apt-key add -

Una vez editado los repositorios. instalamos las llaves para evitar warnings.

Ejecutamos:

$wget http://download.tuxfamily.org/shames/A42A6CF5.gpg -O- | sudo apt-key add -
$wget http://deb.opera.com/archive.key -O- | sudo apt-key add -
$sudo apt-get update #ignorar el warning
$sudo apt-get install debian-multimedia-keyring

En el ultimo comando nos pedirá autorización para instalar el paquete no seguro, ya que se trata de las llaves para el repositorio, aceptamos y ya no nos solicitara mas confirmaciones para los paquetes provenientes de esta fuente.

Seguramente ya tenemos el 99% del software que podamos llegar a necesitar al alcance de apt-get.

Nos queda usar aptitude, synaptic, adept, apt-get para instalar los paquetes que necesitemos.

Pero bueno, no me puse a escribir tanto para decir tan poco, asi que viene una pequeña sección troubleshooting para algunos paquetes problemáticos.

Adobe shockwave/flash Player en sistemas de 64 bits.
instalar flashplayer junto con nspluginwrapper es un tanto complicado, y las ultimas versiones de adobe, comprueban que el sistema no sea de 64 bits. Asi que nada mas simple que usar este paquete que se encuentra en debian-multimedia.
sudo apt-get install flashplayer-mozilla

Adobe acrobat reader:
Algunos documentos PDFs se ven realmente mal en las alternativas libres a este programa, Y en algunos casos pueden llegar a consumir una cantidad considerablemente alta de memoria cuando se trabaja con PDFs grandes.
Para instalar adobe acrobar reader
sudo apt-get install acroread

Opera no se instala de los repositorios.
El repositorio de opera al momento de escribir esto no se encuentra disponible, quizás vuelva a funcionar, quizás no.
Si se quiere instalar opera descargando el paquete, nos encontraremos conque las versiones oficiales solamente funcionan en distribuciones de 32 bits. Los unicos paquetes que encontraremos para 64bits son los que se encuentran en fase Beta.

Para instalar opera 9.50 beta 64 bits
wget http://opera.freeby.pctools.cl/linux/950b/final/en/x86_64/opera_9.50-20071024.2-shared-qt_amd64.deb
sudo dpkg -i opera_9.50-20071024.2-shared-qt_amd64.deb

Para ir terminando solo queda investigar un poco los repositorios. Con estas ampliaciones se puede conseguir software para hacer prácticamente todo.

Como consejo, si están dando sus primeros pasos configurando debian, les recomiendo hacerle un cambio de cara al sistema, cambiar gnome por kde o por Enlightenment, o hacer su propio escritorio Híbrido.

Que se necesita:
Debian lenny netinstaller [0]
Una presario F500
Conexión a internet ethernet permanente. (para no envejecer mucho durante la instalación)
Solo para los que tengan broadcom 94311 (rev 02) Kernel 2.6.24[1] mas parche. [2] (Ver Actualización al final de la entrada)

Instalando:

Arrancamos el instalador pasándole parámetros al kernel
acpi=off pci=nommconf idle=poll
Pasando estos parámetros se puede instalar sin problemas. Hacemos una instalación normal y configuramos todo a gusto.

Una vez instalado dependiendo la notebook que tengan el sistema es muy probable que no arranque, para lo cual editamos los parámetros del
kernel.
acpi=off me parece muy drástico y cuando cargamos de esta forma aparecen varios errores en la traza del núcleo. Así que lo cambiamos por:
noapic nonlapic pci=nommconf idle=poll
Con esto ya tenemos un debian estable, y pasamos a lo interesante, usar b43.

Aclaro, b43 son los antiguos módulos bcm43xx y remplaza a ndiswrapper, es mucho mas completo que este ultimo pero también es un poco mas complicado de configurar.
Así que mas alla de lo que puedan leer por ahí, ndiswrapper o bcm43xx no funcionan junto con b43. Y no dependen en nada uno de los otros. Para no tener conflictos ponemos en el blacklist los módulos que no usemos.

Bajamos un kernel 2.6.24.4 de kernel.org lo descomprimimos y movemos el directorio a /usr/src

bajamos el parche y lo movemos dentro de la carpeta del kernel y linkeamos a la carpeta del kernel a /usr/src/linux (para ser prolijos).

aplicamos el parche a nuestro kernel con

patch -p1 < patch_2.6.24_for_4311_2

limpiamos, configuramos y compilamos e instalamos el kernel.
make mrproper
sudo cp /boot/config-kernelviejo .config
make menuconfig
make-kpkg clean
make-kpkg –initrd kernel_image kernel_headers

Esto compila y empaqueta tanto el kernel como las cabeceras en paquetes deb.
Los paquetes quedan en /usr/src, asi que los instalamos y volvemos a configurar las opciones de arranque (porque se sigue colgando si no los ponemos)
una vez que bootemos el nuevo kernel, solamente queda bajar b43-fwcutter. Al instalarse pregunta si queremos descargar el firmware. Ponemos que si para no seguir tecleando comandos y listo.

modprobe b43 (si es que no lo carga solo).

De momento, o por lo menos en mi caso usando debian lenny 64bits el driver b43 tiene un par de problemas, baja mucho el ancho de banda de la placa y no maneja muy bien la calidad del enlace, por lo que pierde bastantes paquetes, menos de un 10 %. Y una latencia altísima.
Osea, es usable pero un poco molesto.

Aunque ndiswrapper puede funcionar un poco mejor usando unos drivers de dell [3] Dependiendo de la versión y el núcleo que se use las perdidas de paquetes pueden llegar hasta un 40%. Aunque con algo mas de alcance.

[0]
http://cdimage.debian.org/cdimage/lenny_di_beta1/amd64/iso-cd/debian-testing-amd64-netinst.iso
[1]
http://www.eu.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.4.tar.bz2
[2]
http://linuxwireless.org/download/b43/patch_2.6.24_for_4311_2
[3]
http://ftp.us.dell.com/network/R151519.EXE

Actualizacion:
El kernel 2.6.25 ya soporta la placa 94311, por lo que no sera necesario aplicar el parche si usamos este kernel o alguna version posterior.
En los Kernels 2.6.24, la placa detecta un nivel de ruido execivo y baja el ancho de banda a 1Mb, En un principio pensaba que el problema era el ruido, pero tras probar el kernel 2.6.25 veo que no lo es, ya que el ruido se mantiene y si bien la placa no funciona en forma óptima, opera la mayor parte del tiempo en 54Mb

Hace unas horas lo instale, y la verdad, no solamente funciona muy bien, sino que encima las diferencias en lo que respecta a latencias son realmente notables si usamos el modo preemptible.

Esta versión tardo un poco mas de la cuenta en salir, unos 3 meses, y llego hasta el RC9 contra los 4 o 5 release candidates habituales. Esto se debe a que los cambios son muchos y afectan a varios subsistemas del núcleo.

Para los que quieran leer el changelog completo les dejo 2 links.

Changelog de kernel.org (completo y con créditos):
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25

O para una versión compacta y mas organizada.
http://kernelnewbies.org/LinuxChanges

Aunque para los que tengan placas Nvidia, aclaro que la empresa no libero un driver (por lo menos estable) con soporte para los kernels 2.6.25, así que si quieren usar aceleración 3D con este kernel, de momento no queda otra que aventurarse con un driver beta o parchear el driver antiguo. Como la primera no se destaca por su estabilidad, mas usando glx, preparo guía para patchear el driver estable.

Me traslado para aca porque como dije antes, uso productos propietarios hasta que encuentro uno libre que lo sustituya.

Ademas, como me pasa con cada “cosa libre” que descubro, siempre me encuentro con algo muy superior a lo que venia usando.

Voy a dividir esto en secciones y probablemente me vuelva mas prolijo para escribir (pero no prometo nada )

Esto va a tratar de Linux, Debian para ser mas preciso incluyendo algunas distribuciones derivadas. Voy a intentar apuntar las guias a los usuarios desktop que no se haya llevado Ubuntu todavía, y a los que vengan de esa distribución por curiosidad y se encuentren con la famosa dificultad (?) de debian.

También seguro voy a meter algún post de hard, principalmente porque me gusta el tema y me cuesta poco postear mientras yo mismo me mantengo al dia. Pero aclaro que no soy fierrero, todavía uso mi notebook pentium 120 mhz así q vallase dando una idea de por donde viene la mano.

Para los que no entiendan nada, vengo de acá:

http://caminogeek.blogspot.com/

Espero que esto le sirva a alguien.