Bill Gates pronunció su último discurso como "empleado de Microsoft"

- Esto sucedió en el marco de la Conferencia TechEd

En el último de sus discursos de despedida (¡por fin!), el fundador de Microsoft destacó las características del Internet Explorer 8, anunciado en versión beta para agosto, a la vez que presentó un robot parecido a su querido amigo y futuro kapanga de la empresa, Steve Ballmer.

Al tratarse de grandes personalidades, los discursos de despedida tienden a ser numerosos y es difícil saber cuál de ellos es realmente el último y definitivo.

Por lo tanto, puede cuestionarse que el discurso pronunciado por Gates ante una audiencia de desarrolladores en la conferencia TechED en Orlando, Florida, sea realmente de despedida

.

Fuente

Razones para usar kernels precompilados

Hoy temprano me levante con la curiosidad, de compilar un propio kernel para mi micro (AMD Athlon(tm) 64 X2 Dual Core Processor 4200+) para optimizarlo, pero me tope con esta aclaracion, y si no tiene ganas de leer esto (aunque se lo recomiendo) en resumen diria que si compilaramos nuestro propio kernel este no aumentara si eficiencia de manera significativa…, yo por lo pronto no hice nada pero tengo a mano los modulos que debo instalar para mi micro…

$ sudo aptitude install linux-image-k7 linux-restricted-modules-k7

Asi que si alguien lo prueba que me avise que tal le fue…

_____________________________________________________________________________

