Whitix es un nuevo sistema operativo, escrito desde cero, y su objetivo es combinar la estabilidad de UNIX con la facilidad de uso de otras plataformas. Al parecer dice ser una oferta coherente, su interfaz es clara y una nueva forma de navegar por el escritorio. El proyecto ya publicó la versión 0.2, licenciado bajo la GPL. vía: http://infosertec.blogspot.com/2009/01/otro-sistema-operativo-liberado-se.html
No entiendo porque reinventar la rueda...
Si querian hacer una nueva organización del sistema más clara con un nuevo kernel, pues se podría haber sustituido el de GNU/Linux y seguir utilizando GNU, bajo GNU/Whitix, o algo así.
#1 y #10 Teniendo en cuenta que el autor se llama Matthew Whitworth, no hay que atar muchos hilos para saber de donde viene el nombre.
Para todos los que critican un nuevo SO o dicen que no hace falta reinventar la rueda, a mi me parece fabuloso que haya nuevas aportaciones con ideas frescas. La "competencia" es lo mejor que le puede pasar a los desarrollos de software.
#20 gracias, conozco setjmp / longjmp. ¿Cómo vas a hacer un longjmp desde el nucleo al espacio del usuario? ¿Cómo vas a hacer un longjmp desde una función si no sabes cual de las 4000 otras te ha podido llamar? Ah, que vas a tener una tabla de manejadores excepciones. Añade el overhead de estar configurando esa tabla cada vez que vas a llamar a una función, y luego peleate para que eso funcione en un entorno multihilo ¿Tampoco vas a dar a la función que te llama la posibilidad de corregir el error o usar una función alternativa?
2. El compilador ve que la rama else tiene un return, y añadirá el return 0 final al interior de la rama if. Resultado, si entra en el if no hay saltos.
Los programadores de sistemas operativos ya saben que no han de hacer pooling ni escribir al disco sin necesidad. Eso no quita que no deban escribir código óptimo.
A ti te parecerá una tontería. Yo tampoco sacrifico la legibilidad por la eficiencia en mis proyectos, pero has de entender que en tareas críticas como en un cambio de contexto, liberando memoria y en general en la gran mayoría del código de un kernel, unos ciclos de reloj sí importan.
Si aun piensas que ese código está mal, bájate el kernel de linux y reorganiza todo el código para no usar gotos, a ver si te aceptan el parche esos chapuceros. Ahora mismo (2.6.28) tienen 58.225 gotos.
#9 Es libre, está licenciado bajo la GPL v2-or-later (que ya es más que Linux, que usa la GPL v2-only).
Lo puedes ver si miras algún archivo fuente http://bugs.whitix.org/browser/Whitix/trunk
Además, sí que usan algunos de los componentes del sistema GNU (aunque no todos, por ejemplo en lugar de bash usan burn, desarrollado por ellos, que segun dicen es más "user-friendly").
1. ningún SO he visto usar excepciones a bajo nivel. Sí es normal que las funciones devuelvan un código de error, es más rápido. Este método concreto de retornar valores 0 o positivos si no hay error y valores negativos del estilo -CODIGODEERROR es el mismo que sigue el kernel de linux.
2. Primero comprueba si el valor es válido para ejecutar la operación lo más rápido posible (es más rápido entrar en el if que saltar al else).
3. Si no te gusta ENOTIMPL tampoco te gustará demasiado errno.h, del standard de C. Volvemos a lo de antes, es C, se utilizan nombres así, nunca nombres largos, tienes más probabilidades de equivocarte al escribir nombres largos. Por cierto la API de Microsoft tiene E_NOTIMPL.
Hombre... el nombre ya no es muy original pues parece una mezcla de Unix, Linux, Mimix, Multix... pero bueno, sólo es un apunte Habrá que instalarlo y ver qué tal se porta el Whitix.
#1 Los nombres nunca han sido el punto fuerte de la comunidad linuxera(Mandriva... ) y en el caso de kde 3, tampoco los sonidos de los eventos que algunos son literalmente chirridos (probad a minimizar, maximizar ventanas y el de los platos rotos...)
PD: uso kde 3 o gnome segun me dé, pero no pretendo iniciar ningún flame.
Digo yo que el kernel de linux es lo suficientemente flexible para no tener que estar reinventando la rueda cada vez, pero vamos que como pasatiempo no está mal.
Podría llegar a ser un substituto ideal para el kernel Linux (¿y tal vez ayudar al desarrollo de Hurd?).. siempre que se porte el sistema GNU a este kernel
Meneo porque es un sistema operativo libre, pero vamos... la forma en que se presenta en la entradilla es completamente erronea (tampoco mucho peor de la que se prensentan ellos mismos).
la cuestión que nunca se dice en estas noticias es: ¿favorece la libertad? supongo que si es abierto...tendrá posibilidades. Pero...¿es gnu? weno, iré a leer la noticia, aunque me temo que me hablará de cuestiones técnicas que nada digan de la libertad humana.
dice que es free, lo cual en inglés no se sabe qué huevos es: si es gratis o libre. Desde luego la información está capada. Supongo que será gratis y no libre, sinó diría "free as in freedom"
Weno, parece que todo el mundo quiere lanzar su propio SO, lo malo es que el gnu-linux está desaprovechado y seguimos dispersándonos, pero no diré que eso es malo: tiene su parte buena y su parte mala.
Primero, (ABC de la programación). Se comprueban los errores antes de empezar el cuerpo real de la función:
359 int SysExitThread(int threadId)
360
Segundo, nunca debe utilizarse el valor devuelto para indicar un error. Si hay error se genera una excepción (lngjmp al cuerpo de gestión de errores), no se codifica en el valor devuelto, que debe ser void ya que no devuelve valor alguno.
359 void SysExitThread(int threadId)
360
362 ThrDoExitThread();
363 ">
¿Que significa ENOTIMPL? Supongo que "error no thread implementation" o algo por el estilo, pero en el año 2009 con portátiles de 300 Euros con 2 Gigas de RAM y 320 Gigas de disco duro, se podrían dejar de "hacer el poyas" con las abreviaturas para ahorra 4 bytes.
En definitiva, no le veo ningún futuro con esa forma de escribir código (2 errores graves en 6 lineas de código efectivo).
#16 No, no es más rápido devolver un código de error que un setjmp/longjmp (http://en.wikipedia.org/wiki/Longjmp). El código de error debe comprobarse por cada "salto en la pila". Sí el código que genera el error se produce en el séptimo nivel hace falta 7 "ifs" comprobando el valor devuelto. Si en uno solo de eso 7 "ifs" olvidamos comprobar el valor devuelto el código falla. Lo que te cuento no es una opinión, es un hecho comprobado matemáticamente y reduce el nivel de entropía del código (el nivel de variables/estados intermedios posibles). La pena es que con tanto marketingware del OOP se olvida los principios básicos de la programación estructurada.
2.- No, no es más rápido.
El código anterior en lenguaje máquina se traduce en algo similar a:
rjmpnz ... ("relative jump no zero") opción A
o bien
rjmpz ... ("relative jump zero) opción B
es decir, la comparación se tiene que hacer siempre y el resultado guardarse en un registro de estado. A continuación hay que realizar un salto condicional en función del estado. Es decir que no se gana velocidad alguna haciendo una cosa o la contraria. El hecho de que aparezca escrito antes en el código no significa que se ejecute antes.
Aun en el hipotético (absurdo) caso de que así fuera (y te aseguro que no lo es), cualquier análisis de profiling dejaría claro que no merece la pena complicar el código para ganar, en el mejor y más optimista de los casos, un ciclo de reloj. ¿Qué ocurre si más tarde queremos hacer comprobaciones extra? Pues que el código se empieza a complicar más y más y tenemos que empezar a añadir if anidados y cómo codificamos varios tipos de errores en el valor devuelto. Y si queremos añadir información adicional del error, ¿Dónde la guardamos, si sólo tenemos un int para devolver toda la información?
Si queremos ganar velocidad, lo que hay que hacer es sustituir "poolings" por interrupciones, cachear las entradas/salidas y evitar cuellos de botella. Un sólo dato enviado a disco y que pudiese ser cacheado puede consumir alrededor de 100.000 ciclos de reloj y es allí donde hay que optimizar, pero nunca complicar/ensuciar el código para ganar un solo ciclo de reloj.
3.- El C del que tú hablas se creó a finales de los 70 al igual que el primer UNIX, cuando todavía era normal trabajar con disketes de 180Kbytes (mi primer PC llegó en el año 92, tenía 1Mega de RAM y 20 Mbyte de disco duro, en esas condiciones sí que tenía sentido utilizar crípticas abreviaturas para salvar espacio). De lo que me quejo es que hoy en día se sigua utilizando estas estúpidas abreviaturas que dificultan la lectura y que tenía sentido utilizarlas en los años 80 cuando la memoria escaseaba y los programas se imprimian en papel porque la VGA de 640x480 era el futuro lejano, pero no en el año 2009 con netbooks de 300 Euros y gigas de RAM y disco duro. Ahora mismo estoy trabajando con un PC de 1920x1200 de resolución, 2Gigas de RAM y 180 Gigas de disco duro que me costó 550Euros en Dell.es. Sólo los iconos bmp de la barra de herramientas del Firefox probablemente ya ocupen más memoria que todas las constantes de error definidas en el kernel. Intentan crear un UNIX "moderno", desde cero y para ello utilizar chapucillas de los años 70. Así no van a ningún lado. Para eso ya tenemos Linux, Solaris, BSD, Minix y algún otro que me olvido.
Comentarios
Lo he probado y la verdad es que no está nada mal! Muy ligero y la interfaz muy chula tb. recomendado
No entiendo porque reinventar la rueda...
Si querian hacer una nueva organización del sistema más clara con un nuevo kernel, pues se podría haber sustituido el de GNU/Linux y seguir utilizando GNU, bajo GNU/Whitix, o algo así.
#1 y #10 Teniendo en cuenta que el autor se llama Matthew Whitworth, no hay que atar muchos hilos para saber de donde viene el nombre.
Para todos los que critican un nuevo SO o dicen que no hace falta reinventar la rueda, a mi me parece fabuloso que haya nuevas aportaciones con ideas frescas. La "competencia" es lo mejor que le puede pasar a los desarrollos de software.
los cambios de whitix son bastante irrelevantes, no aporta nada
#20 gracias, conozco setjmp / longjmp. ¿Cómo vas a hacer un longjmp desde el nucleo al espacio del usuario? ¿Cómo vas a hacer un longjmp desde una función si no sabes cual de las 4000 otras te ha podido llamar? Ah, que vas a tener una tabla de manejadores excepciones. Añade el overhead de estar configurando esa tabla cada vez que vas a llamar a una función, y luego peleate para que eso funcione en un entorno multihilo ¿Tampoco vas a dar a la función que te llama la posibilidad de corregir el error o usar una función alternativa?
2. El compilador ve que la rama else tiene un return, y añadirá el return 0 final al interior de la rama if. Resultado, si entra en el if no hay saltos.
Los programadores de sistemas operativos ya saben que no han de hacer pooling ni escribir al disco sin necesidad. Eso no quita que no deban escribir código óptimo.
A ti te parecerá una tontería. Yo tampoco sacrifico la legibilidad por la eficiencia en mis proyectos, pero has de entender que en tareas críticas como en un cambio de contexto, liberando memoria y en general en la gran mayoría del código de un kernel, unos ciclos de reloj sí importan.
Si aun piensas que ese código está mal, bájate el kernel de linux y reorganiza todo el código para no usar gotos, a ver si te aceptan el parche esos chapuceros. Ahora mismo (2.6.28) tienen 58.225 gotos.
#9 Es libre, está licenciado bajo la GPL v2-or-later (que ya es más que Linux, que usa la GPL v2-only).
Lo puedes ver si miras algún archivo fuente http://bugs.whitix.org/browser/Whitix/trunk
Además, sí que usan algunos de los componentes del sistema GNU (aunque no todos, por ejemplo en lugar de bash usan burn, desarrollado por ellos, que segun dicen es más "user-friendly").
Para la interfaz gráfica usan Xynth (http://www.xynth.org/) en lugar de X.org
Pero por lo visto al kernel todavia le falta para ser más maduro y de momento no van a funcionar todos los programas sobre él.
#12 BeOS ? goto Haiku
#15
1. ningún SO he visto usar excepciones a bajo nivel. Sí es normal que las funciones devuelvan un código de error, es más rápido. Este método concreto de retornar valores 0 o positivos si no hay error y valores negativos del estilo -CODIGODEERROR es el mismo que sigue el kernel de linux.
2. Primero comprueba si el valor es válido para ejecutar la operación lo más rápido posible (es más rápido entrar en el if que saltar al else).
3. Si no te gusta ENOTIMPL tampoco te gustará demasiado errno.h, del standard de C. Volvemos a lo de antes, es C, se utilizan nombres así, nunca nombres largos, tienes más probabilidades de equivocarte al escribir nombres largos. Por cierto la API de Microsoft tiene E_NOTIMPL.
Hombre... el nombre ya no es muy original pues parece una mezcla de Unix, Linux, Mimix, Multix... pero bueno, sólo es un apunte Habrá que instalarlo y ver qué tal se porta el Whitix.
#1 Los nombres nunca han sido el punto fuerte de la comunidad linuxera(Mandriva... ) y en el caso de kde 3, tampoco los sonidos de los eventos que algunos son literalmente chirridos (probad a minimizar, maximizar ventanas y el de los platos rotos...)
PD: uso kde 3 o gnome segun me dé, pero no pretendo iniciar ningún flame.
Digo yo que el kernel de linux es lo suficientemente flexible para no tener que estar reinventando la rueda cada vez, pero vamos que como pasatiempo no está mal.
P.D: Que vuelva BeOS
hmm... esto es realmente interesante http://www.whitix.org/blog/?p=24
Podría llegar a ser un substituto ideal para el kernel Linux (¿y tal vez ayudar al desarrollo de Hurd?).. siempre que se porte el sistema GNU a este kernel
Meneo porque es un sistema operativo libre, pero vamos... la forma en que se presenta en la entradilla es completamente erronea (tampoco mucho peor de la que se prensentan ellos mismos).
#14 que alivio, ya estaba pensando que lo de 'white' era por alguna filia con el Ku Kux Klan ó_ò
la cuestión que nunca se dice en estas noticias es: ¿favorece la libertad? supongo que si es abierto...tendrá posibilidades. Pero...¿es gnu? weno, iré a leer la noticia, aunque me temo que me hablará de cuestiones técnicas que nada digan de la libertad humana.
dice que es free, lo cual en inglés no se sabe qué huevos es: si es gratis o libre. Desde luego la información está capada. Supongo que será gratis y no libre, sinó diría "free as in freedom"
Weno, parece que todo el mundo quiere lanzar su propio SO, lo malo es que el gnu-linux está desaprovechado y seguimos dispersándonos, pero no diré que eso es malo: tiene su parte buena y su parte mala.
Miro un poco por encima el código (http://bugs.whitix.org/browser/Whitix/trunk/kernel/thread.c) y lo veo débil, débil.
359 int SysExitThread(int threadId)
360
¿Veís tantos fallos como veo yo?
Primero, (ABC de la programación). Se comprueban los errores antes de empezar el cuerpo real de la función:
359 int SysExitThread(int threadId)
360
Segundo, nunca debe utilizarse el valor devuelto para indicar un error. Si hay error se genera una excepción (lngjmp al cuerpo de gestión de errores), no se codifica en el valor devuelto, que debe ser void ya que no devuelve valor alguno.
359 void SysExitThread(int threadId)
360
362 ThrDoExitThread();
363 ">
¿Que significa ENOTIMPL? Supongo que "error no thread implementation" o algo por el estilo, pero en el año 2009 con portátiles de 300 Euros con 2 Gigas de RAM y 320 Gigas de disco duro, se podrían dejar de "hacer el poyas" con las abreviaturas para ahorra 4 bytes.
En definitiva, no le veo ningún futuro con esa forma de escribir código (2 errores graves en 6 lineas de código efectivo).
Para empezar la página lleva 3 minutos sin abrirse el enlace, todavía ni se como es.
#16 No, no es más rápido devolver un código de error que un setjmp/longjmp (http://en.wikipedia.org/wiki/Longjmp). El código de error debe comprobarse por cada "salto en la pila". Sí el código que genera el error se produce en el séptimo nivel hace falta 7 "ifs" comprobando el valor devuelto. Si en uno solo de eso 7 "ifs" olvidamos comprobar el valor devuelto el código falla. Lo que te cuento no es una opinión, es un hecho comprobado matemáticamente y reduce el nivel de entropía del código (el nivel de variables/estados intermedios posibles). La pena es que con tanto marketingware del OOP se olvida los principios básicos de la programación estructurada.
2.- No, no es más rápido.
El código anterior en lenguaje máquina se traduce en algo similar a:
rjmpnz ... ("relative jump no zero") opción A
o bien
rjmpz ... ("relative jump zero) opción B
es decir, la comparación se tiene que hacer siempre y el resultado guardarse en un registro de estado. A continuación hay que realizar un salto condicional en función del estado. Es decir que no se gana velocidad alguna haciendo una cosa o la contraria. El hecho de que aparezca escrito antes en el código no significa que se ejecute antes.
Aun en el hipotético (absurdo) caso de que así fuera (y te aseguro que no lo es), cualquier análisis de profiling dejaría claro que no merece la pena complicar el código para ganar, en el mejor y más optimista de los casos, un ciclo de reloj. ¿Qué ocurre si más tarde queremos hacer comprobaciones extra? Pues que el código se empieza a complicar más y más y tenemos que empezar a añadir if anidados y cómo codificamos varios tipos de errores en el valor devuelto. Y si queremos añadir información adicional del error, ¿Dónde la guardamos, si sólo tenemos un int para devolver toda la información?
Si queremos ganar velocidad, lo que hay que hacer es sustituir "poolings" por interrupciones, cachear las entradas/salidas y evitar cuellos de botella. Un sólo dato enviado a disco y que pudiese ser cacheado puede consumir alrededor de 100.000 ciclos de reloj y es allí donde hay que optimizar, pero nunca complicar/ensuciar el código para ganar un solo ciclo de reloj.
3.- El C del que tú hablas se creó a finales de los 70 al igual que el primer UNIX, cuando todavía era normal trabajar con disketes de 180Kbytes (mi primer PC llegó en el año 92, tenía 1Mega de RAM y 20 Mbyte de disco duro, en esas condiciones sí que tenía sentido utilizar crípticas abreviaturas para salvar espacio). De lo que me quejo es que hoy en día se sigua utilizando estas estúpidas abreviaturas que dificultan la lectura y que tenía sentido utilizarlas en los años 80 cuando la memoria escaseaba y los programas se imprimian en papel porque la VGA de 640x480 era el futuro lejano, pero no en el año 2009 con netbooks de 300 Euros y gigas de RAM y disco duro. Ahora mismo estoy trabajando con un PC de 1920x1200 de resolución, 2Gigas de RAM y 180 Gigas de disco duro que me costó 550Euros en Dell.es. Sólo los iconos bmp de la barra de herramientas del Firefox probablemente ya ocupen más memoria que todas las constantes de error definidas en el kernel. Intentan crear un UNIX "moderno", desde cero y para ello utilizar chapucillas de los años 70. Así no van a ningún lado. Para eso ya tenemos Linux, Solaris, BSD, Minix y algún otro que me olvido.
Todas las alternativas a los sistemas operativos propietarios, serán bienvenidas
Eramos pocos y parió la abuela...