Hay una especie de “regla no escrita” en el mundo linuxero que dice que toda persona “debe” compilar su propio kernel, como parte de su proceso de aprendizaje o de incremento de su “estatus geek”. Nada más lejos de la realidad: El kernel, al igual que el resto del software del sistema, no deberia necesitar compilarse – como cualquier software diseñado decentemente. Lo que mucha gente no sabe es que Linux 2.6 es lo suficientemente avanzado como para que un kernel precompilado funcione perfectamente sin retoques en la mayoría de sistemas

  • Razón 1: Hay un mito sobre el kernel: La gente piensa que optimizando el kernel, el sistema irá más rápido, y que si no lo haces irá lentísimo y estarás desaprovechando tu equipo.

    Vamos a ignorarlo y hacer un análisis serio. Pregunta: ¿Cuanto tiempo de CPU gasta un sistema normal ejecutando codigo en espacio de usuario y cuanto gasta ejecutando código del kernel?. sar (maravilloso programa que no debería faltar en vuestros sistemas) puede decirlo:

    20:05:01          CPU     %user     %nice   %system   %iowait     %idle20:05:01          all      6,23      0,00      0,50      0,25     93,03


    Como se puede ver en este caso, de todo el tiempo de CPU transcurrido en mi sistema en un uso típico de escritorio (email, firefox, escribir artículos malos) solo un 0.50% del tiempo de CPU ha sido utilizado por el kernel, y un 6.23% por programas de espacio de usuario (un servidor dará diferentes números, de hecho un servidor web dará porcentajes diferentes a un pc haciendo de router). Es decir, 12.46 veces más. De todos los ciclos de CPU durante el que se ejecuta “software real” (todo lo que no es tiempo “idle”) el 92.57% se ejecutan en espacio de usuario, y un 7.42% en el kernel.

    Lo que quiere decir esto es que en un uso normal el sistema se pasa la mayor parte del tiempo ejecutando software en espacio de usuario, y que por lo tanto optimizar el kernel no mejorar el rendimiento del sistema de manera notable, por la simple razón de que la mayor parte del tiempo no es su código el que se está ejecutando. En las distros precompiladas tiene especialmente poco sentido: ¿Para qué optimizar para el procesador de turno el 7.42% del tiempo de ejecución si el software que se ejecuta el 92.57 del tiempo está “optimizado” para i586 o i386?.

    Esto tampoco quiere decir que la optimización no influya en absoluto: Hay ciertas funciones (como las funciones que mueven porciones de memoria de un sitio a otro) que se utilizan mucho y algunas tienen incluso optimizaciones específicas en ensamblador. Lo que quiero decir es que esperar que el optimizar el kernel vaya a acelerar notablemente un sistema típico es lo mismo que esperar que un grano de arena sea distinguible en un desierto.

  • Razón 2: Las diferencias entre procesadores puede que no justifican la optimización. Eso tampoco quiere decir que no existan esas diferencias o que no vayan a influir: Simplemente, las diferencias no son tan grandes como para justificar la optimización. Las distribuciones suelen tener un kernel i586 por defecto (excepto ubuntu y debian) y muchas kernels precompilados adicionales disponibles (para k7, para athlon64, para p4) en los repositorios. En serio, no necesitas recompilar el kernel solo porque en el kernel no añadieron una opción al gcc que tu “sabes” que en “teoria” optimiza mucho el ejecutable para tu máquina. Como ejemplo extremo está Ubuntú: Su kernel por defecto está optimizado con instrucciones de i386 (pero optimizadas para un pentium 4, esto es otro tema), y apuesto a que mucha gente ni siquiera se ha dado cuenta. Además hay que tener en cuenta una pecularidad de la plataforma x86: Todos sus procesadores se parecen “enormemente” entre si. De hecho, es la base de su éxito: Si x86 está donde está es en gran parte por no cambiar demasiado y preservar la compatibilidad lo máximo posible. En general, cuando las empresas dedicadas a CPUs preparan una nueva versión de CPU intentan copiar al máximo y dentro de las posibilidades de la nueva arquitectura el comportamiento de los procesadores anteriores, por la simple razón de que los compiladores tardan años en optimizarse para una arquitectura determinada. Eso puede suponer que al salir el producto a la calle el rendimiento sea pobre y que el producto fracase comercialmente. ¿A alguien le suena Itanium?

    Una de las principales diferencias entre los x86 (además de las diferencias fundamentales como netburst vs opteron etc) son las extensiones “multimedia”: MMX, SSE, 3dnow. Estas son especialmente irrelevantes para el kernel: Existe una regla en el kernel que prohibe utilizar código en punto flotante en el kernel excepto en unos pocos lugares controlados (usarlo demasiado obligaría a guardar los contenidos del coprocesador matemático entre cambios de contexto y eso enlentecería mucho el kernel). Se utilizan en algunos puntos, pero se evitan como si tuvieran la peste

    Lo que quiero decir aquí es que esto es como los benchmarks de Intel vs AMD: “En x benchmark AMD gana a intel un 5%”. Si, el AMD es más rápido, pero esa “ventaja” supone que en vez de tardar un minuto el amd lo hace en 59 segundos, que es prácticamente lo mismo. Es muy probable que no notes las optimizaciones que estes haciendo al compilar a mano el kernel. Son demasiado pequeñas. Las principales diferencias vienen casi siempre de mano los algoritmos: No hay optimización de procesador en el mundo que vaya a hacer que el kernel descarte correctamente tal o cual dato en el cache de disco o el orden correcto en el elevator del kernel, por ejemplo, y te aseguro que esa decisión va a influir muchísimo más en el rendimiento de tu máquina que cualquier optimización a nivel de procesador

  • Razón 3: Seguridad: Si descargas y compilas tu propio kernel, el día que haya un fallo de seguridad en el kernel tendrás que: 1) Enterarte. Algo que no es fácil, porque los fallos de seguridad del kernel casi nunca se reportan en barrapunto o slashdot o osnews (y si piensas que si, significa que no te has enterado de muchos fallos de seguridad o incluso de que alguien ha hackeado tu servidor gracias a uno de esos bugs y tiene instalado un rootkit en él ahora mismo, y no tengo por qué estar siendo paranoico) 2) reconfigurar 3) recompilar

    Sin embargo, si instalas un kernel precompilado, lo instalarás a partir de los paquetes de tu distro, y los sistemas de actualización de tu distro te lo actualizarán automáticamente en cuanto haya nueva actualización de seguridad. Es una opción bastante más inteligente…

  • Razón 4: Tener muchas cosas (opciones) compiladas en el kernel no daña necesariamente el rendimiento: Alguna gente se cree que tener todos los sistemas de archivos en el kernel, o la emulación de coprocesador matemático va a hacer las cosas mas lentas. ¿Por qué? No se trata mas que de un gran IF: Si algo no se usa, no tiene porque afectar al resto. El código de un dispositivo que no se tiene jamás se ejecutará. Y por supuesto la mayoría de kernels precompilados no hacen esas cosas – se modularizan las cosas exageradamente, hasta el punto que algunas distros nisiquiera compilan el sistema de archivos del sistema de archivos root / en el kernel, compilan todos como módulo y cargan el necesario en el initrd
  • Razón 5: Tener muchos módulos es útil: La gente suele compilar su kernel porque quiere “compilar solo el soporta para su hardware y quitar el resto”. Esto está relacionado con el punto anterior. La pregunta es: ¿Por qué? Los módulos no utilizan nada más que espacio en el disco al menos que no se carguen. Probablemente tengas un /usr/X11R6/lib/modules/drivers/vmware_drv.o en tu sistema. ¿Recompilas las X solo para desactivar ese driver? ¿Recompilas para desactivar las librerias de accesibilidad de gnome solo porque no las necesitas? Tener 100 o los módulos que sean ahí no hace daño. Tampoco es ninguna guarrada: Es lo correcto. El objetivo del kernel es que tu hardware funcione, y el soportar más hardware del que tienes significa que podrás cambiar de hardware sin recompilar el kernel: Y esto es importante para todos, porque con USB y firewire es imposible determinar en tiempo de compilación que dispositivos vas a acabar conectando a tu equipo. La flexibilidad es una característica del software, y es buena.

    Una vez sufrí un problema relacionado con esto: No tengo un lápiz USB, asi que no tenía compilado el soporte. Pero resulta que un amigo vino con un disco duro externo USB, y como no tenia ganas de hacerle soportar la espera de compilar un kernel, tuve que iniciar en Windows. Windows paraba la transferencia a la mitad y el driver dejaba de funcionar asi que finalmente tuve que hacer esperar a mi amigo. Moraleja: Un sistema moderno tiene USB y firewire y por lo tanto no tiene una configuración de hardware estática

    Udev es quien se encarga de hacer gran parte del trabajo de configurar el hardware del sistema y cargar los modulos de tu hardware y no cargar los que no son. Si yo por ejemplo enchufo mi webcam Creative Go Plus, el kernel notifica a udev de que se ha insertado un dispositivo en el bus usb, udev mira que es mirando identificando el hardware y carga los dos ó 3 módulos de soporte básico de USB, el módulo de la camara, el módulo del chip de la camara, y el módulo de V4l. Automaticamente. Pero si no la enchufo, no las carga, y puedo hacer que udev descargue los módulos cuando desenchufo la cámara – no hay “bloatware” en ningún lado. Las máquinas se inventaron para hacer cosas por nosotros. Utilizalas para ello y utiliza un kernel precompilado y udev. Muchisima gente de la que compila su kernel a mano no activa el soporte de hotplug (necesario para udev), porque piensa “que no lo necesita”. Lo cual nos lleva al siguiente punto

  • Razón 6: Configurar el kernel no es fácil y los mantenedores del paquete precompilado saben que necesitas mucho mejor que tú, aunque no lo creas: El número de opciones disponibles en la fase de configuración del kernel se multiplica en cada versión, y a día de hoy es prácticamente imposible saber configurar correctamente todas las opciones. Mi config tiene 1034 opciones diferentes entre las activadas y desactivadas. ¿Sabes configurar correctamente esas 1034 opciones? Puedes pensar que sabes, pero siendo realistas no hay nadie en el mundo que sepa configurar por si mismo un kernel por completo. Yo llevo años compilando decenas y decenas de kernels por afición al desarrollo del kernel, y aun hay muchas opciones que no se que hacen, ni si debería activarlas o no. Ni tan siquiera los hackers del kernel lo saben, ni Linus Torvalds, te lo aseguro (bueno, quizás Alan Cox…) Los que mantienen una arquitectura no se enteran de que cosas están haciendo los del soporte USB, y viceversa. Por si fuera poco, muchas opciones no están documentadas (o están mal documentadas, que es peor), algunas son peligrosas y otras no puedes saber si activarlas o desactivarlas porque simplemente te da lo mismo (como pasa con cualquier proyecto software que tenga este tamaño: nadie puede conocer 200 MB de código C, además en linux se tiene la “manía” de hacer todo extremadamente configurable hasta el punto que dudo mucho que exista un kernel más configurable) Y la configuración por defecto que trae el kernel de kernel.org está muy lejos de tener los valores por defecto ideales. Moraleja: Deja que los mantenedores de tu distribución se ocupen de la compleja tarea de configurar el kernel. Ellos tienen los recursos (varias personas, sistemas de seguimiento de bugs por si se equivocan en algo, etc) para hacerlo, tú no.

¿Y esto para que lo escribo? Para intentar evitar que la gente se pase la vida compilando kernels por “tradición”. Eso no quiere decir que esté prohibido compilarles: Compilar kernels es una actividad divertida y entretenida para un geek, siempre que tenga una razón para ello (por ejemplo, que le da la gana). Lo absurdo es hacer lo que hace la gente: Compilar por que si, sin tan siquiera tener ganas, como si fuera una “obligación” a su estatus de “geek”.

Saludos…

Fuente

Redes, Tipos (tipología)

Conjunto de equipos con la capacidad de intercomunicarse entre sí. A los equipos que forman parte de una red los denominamos nodos. Por lo que al principio todos eran redes P2P.

  • Redes PEER TO PEER (punto a punto): Los nodos solicitan/prestan recursos de forma indistinta (mismo nivel).
  • Redes CERRADAS: Nodos especializados en dar servicios web (Servidores) y nodos en solicitudes (Clientes) particularizados por cada fabricante de hardware.
  • Redes ABIERTAS: El ISO (Organismo Internacional) homologó un estándar de comunicaciones para todos los fabricantes, para que todos los fabricantes de distintas redes se comunicaran entre sí.

Tipos de Nodos

Clientes: Estaciones de trabajo que solicitan un servicio.
Servidores: Estaciones de trabajo que prestan un servicio.

  • Servidores no dedicados: Pueden funcionar como servidor y estación de trabajo.
  • Servidores dedicados: Solo funcionan como servidor.

Elementos/Componentes de una red

Hardware: Elemento físico que se encarga de la transmisión física de los datos de una red.

  • Medio de conexión: Cable (coaxial, UTP, TP, …), fibra, ondas, radio, …
  • Emisores/Receptores: Tarjetas de red, modems, puntos de acceso directo, wireless, …
  • Interconexiones: Repetidores, hubs, switches, routers, bridges, …
  • Nodos: Cliente/Servidor.

Software: Aplicaciones de red con las que el usuario interactua, existe software de red específico para clientes y para servidores.

Topología de red (Tipología de redes)

Forma en la que los nodos se interconectan entre sí (viene definido por el tipo de hardware de red que se utilice):

  • Topología lógica: Se clasifican las redes según la forma de transmisión/recepción de los datos en nodos:
    • Redes FULL-DUPLEX: Los nodos mandan/reciben datos a través del mismo medio.
    • Redes HALF-DUPLEX: Los nodos mandan datos a través de un medio distinto al que reciben.
    • Redes SIMPLEX: Es la fibra óptica.
  • Tipología física: Las redes se clasifican en función a la forma en la que los nodos se conectan entre sí, y tenemos los siguientes tipos:

    • Red en Bus:
      La estación central es un cable central al que se conectan los nodos.
      Este cable es coaxial:
      • 10 Base 2 (thinnet)
      • 10 Base 5 (thicnet)

      El ancho de banda teórico es de 10Mbps (MegaBits/s).
      Y la estructura del cable es: Aislante, rejilla (mallazo), aislante y cable.
      La distancia entre nodos puede ser de 200 metros (en base 2) o de 500 metros (en base 5).
      BNC –> Terminadores necesarios para devolver la señal al bus.

      • Inconvenientes:
        Sin BNC la red no funciona.
        Si desconectas un nodo, dejas sin conexión al bus a los nodos que queden detrás.
      • Ventajas:
        Distancia entre nodos.
        Bajo coste.
    • Red en Estrella:
      Los nodos están conectados a un dispositivo central encargado de repetir la señal.
      La red de estrella extendida es lo mismo pero con otro dispositivo de interconexión entre dos redes de estrella.
      Las redes típicas para áreas locales pequeñas se llaman LAN, redes metropolitanas que interconectan las LAN son MAN y las redes que interconectan MAN son WAN.
      En las LAN, el tipo de cable que se utiliza es el TP (”Twisted Pair” o de par tenzado) y está formado por 8 pares de hilos trenzados entre sí. Existen dos tipos de cable TP:
      • UTP: TP sin malla metálica sin refuerzo y aislante de ruido.
      • STP: TP con malla metálica con refuerzo y aislante de ruido.

      El posible ancho de banda es de 10Mbps a 10000Mbps.
      El cable TP puede ser:

      • Straight-Throgh (normal) –> Sierve para conectar en LAN ethernet. Misma secuencia de colores en los extremos, y conecta PC-Dispositivo de Interconexión.
      • CrossOver (cruzado) –> Conecta dos PC’s entre sí, sin necesidad de dispositivo de interconexión.

      Inconvenientes:

      • Máximo 50 metros entre nodos.
      • Fragilidad del UTP.
      • Colisión en comunicación.

      Ventajas:

      • Ancho de Banda.
      • Facilidad de conectar y desconectar un nodo.
    • Red en Circulo:
      También llamadas Token-Ring de IBM. No existen colisiones por que existe un token girando constantemente en el anillo en el cual los nodos mandan/reciben datos.
    • Red en Malla:
      Cada ordenador debe poseer n-1 tarjetas de red siendo n el número de ordenadores.

Existen una gran diversidad de formas de redes, pero creo que con estas son más que suficientes.

Fuente

Interfazes y Herencia en Java

__________________________________________________________________
HERENCIA
__________________________________________________________________

La Herencia es el mecanismo por el que se crean nuevos objetos definidos en términos de objetos ya existentes. Por ejemplo, si se tiene la clase Ave, se puede crear la subclase Pato, que es una especialización de Ave.

1
2
3
 class Pato extends Ave {
        int numero_de_patas;
        }

La palabra clave extends se usa para generar una subclase (especialización) de un objeto. Una Pato es una subclase de Ave. Cualquier cosa que contenga la definición de Ave será copiada a la clase Pato, además, en Pato se pueden definir sus propios métodos y variables de instancia. Se dice que Pato deriva o hereda de Ave.

Además, se pueden sustituir los métodos proporcionados por la clase base. Utilizando nuestro anterior ejemplo de MiClase, aquí hay un ejemplo de una clase derivada sustituyendo a la función Suma_a_i():

1
2
3
4
5
6
 import MiClase;
    public class MiNuevaClase extends MiClase {
        public void Suma_a_i( int j ) {
            i = i + ( j/2 );
            }
        }

Ahora cuando se crea una instancia de MiNuevaClase, el valor de i también se inicializa a 10, pero la llamada al método Suma_a_i() produce un resultado diferente:

1
2
3
 MiNuevaClase mnc;
    mnc = new MiNuevaClase();
    mnc.Suma_a_i( 10 );

En Java no se puede hacer herencia múltiple. Por ejemplo, de la clase aparato con motor y de la clase animal no se puede derivar nada, sería como obtener el objeto toro mecánico a partir de una máquina motorizada (aparato con motor) y un toro (aminal). En realidad, lo que se pretende es copiar los métodos, es decir, pasar la funcionalidad del toro de verdad al toro mecánico, con lo cual no sería necesaria la herencia múltiple sino simplemente la compartición de funcionalidad que se encuentra implementada en Java a través de interfaces.

__________________________________________________________________

INTERFAZ
__________________________________________________________________

• Una Interfaz es una especificación para las operaciones externas
visibles de una clase, componente, o otra entidad (incluyendo
unidades globales como los paquetes), pero siempre sin
especificar la estructura interna

• Cada interfaz especifica a menudo sólo una parte limitada del
comportamiento de una clase real

• Una interfaz no tiene implementación

• Una Interfaz es formalmente equivalente a una clase abstracta sin
atributos y sin métodos, con sólo operaciones abstractas

• Un interfaz se puede representar de dos formas:
– Circulo unido por una línea a una clase con las operaciones de
interfaz al lado del círculo
– Rectángulo con la palabra reservada <> y la sección de
operaciones

• Una clase que usa las operaciones de una interfaz se une por
medio de una flecha de línea discontinua a los círculos o al
rectángulo de la interfaz

• También se puede utilizar la “relación Realiza” desde una clase a
una interfaz que soporta

Un interface es parecido a una clase abstracta en Java, pero con las siguientes diferencias:

- Todo método es abstracto y público sin necesidad de declararlo. Por lo tanto un interface en Java no implementa ninguno de los métodos que declara.

- Las varibles del interface serán las variables miembro de la clase.

- Un interface se implementa (implements) no se extiende (extends) por sus subclases.

- Una clase puede implementar más de un interfaz en Java, pero sólo puede extender una clase. Es lo más parecido que tiene Java a la herencia múltiple, que de clases normales está prohibida.

- Podemos declarar variables del tipo de clase del interfaz, pero para inicializarlas tendremos que hacerlo de una clase que lo implemente.

Así, por ejemplo, podemos declarar el siguiente interfaz en Java:

1
2
3
       interface Figura{
    int area();
    }

y una clase que lo implementa:

1
2
3
4
5
6
7
      public class Cuadrado implements Figura {
    int lado;
    public Cuadrado (int ladoParametro) {
    lado = ladoParametro;
    }
 
    public int area(){ return lado*lado; }}

Más adelante podemos:

1
2
3
4
5
6
    public class PruebaInterfaz{
    public static void main(String args[]){
    Figura figura=new Cuadrado (5);
    //Podemos crear una referencia de interface(variable r) y que un objeto que pertenezca
    // a una clase que la implementa le sea asignada a la variable
    System.out.println(figura.area());}

Saludos…

Mas ejemplos en ingles
Fuente1
Fuente2
Fuente3

Como iniciar nuestro GNU/Linux con la tecla bloq num activada

Muchas de mis contraseñas, incluida la de Ubuntu, posee números. Para iniciar la sesión siempre tengo que activar el Bloq Num (Num Lock) lo que me resulta un poco incomodo.

Por ello buscando encontré esta solución:

Instalar numlockx:

guido@guido-amd ~ $ sudo apt-get install numlockx

Este programa activa el Bloq Num, pero esto lo realiza una ves iniciada la sesión. Como lo que quiero es que se active en la ventana de login lo que hay que hacer es editar el archivo /etc/gdm/Init/Default

guido@guido-amd ~ $ gksudo gedit /etc/gdm/Init/Default

Al final del texto en una linea antes de “exit 0″ agregamos:

if [ -x /usr/bin/numlockx ]; then
/usr/bin/numlockx on
fi

Guardamos y cerramos, listo la próxima ves que ves la sesión de login estará prendida la luz del teclado.

Si tienen miedo de andar toqueteando, hagan una copia por si las dudas…

guido@guido-amd ~ $ sudo cp /etc/gdm/Init/Default /etc/gdm/Init/Default-Original

Saludos…

Sidux – Otra Distribucion Linux


Sidux
es una distribución del sistema operativo GNU/Linux basada en la rama “inestable” de Debian, llamada Sid.
La distribución consiste de un Live-CD (CD-ROM autoarrancable) para las arquitectuas i386 y amd64, y puede ser instalado en el disco duro mediante un instalador gráfico. Sidux está mantenida por un pequeño grupo de desarrolladores, incluyendo al antiguo desarrollador de Kanotix, llamado Stefan Lippers-Hollmann (slh). La administración es manejada por la Fundación sidux, en inglés, The sidux Foundation, Inc. locazalizada en Estados Unidos.

Los lanzamientos de sidux contienen sólo software libre como ha sido definido por Debian Free Software Guidelines (DFSG). Para ayudar a aprobar el cumplimiento de la GPL, un tarball monolítico proporciona el conteniendo de las fuentes de todos los paquetes de programas usados en el lanzamiento junto a la imagen, en formato ISO, dentro del LiveCD. El acceso al software no libre, como codecs, plugins(agregados) y el firmware de wlan puede ser validado puede permitir ser configurando desde los repositorios contrib y non-free de Debian y sidux en el archivo /etc/apt/sources.list.

De acuerdo con la naturaleza evolutiva de la rama “inestable” de Debian, las liberaciones de sidux no proporcionan un camino de mejoras(upgrade path) de las versiones de liberación anteriores. Más bien, una vez que sidux está instalado, las actualizaciones incrementales son realizadas mediante la forma regular “dist-upgrade”. La idea de un lanzamiento sidux es para mejorar el soporte de hardware del LiveCD, el funcionamiento, la flexibilidad y la fiabilidad, construida desde el actual repositorio de Debian.

Sidux también proporciona un instalador en modo “meta-paquete”. para la instalación de los paquetes relacionados a los requisitos comunes, vía un proceso de instalación gráfica. Los meta-paquetes existentes incluyen seguridad, gráficos, juegos, software educativo y proporcionan soporte a las computadoras más antiguas.

El idioma por defecto de sidux es el inglés, aunque el soporte para el alemán, en la internacionalización, i18n, está también disponible. Existe un manual que incluye el método para la traducción hacia otros idiomas, incluyendo el aleman, italiano, español, ruso y francés.

En cuanto al escritorio, utiliza KDE.

Aqui unas capturas de su entorno:

DVD live para i386 y AMD (1.43 Gb)
Opcion1
Opcion2


Live Cd para AMD (436 Mb)

Live Cd para i386 (428 Mb)

Manual en español

Para mayor informacion sobre Sidux, visita su pagina oficial:
http://sidux.com/

 
Follow Me Hazte Fan Subscribe