Portada
mis comunidades
otras secciones
#7:
1. Totalmente de acuerdo
2. Están por demostrar las ventajas de los microkernels (funcionalidad vs. rendimiento). El núcleo de Linux es monolítico PERO modular. Quizá una modularización más fina y un ABI estable pudiesen ayudar.
3. udev+hal+dbus son un estándar hoy en día. Lo que quieras implementar por encima ya es cosa del usuario.
4. Tarde o temprano los parches que se demuestran estables y que no interfieren con el funcionamiento normal del núcleo, pasan al núcleo.
5. Un Sistema Operativo no debe saber de "formatos". Es absurdo que el sistema operativo sepa qué es un mp3, un jpg y demás, de eso se encargan las bibliotecas de usuario (otra cosa es estandarizar esas bibliotecas). El sistema operativo ya da mecanismos de comunicación estándares (colas de mensajes, memoria compartida, etc...)
6. Una vez más, eso es cosa del espacio de usuario. El sistema operativo ya te da TCP/IP para que implementes lo que quieras. Podría existir una biblioteca estándar de Bittorrent, pues bueno, pero no es el objetivo de un sistema operativo. Puede ser objetivo de un entorno de escritorio como KDE o GNOME.
7. Totalmente de acuerdo, pero el principio KISS choca frontalmente con querer incluir toda la funcionalidad dentro del núcleo (por no mencionar que es totalmente contrario al concepto de microkernel)
8. DBUS+bindings (por ejemplo Ruby, TCL, Python, será por lenguajes de Script). No es tarea del sistema operativo implementar lenguajes.
9. apt-build
10. Ya se hace a nivel de entorno de escritorio.
Dicho esto, parece que lo que quiere es una distribución unificada, con un sólo entorno de escritorio, una sóla biblioteca de cada tipo, un único programa de cada tipo, etc. Eso ya existe, así que poca mejora ofrece.
2. Están por demostrar las ventajas de los microkernels (funcionalidad vs. rendimiento). El núcleo de Linux es monolítico PERO modular. Quizá una modularización más fina y un ABI estable pudiesen ayudar.
3. udev+hal+dbus son un estándar hoy en día. Lo que quieras implementar por encima ya es cosa del usuario.
4. Tarde o temprano los parches que se demuestran estables y que no interfieren con el funcionamiento normal del núcleo, pasan al núcleo.
5. Un Sistema Operativo no debe saber de "formatos". Es absurdo que el sistema operativo sepa qué es un mp3, un jpg y demás, de eso se encargan las bibliotecas de usuario (otra cosa es estandarizar esas bibliotecas). El sistema operativo ya da mecanismos de comunicación estándares (colas de mensajes, memoria compartida, etc...)
6. Una vez más, eso es cosa del espacio de usuario. El sistema operativo ya te da TCP/IP para que implementes lo que quieras. Podría existir una biblioteca estándar de Bittorrent, pues bueno, pero no es el objetivo de un sistema operativo. Puede ser objetivo de un entorno de escritorio como KDE o GNOME.
7. Totalmente de acuerdo, pero el principio KISS choca frontalmente con querer incluir toda la funcionalidad dentro del núcleo (por no mencionar que es totalmente contrario al concepto de microkernel)
8. DBUS+bindings (por ejemplo Ruby, TCL, Python, será por lenguajes de Script). No es tarea del sistema operativo implementar lenguajes.
9. apt-build
10. Ya se hace a nivel de entorno de escritorio.
Dicho esto, parece que lo que quiere es una distribución unificada, con un sólo entorno de escritorio, una sóla biblioteca de cada tipo, un único programa de cada tipo, etc. Eso ya existe, así que poca mejora ofrece.
#11:
No sé; no me convence el artículo éste...
Primero, no es la comunidad de linux, sino la comunidad del Software Libre. De todos los aspectos que abarca, sólo uno es aplicable a Linux (núcleo). El resto de cosas, se aplican al resto e núcleos si no me equivoco: GNU/Hurd FreeBSD... etc. Si no os gusta que os discriminen los users de Windows por ser de Linux, ¿Porqué discrimináis al resto de núcleos, si usan casi las mismas aplicaciones?
Resumo, para quien no quiera leer la crítica entera: Parece que quien escribe el artículo venga de MacOS, y no conoce aún a fondo lo que está usando. Confunde constantemente cosas básicas como son las distintas capas del S.O. : núcleo, escritorio, drivers, librerías/API's... vamos, a mí me da la sensación de que no sabe de lo que está hablando.
Su opinión es muy respetable, pero sin estar suficientemente fundamentada.
Ahora sí, el resto de la crítica:
1.- "Dejar de utilizar X11." Será que el sistema de Windows es mejor, ¿no?. X11 es un sistema para poder representar aplicaciones en pantalla de forma unificada, y eso es lo que hace. ¿Que se ha hecho demasiado grande? puede ser. Pero la solución, desde luego, no es dejar de usarlo. La solución será, en caso de necesitarse, partir la aplicación en dos partes o más, para que se encarguen de cosas más sencillas. De todos modos, es la primera queja que leo al X11. ¿Alguno habéis probado NX-Server/NX-Client?
2.- "Pasar de un kernel monolítico a un sistema de microkernels." Sólo hace falta navegar un poco por las webs que tratan sobre Linux (kernel) para ver peticiones como ésta. En alguna web, incluso, hay algún FAQ respondiendo a ésto. Actualmente el kernel monolítico es mejor y más rápido que el microkernel. Hasta que alguien, como la gente de Hurd, demuestre que es viable un kernel de este tipo y mejor, lo más factible es seguir con el kernel monolítico, que aún le queda mucho potencial por explotar.
Además, la complicación añadida de programar para un microkernel muy complejo, podría provocar que los programadores no escriban drivers para él.
3.- "Relegar a una parte del sistema operativo la gestión de todos los dispositivos y ofrecer al usuario una visión unificada de los mismos." Entre el núcleo y el usuario hay más capas. Todas esas capas son las que componen el Sistema Operativo en sí. Obviamente, algunas aplicaciones/drivers estarán programados para funcionar en capas más superficiales y otras lo harán de forma más interna, o más coherente. Tiempo al tiempo. A mí no me gusta cómo se instalan los drivers oficiales de NVidia, podría ser algo más unificado y estándar. Pero todo llegará. No creo que este punto sea algo a mejorar, sino algo que está en constante mejora. La comunidad del SL no tiene la culpa de que X personas no integren o no programen de forma estandarizada. Y esas X personas, tal vez programan sin cobrar nada a cambio, tampoco es para exigirles.
4.- "Incluir un mecanismo para crear clústers de forma sencilla, y dar al usuario una imagen de que existe una sola máquina". No creo que esto sea relevante para la comunidad del SL. Tan sólo es un proyecto, como cualquier otro. Seguramente hay montones de proyectos sobre ésto en Internet. Todo está en colaborar activa o económicamente con ellos. Pero lo que está claro es que ningún cambio en este aspecto hará que la experiencia del usuario medio cambie lo más mínimo.
5.- "Utilizar un sistema interno común de representación de la información, y relegar a ciertos componentes incluidos en el sistema operativo las tareas de conversión entre formatos de intercambio". Muy bien. Pero sabemos si realmente se está usando ya algo o no? existe? hay previsiones?. Yo no estoy al tanto, pero parece que el autor del artículo tampoco. Lo mejor sería ponerse al corriente antes de decir nada. Cosas como " utilizar una estructura de datos tipo BMP sin compresión para intercambiar la información" me parecen un tanto ridículas. Lo más básico para comunicarse, es comunicar sin compresión, tal cual. Me niego a creer que actualmente no se pueden comunicar las aplicaciones de una forma TAN esencial.
6.- "De forma similar a lo anterior, utilizar un sistema interno para la gestión de protocolos de forma transparente.". KDE ya hace tiempo que lo está implementando. Pero yo no sé si el que escribió esto se refiere a nivel de escritorio, de núcleo, o de qué.
7.- "Intentar seguir una filosofía KISS (Keep It Simple, Stupid!) en todos los niveles del sistema operativo.". Eso ya se hace. KDE lo hace, muchas aplicaciones también lo siguen.
8.- "desarrollar un lenguaje de scripting para el sistema operativo y sus aplicaciones" qué tipo de lenguaje y para qué? es que no hay suficiente con Shell, python, ruby, etc ,etc?
9.- ". Quizá fuese mejor una solución mixta que incluyese los paquetes precompilados para su uso inmediato, y el código fuente para su compilación (en caso de que se quiera optimizar). " Pues, que yo sepa, la GPL obliga a que el código fuente esté disponible, así que, la mayoría de distribuciones, igual que se bajan el paquete, se pueden bajar el código fuente.
10.- "Utilizar un sistema centralizado para la gestión de contraseñas a modo “llavero” de una forma similar a la que lo implementa MacOS X". KDE, por ejemplo. Gnome tendrá algo también.
En fin... respeto su opinión, pero no la comparto. Debería enterarse mejor de cómo funciona GNU/Linux antes de opinar de cosas tan técnicas.
Primero, no es la comunidad de linux, sino la comunidad del Software Libre. De todos los aspectos que abarca, sólo uno es aplicable a Linux (núcleo). El resto de cosas, se aplican al resto e núcleos si no me equivoco: GNU/Hurd FreeBSD... etc. Si no os gusta que os discriminen los users de Windows por ser de Linux, ¿Porqué discrimináis al resto de núcleos, si usan casi las mismas aplicaciones?
Resumo, para quien no quiera leer la crítica entera: Parece que quien escribe el artículo venga de MacOS, y no conoce aún a fondo lo que está usando. Confunde constantemente cosas básicas como son las distintas capas del S.O. : núcleo, escritorio, drivers, librerías/API's... vamos, a mí me da la sensación de que no sabe de lo que está hablando.
Su opinión es muy respetable, pero sin estar suficientemente fundamentada.
Ahora sí, el resto de la crítica:
1.- "Dejar de utilizar X11." Será que el sistema de Windows es mejor, ¿no?. X11 es un sistema para poder representar aplicaciones en pantalla de forma unificada, y eso es lo que hace. ¿Que se ha hecho demasiado grande? puede ser. Pero la solución, desde luego, no es dejar de usarlo. La solución será, en caso de necesitarse, partir la aplicación en dos partes o más, para que se encarguen de cosas más sencillas. De todos modos, es la primera queja que leo al X11. ¿Alguno habéis probado NX-Server/NX-Client?
2.- "Pasar de un kernel monolítico a un sistema de microkernels." Sólo hace falta navegar un poco por las webs que tratan sobre Linux (kernel) para ver peticiones como ésta. En alguna web, incluso, hay algún FAQ respondiendo a ésto. Actualmente el kernel monolítico es mejor y más rápido que el microkernel. Hasta que alguien, como la gente de Hurd, demuestre que es viable un kernel de este tipo y mejor, lo más factible es seguir con el kernel monolítico, que aún le queda mucho potencial por explotar.
Además, la complicación añadida de programar para un microkernel muy complejo, podría provocar que los programadores no escriban drivers para él.
3.- "Relegar a una parte del sistema operativo la gestión de todos los dispositivos y ofrecer al usuario una visión unificada de los mismos." Entre el núcleo y el usuario hay más capas. Todas esas capas son las que componen el Sistema Operativo en sí. Obviamente, algunas aplicaciones/drivers estarán programados para funcionar en capas más superficiales y otras lo harán de forma más interna, o más coherente. Tiempo al tiempo. A mí no me gusta cómo se instalan los drivers oficiales de NVidia, podría ser algo más unificado y estándar. Pero todo llegará. No creo que este punto sea algo a mejorar, sino algo que está en constante mejora. La comunidad del SL no tiene la culpa de que X personas no integren o no programen de forma estandarizada. Y esas X personas, tal vez programan sin cobrar nada a cambio, tampoco es para exigirles.
4.- "Incluir un mecanismo para crear clústers de forma sencilla, y dar al usuario una imagen de que existe una sola máquina". No creo que esto sea relevante para la comunidad del SL. Tan sólo es un proyecto, como cualquier otro. Seguramente hay montones de proyectos sobre ésto en Internet. Todo está en colaborar activa o económicamente con ellos. Pero lo que está claro es que ningún cambio en este aspecto hará que la experiencia del usuario medio cambie lo más mínimo.
5.- "Utilizar un sistema interno común de representación de la información, y relegar a ciertos componentes incluidos en el sistema operativo las tareas de conversión entre formatos de intercambio". Muy bien. Pero sabemos si realmente se está usando ya algo o no? existe? hay previsiones?. Yo no estoy al tanto, pero parece que el autor del artículo tampoco. Lo mejor sería ponerse al corriente antes de decir nada. Cosas como " utilizar una estructura de datos tipo BMP sin compresión para intercambiar la información" me parecen un tanto ridículas. Lo más básico para comunicarse, es comunicar sin compresión, tal cual. Me niego a creer que actualmente no se pueden comunicar las aplicaciones de una forma TAN esencial.
6.- "De forma similar a lo anterior, utilizar un sistema interno para la gestión de protocolos de forma transparente.". KDE ya hace tiempo que lo está implementando. Pero yo no sé si el que escribió esto se refiere a nivel de escritorio, de núcleo, o de qué.
7.- "Intentar seguir una filosofía KISS (Keep It Simple, Stupid!) en todos los niveles del sistema operativo.". Eso ya se hace. KDE lo hace, muchas aplicaciones también lo siguen.
8.- "desarrollar un lenguaje de scripting para el sistema operativo y sus aplicaciones" qué tipo de lenguaje y para qué? es que no hay suficiente con Shell, python, ruby, etc ,etc?
9.- ". Quizá fuese mejor una solución mixta que incluyese los paquetes precompilados para su uso inmediato, y el código fuente para su compilación (en caso de que se quiera optimizar). " Pues, que yo sepa, la GPL obliga a que el código fuente esté disponible, así que, la mayoría de distribuciones, igual que se bajan el paquete, se pueden bajar el código fuente.
10.- "Utilizar un sistema centralizado para la gestión de contraseñas a modo “llavero” de una forma similar a la que lo implementa MacOS X". KDE, por ejemplo. Gnome tendrá algo también.
En fin... respeto su opinión, pero no la comparto. Debería enterarse mejor de cómo funciona GNU/Linux antes de opinar de cosas tan técnicas.
#21:
Creo que discrepo en la mayoría de los puntos:
1.- Dejar de utilizar X11
X11 funciona muy bien, es un sistema pequeño (mira si no tinyX o al servidor X que usan cosas como el nokia 770). Aqui el problema es que los fabricantes de hardware ni escribe drivers 3d de calidad ni ofrecen especificaciones.
2.- Pasar de un kernel monolítico a un sistema de microkernels
¿Qué más le da esto al usuario?. Que funcione y que funcione bien. Y para los programadores, que sea legible, y mantenible. Keep It Simple, Stupid.
http://www.educ.umu.se/~bjorn/mhonarc-files/obsolete/
3.- Relegar a una parte del sistema operativo la gestión de todos los dispositivos y ofrecer al usuario una visión unificada de los mismos.
HAL y GNOME. El usuario lo único que quiere es ver su memoria USB en pantalla, o acceder a las fotos de su cámara, o imprimir, o que le funcione la webcam directamente. Vamos por el buen camino, solo faltan algunos drivers y pulir un poco todo el sistema.
4.- Incluir un mecanismo para crear clústers de forma sencilla
¿Y esto es importante para el usuario final? ¿Cómo para estar en el TOP 10? Permiteme discrepar, pero dudo que más de un 0.005 de los usuarios de ordenadores se preocupen por esto.
5.- Utilizar un sistema interno común de representación de la información
Este es un punto vago y sólo habla de formatos gráficos. ¿Para qué diablos tiene que meterse el SO en estos temas? ¿No mencionabas el tema de modularidad y de microkernels? Pues esta funcionalidad está a nivel de aplicación, en una librería que te abstraiga el formato. Y ya las hay, GdkPixbuf o QtPixbuf.
6.- De forma similar a lo anterior, utilizar un sistema interno para la gestión de protocolos de forma transparente.
Ya hay varios a nivel de aplicación. KIOSlave, gnome-vfs, gvfs, etc... Pero no de transparencia vive el hombre. Lo que realmente hace falta son aplicaciones finales que hagan esta tarea sencilla. Si yo pincho un link de un torrent y un programa lo maneja, inicia la descarga del archivo y lo deja en mi escritorio yo soy feliz. Me da igual si el protocolo está implementado en una libraria o en el kernel o en la aplicacion. La experiencia nos ha demostrado que no se puede acceder a toda la informacion de la misma manera. Yo tengo casos de uso diferentes para leer un pdf, mirar la web de meneame o navegar por el sistema de ficheros.
7.- Intentar seguir una filosofía KISS
Creo que esta es la filosfía de UNIX desde que existe.
8.- Desarrollar un lenguaje de scripting para el sistema operativo y sus aplicaciones.
No se si esto es realmente util para el usuario final. El usuario no debería necesitar hacer scripting, las cosas deberían simplemente funcionar bien. Quizá para el usuario avanzado fuera interesante. Algo como la PowerShell de Microsoft combinado con un editor visual si haría las delicias de usuarios avanzados.
9.- Este punto no esta nada claro.
En cualquier caso que mi madre se tenga que compilar un paquete es una aberración. El único problema a solucionar es como manejar ese software que no viene incluido en tu distribución y quieres instalar. Tanto para los usuarios como para los ISVs. A mi personalmente me gusta la aproximación de autopackage.
10.- Utilizar un sistema centralizado para la gestión de contraseñas a modo “llavero”
gnome-keyring o KWaller?. Chico, qué linux estás usando tú?
1.- Dejar de utilizar X11
X11 funciona muy bien, es un sistema pequeño (mira si no tinyX o al servidor X que usan cosas como el nokia 770). Aqui el problema es que los fabricantes de hardware ni escribe drivers 3d de calidad ni ofrecen especificaciones.
2.- Pasar de un kernel monolítico a un sistema de microkernels
¿Qué más le da esto al usuario?. Que funcione y que funcione bien. Y para los programadores, que sea legible, y mantenible. Keep It Simple, Stupid.
http://www.educ.umu.se/~bjorn/mhonarc-files/obsolete/
3.- Relegar a una parte del sistema operativo la gestión de todos los dispositivos y ofrecer al usuario una visión unificada de los mismos.
HAL y GNOME. El usuario lo único que quiere es ver su memoria USB en pantalla, o acceder a las fotos de su cámara, o imprimir, o que le funcione la webcam directamente. Vamos por el buen camino, solo faltan algunos drivers y pulir un poco todo el sistema.
4.- Incluir un mecanismo para crear clústers de forma sencilla
¿Y esto es importante para el usuario final? ¿Cómo para estar en el TOP 10? Permiteme discrepar, pero dudo que más de un 0.005 de los usuarios de ordenadores se preocupen por esto.
5.- Utilizar un sistema interno común de representación de la información
Este es un punto vago y sólo habla de formatos gráficos. ¿Para qué diablos tiene que meterse el SO en estos temas? ¿No mencionabas el tema de modularidad y de microkernels? Pues esta funcionalidad está a nivel de aplicación, en una librería que te abstraiga el formato. Y ya las hay, GdkPixbuf o QtPixbuf.
6.- De forma similar a lo anterior, utilizar un sistema interno para la gestión de protocolos de forma transparente.
Ya hay varios a nivel de aplicación. KIOSlave, gnome-vfs, gvfs, etc... Pero no de transparencia vive el hombre. Lo que realmente hace falta son aplicaciones finales que hagan esta tarea sencilla. Si yo pincho un link de un torrent y un programa lo maneja, inicia la descarga del archivo y lo deja en mi escritorio yo soy feliz. Me da igual si el protocolo está implementado en una libraria o en el kernel o en la aplicacion. La experiencia nos ha demostrado que no se puede acceder a toda la informacion de la misma manera. Yo tengo casos de uso diferentes para leer un pdf, mirar la web de meneame o navegar por el sistema de ficheros.
7.- Intentar seguir una filosofía KISS
Creo que esta es la filosfía de UNIX desde que existe.
8.- Desarrollar un lenguaje de scripting para el sistema operativo y sus aplicaciones.
No se si esto es realmente util para el usuario final. El usuario no debería necesitar hacer scripting, las cosas deberían simplemente funcionar bien. Quizá para el usuario avanzado fuera interesante. Algo como la PowerShell de Microsoft combinado con un editor visual si haría las delicias de usuarios avanzados.
9.- Este punto no esta nada claro.
En cualquier caso que mi madre se tenga que compilar un paquete es una aberración. El único problema a solucionar es como manejar ese software que no viene incluido en tu distribución y quieres instalar. Tanto para los usuarios como para los ISVs. A mi personalmente me gusta la aproximación de autopackage.
10.- Utilizar un sistema centralizado para la gestión de contraseñas a modo “llavero”
gnome-keyring o KWaller?. Chico, qué linux estás usando tú?
#48:
#45 Yo no te he votado negativo pero si quieres te lo explico.
Yo mi impresora hp multifunción, la instalé enchufandola y dándole a agregar impresora.
El plugin del flash para el firefox en kubuntu se instala desde el administrador de paquetes sin tener que escribir ningún comando.
La estructura actual de directorios es mucho mejor y más óptima que C: y no tienes que ser informático para entenderla, tu cuando te logueas estas en tu directorio personal y ahí es donde puedes hacer lo que te dé la gana.
Y respecto al artículo es un artículo técnico y además con muchas lagunas, es como si me dices que a usuario que ve una conversación entre dos técnicos de Microsoft ya se le quitan las ganas de usarlo porque es muy difícil, ya me dirás que tiene que ver una cosa con la otra.
¿Me he dejado algo?
Yo mi impresora hp multifunción, la instalé enchufandola y dándole a agregar impresora.
El plugin del flash para el firefox en kubuntu se instala desde el administrador de paquetes sin tener que escribir ningún comando.
La estructura actual de directorios es mucho mejor y más óptima que C: y no tienes que ser informático para entenderla, tu cuando te logueas estas en tu directorio personal y ahí es donde puedes hacer lo que te dé la gana.
Y respecto al artículo es un artículo técnico y además con muchas lagunas, es como si me dices que a usuario que ve una conversación entre dos técnicos de Microsoft ya se le quitan las ganas de usarlo porque es muy difícil, ya me dirás que tiene que ver una cosa con la otra.
¿Me he dejado algo?
#39:
#34 , que tenga o no consola, que antes de arrancar aparezca modo texto o no, no tiene nada que ver con que un SO sea para Servidor, o sea para Desktop.
¿Debian Etch GNU/Linux es un SO de Desktop o Server?
Como dice #38, no existe tal ventana, ni proceso Shell/Bash, ni nada parecido. Cuando se lanza una aplicación, se lanza y ya está. No hay más historias.
¿Debian Etch GNU/Linux es un SO de Desktop o Server?
Como dice #38, no existe tal ventana, ni proceso Shell/Bash, ni nada parecido. Cuando se lanza una aplicación, se lanza y ya está. No hay más historias.
Comentarios
1. Totalmente de acuerdo
2. Están por demostrar las ventajas de los microkernels (funcionalidad vs. rendimiento). El núcleo de Linux es monolítico PERO modular. Quizá una modularización más fina y un ABI estable pudiesen ayudar.
3. udev+hal+dbus son un estándar hoy en día. Lo que quieras implementar por encima ya es cosa del usuario.
4. Tarde o temprano los parches que se demuestran estables y que no interfieren con el funcionamiento normal del núcleo, pasan al núcleo.
5. Un Sistema Operativo no debe saber de "formatos". Es absurdo que el sistema operativo sepa qué es un mp3, un jpg y demás, de eso se encargan las bibliotecas de usuario (otra cosa es estandarizar esas bibliotecas). El sistema operativo ya da mecanismos de comunicación estándares (colas de mensajes, memoria compartida, etc...)
6. Una vez más, eso es cosa del espacio de usuario. El sistema operativo ya te da TCP/IP para que implementes lo que quieras. Podría existir una biblioteca estándar de Bittorrent, pues bueno, pero no es el objetivo de un sistema operativo. Puede ser objetivo de un entorno de escritorio como KDE o GNOME.
7. Totalmente de acuerdo, pero el principio KISS choca frontalmente con querer incluir toda la funcionalidad dentro del núcleo (por no mencionar que es totalmente contrario al concepto de microkernel)
8. DBUS+bindings (por ejemplo Ruby, TCL, Python, será por lenguajes de Script). No es tarea del sistema operativo implementar lenguajes.
9. apt-build
10. Ya se hace a nivel de entorno de escritorio.
Dicho esto, parece que lo que quiere es una distribución unificada, con un sólo entorno de escritorio, una sóla biblioteca de cada tipo, un único programa de cada tipo, etc. Eso ya existe, así que poca mejora ofrece.
No sé; no me convence el artículo éste...
Primero, no es la comunidad de linux, sino la comunidad del Software Libre. De todos los aspectos que abarca, sólo uno es aplicable a Linux (núcleo). El resto de cosas, se aplican al resto e núcleos si no me equivoco: GNU/Hurd FreeBSD... etc. Si no os gusta que os discriminen los users de Windows por ser de Linux, ¿Porqué discrimináis al resto de núcleos, si usan casi las mismas aplicaciones?
Resumo, para quien no quiera leer la crítica entera: Parece que quien escribe el artículo venga de MacOS, y no conoce aún a fondo lo que está usando. Confunde constantemente cosas básicas como son las distintas capas del S.O. : núcleo, escritorio, drivers, librerías/API's... vamos, a mí me da la sensación de que no sabe de lo que está hablando.
Su opinión es muy respetable, pero sin estar suficientemente fundamentada.
Ahora sí, el resto de la crítica:
1.- "Dejar de utilizar X11." Será que el sistema de Windows es mejor, ¿no?. X11 es un sistema para poder representar aplicaciones en pantalla de forma unificada, y eso es lo que hace. ¿Que se ha hecho demasiado grande? puede ser. Pero la solución, desde luego, no es dejar de usarlo. La solución será, en caso de necesitarse, partir la aplicación en dos partes o más, para que se encarguen de cosas más sencillas. De todos modos, es la primera queja que leo al X11. ¿Alguno habéis probado NX-Server/NX-Client?
2.- "Pasar de un kernel monolítico a un sistema de microkernels." Sólo hace falta navegar un poco por las webs que tratan sobre Linux (kernel) para ver peticiones como ésta. En alguna web, incluso, hay algún FAQ respondiendo a ésto. Actualmente el kernel monolítico es mejor y más rápido que el microkernel. Hasta que alguien, como la gente de Hurd, demuestre que es viable un kernel de este tipo y mejor, lo más factible es seguir con el kernel monolítico, que aún le queda mucho potencial por explotar.
Además, la complicación añadida de programar para un microkernel muy complejo, podría provocar que los programadores no escriban drivers para él.
3.- "Relegar a una parte del sistema operativo la gestión de todos los dispositivos y ofrecer al usuario una visión unificada de los mismos." Entre el núcleo y el usuario hay más capas. Todas esas capas son las que componen el Sistema Operativo en sí. Obviamente, algunas aplicaciones/drivers estarán programados para funcionar en capas más superficiales y otras lo harán de forma más interna, o más coherente. Tiempo al tiempo. A mí no me gusta cómo se instalan los drivers oficiales de NVidia, podría ser algo más unificado y estándar. Pero todo llegará. No creo que este punto sea algo a mejorar, sino algo que está en constante mejora. La comunidad del SL no tiene la culpa de que X personas no integren o no programen de forma estandarizada. Y esas X personas, tal vez programan sin cobrar nada a cambio, tampoco es para exigirles.
4.- "Incluir un mecanismo para crear clústers de forma sencilla, y dar al usuario una imagen de que existe una sola máquina". No creo que esto sea relevante para la comunidad del SL. Tan sólo es un proyecto, como cualquier otro. Seguramente hay montones de proyectos sobre ésto en Internet. Todo está en colaborar activa o económicamente con ellos. Pero lo que está claro es que ningún cambio en este aspecto hará que la experiencia del usuario medio cambie lo más mínimo.
5.- "Utilizar un sistema interno común de representación de la información, y relegar a ciertos componentes incluidos en el sistema operativo las tareas de conversión entre formatos de intercambio". Muy bien. Pero sabemos si realmente se está usando ya algo o no? existe? hay previsiones?. Yo no estoy al tanto, pero parece que el autor del artículo tampoco. Lo mejor sería ponerse al corriente antes de decir nada. Cosas como " utilizar una estructura de datos tipo BMP sin compresión para intercambiar la información" me parecen un tanto ridículas. Lo más básico para comunicarse, es comunicar sin compresión, tal cual. Me niego a creer que actualmente no se pueden comunicar las aplicaciones de una forma TAN esencial.
6.- "De forma similar a lo anterior, utilizar un sistema interno para la gestión de protocolos de forma transparente.". KDE ya hace tiempo que lo está implementando. Pero yo no sé si el que escribió esto se refiere a nivel de escritorio, de núcleo, o de qué.
7.- "Intentar seguir una filosofía KISS (Keep It Simple, Stupid!) en todos los niveles del sistema operativo.". Eso ya se hace. KDE lo hace, muchas aplicaciones también lo siguen.
8.- "desarrollar un lenguaje de scripting para el sistema operativo y sus aplicaciones" qué tipo de lenguaje y para qué? es que no hay suficiente con Shell, python, ruby, etc ,etc?
9.- ". Quizá fuese mejor una solución mixta que incluyese los paquetes precompilados para su uso inmediato, y el código fuente para su compilación (en caso de que se quiera optimizar). " Pues, que yo sepa, la GPL obliga a que el código fuente esté disponible, así que, la mayoría de distribuciones, igual que se bajan el paquete, se pueden bajar el código fuente.
10.- "Utilizar un sistema centralizado para la gestión de contraseñas a modo “llavero” de una forma similar a la que lo implementa MacOS X". KDE, por ejemplo. Gnome tendrá algo también.
En fin... respeto su opinión, pero no la comparto. Debería enterarse mejor de cómo funciona GNU/Linux antes de opinar de cosas tan técnicas.
#18, Es lo de los hobbits, un elfo, un enano, un montaráz, un mago y un anillo de oro.
Creo que discrepo en la mayoría de los puntos:
1.- Dejar de utilizar X11
X11 funciona muy bien, es un sistema pequeño (mira si no tinyX o al servidor X que usan cosas como el nokia 770). Aqui el problema es que los fabricantes de hardware ni escribe drivers 3d de calidad ni ofrecen especificaciones.
2.- Pasar de un kernel monolítico a un sistema de microkernels
¿Qué más le da esto al usuario?. Que funcione y que funcione bien. Y para los programadores, que sea legible, y mantenible. Keep It Simple, Stupid.
http://www.educ.umu.se/~bjorn/mhonarc-files/obsolete/
3.- Relegar a una parte del sistema operativo la gestión de todos los dispositivos y ofrecer al usuario una visión unificada de los mismos.
HAL y GNOME. El usuario lo único que quiere es ver su memoria USB en pantalla, o acceder a las fotos de su cámara, o imprimir, o que le funcione la webcam directamente. Vamos por el buen camino, solo faltan algunos drivers y pulir un poco todo el sistema.
4.- Incluir un mecanismo para crear clústers de forma sencilla
¿Y esto es importante para el usuario final? ¿Cómo para estar en el TOP 10? Permiteme discrepar, pero dudo que más de un 0.005 de los usuarios de ordenadores se preocupen por esto.
5.- Utilizar un sistema interno común de representación de la información
Este es un punto vago y sólo habla de formatos gráficos. ¿Para qué diablos tiene que meterse el SO en estos temas? ¿No mencionabas el tema de modularidad y de microkernels? Pues esta funcionalidad está a nivel de aplicación, en una librería que te abstraiga el formato. Y ya las hay, GdkPixbuf o QtPixbuf.
6.- De forma similar a lo anterior, utilizar un sistema interno para la gestión de protocolos de forma transparente.
Ya hay varios a nivel de aplicación. KIOSlave, gnome-vfs, gvfs, etc... Pero no de transparencia vive el hombre. Lo que realmente hace falta son aplicaciones finales que hagan esta tarea sencilla. Si yo pincho un link de un torrent y un programa lo maneja, inicia la descarga del archivo y lo deja en mi escritorio yo soy feliz. Me da igual si el protocolo está implementado en una libraria o en el kernel o en la aplicacion. La experiencia nos ha demostrado que no se puede acceder a toda la informacion de la misma manera. Yo tengo casos de uso diferentes para leer un pdf, mirar la web de meneame o navegar por el sistema de ficheros.
7.- Intentar seguir una filosofía KISS
Creo que esta es la filosfía de UNIX desde que existe.
8.- Desarrollar un lenguaje de scripting para el sistema operativo y sus aplicaciones.
No se si esto es realmente util para el usuario final. El usuario no debería necesitar hacer scripting, las cosas deberían simplemente funcionar bien. Quizá para el usuario avanzado fuera interesante. Algo como la PowerShell de Microsoft combinado con un editor visual si haría las delicias de usuarios avanzados.
9.- Este punto no esta nada claro.
En cualquier caso que mi madre se tenga que compilar un paquete es una aberración. El único problema a solucionar es como manejar ese software que no viene incluido en tu distribución y quieres instalar. Tanto para los usuarios como para los ISVs. A mi personalmente me gusta la aproximación de autopackage.
10.- Utilizar un sistema centralizado para la gestión de contraseñas a modo “llavero”
gnome-keyring o KWaller?. Chico, qué linux estás usando tú?
Creo que lo que necesita la comunidad de Linux para mejorar es multiplicarse por 1.000.000. Para ello tenemos que conseguir que los usuarios utilicen cualquier distribución de Linux en vez de Windows.
No es por atacar al creador del artículo, pero si Vista ha vendido 40 millones de copias en 100 días...no creo que podamos contrarrestarlo mediante propuestas como "pasar de un kernel monolítico a un sistema de microkernels" o "incluir un mecanismo para crear clústers de forma sencilla".
#45 Yo no te he votado negativo pero si quieres te lo explico.
Yo mi impresora hp multifunción, la instalé enchufandola y dándole a agregar impresora.
El plugin del flash para el firefox en kubuntu se instala desde el administrador de paquetes sin tener que escribir ningún comando.
La estructura actual de directorios es mucho mejor y más óptima que C: y no tienes que ser informático para entenderla, tu cuando te logueas estas en tu directorio personal y ahí es donde puedes hacer lo que te dé la gana.
Y respecto al artículo es un artículo técnico y además con muchas lagunas, es como si me dices que a usuario que ve una conversación entre dos técnicos de Microsoft ya se le quitan las ganas de usarlo porque es muy difícil, ya me dirás que tiene que ver una cosa con la otra.
¿Me he dejado algo?
Muy interesante.
Con la discusión critica y el diálogo mejoraremos cada vez más el Software Libre.
Ahora por favor y distribuid el artículo.
#34 , que tenga o no consola, que antes de arrancar aparezca modo texto o no, no tiene nada que ver con que un SO sea para Servidor, o sea para Desktop.
¿Debian Etch GNU/Linux es un SO de Desktop o Server?
Como dice #38, no existe tal ventana, ni proceso Shell/Bash, ni nada parecido. Cuando se lanza una aplicación, se lanza y ya está. No hay más historias.
#12
No es mi intención empezar una discusión sobre si deberíamos llamar GNU/Linux al S.O. o no; aunque yo crea que sí deberíamos, lo que destaco, no es que el autor del artículo no lo haga, sino que confunda contínuamente de qué es lo que está hablando. Habla de Linux, como si fuese el responsable de lo que haga la gente de KDE, Gnome, etc.
De hecho, me pregunto si sabe que existen escritorios separados, y que éstos no los "crean" las distros, o Linux. Hay muchas lagunas escondidas en el artículo, en serio.
Me pregunto también, si lo que ha hecho es algún tipo de "recolección" de otras quejas de por ahí, y las ha puesto como suyas o algo. Porque no me cuadran la mitad de las cosas.
Y bueno, del resto, como del X11, ya comento más adelante cuando pase por casa.
#34 Conozco a Linux desde hace poco, pero lo cierto es que cualquier operación esconde una ventana terminal detrás. Y, además, hay cosas que no se pueden hacer desde gráfico.
Lo siento, pero no estoy de acuerdo contio en ese punto, todas las cosas que necesite hacer un usuario de Desktop, como dices tu de los de jugar al buscaminas, chatear etc... puede hacerlas sin abrir la consola y sin teclear ningun comando. Hoy en día hay GUIs para todo.
#4, originalmente X estaba diseñado para proporcionar un sistema gráfico en redes... no está optimizado para escritorio, está pensado para que un terminal gráfico tonto se conecte a un servidor Unix y ejecute allí sus programas.
También habría que ver qué entiende el autor por "X"... X es sólo un protocolo de comunicaciones, nada más... creo que el autor se refiere al X + gestor de ventanas + escritorio, que son 3 aplicaciones distintas.
Una alternativa sería hacer lo que hace hasefroch, meter el sistema gráfico en el núcleo... sería más rápido pero mucho más inestable (como hasefroch). Creo que es mejor dejarlo como está, queda mucho más modular y permite a los usuarios tener distintas combinaciones de gestor de ventanas y escritorio. Además X es comodísimo para acceder a servidores remotos, es una de las cosas que se echa de menos en el Mac (se puede instalar aparte, pero no se integra bien con el sistema).
Coincido con deavid.
Para mí el principal problema del artículo son las claras lagunas que muestra en muchos puntos lo que acaba invalidando el total de la argumentación y el principal ejemplo está en el punto 3. Cómo bien dicen la gestión de dispositivos se lleva a cabo por udev + hal + dbus esto se empezó a implantar si no recuerdo mal hace por lo menos 2 años o sea que no es de ahora. Son las aplicaciones gráficas las que interactuan con dbus para realizar una serie de acciones y no al revés.
Otro punto importante que no está claro es el de las X, la mayoría de los artículos que puedas enlazar estan anticuados, nada tiene que ver xfree86 con el camino que está tomando xorg. Las X para nada son un monstruo y para nada han dejado de evolucionar y como repito la prueba es xorg. ¿Que es mejorable? Sí, por supuesto, en ello está mucha gente pero de ahí a descartar las X me parece una tontería y sobre todo ¿descartar por qué? por unas X integradas en kernel, ¿donde un cuelgue de una aplicación cuelgue el sistema operativo como ocurre en Windows? En fin que de los problemas de las X ya se habló mucho tiempo sobre todo cuando se empezó a hablar de un fork y las X hoy en día con gestores de ventanas como compiz han demostrado que funcionan muy bien. Freedesktop está uniendo los desarrollos de las X y los escritoros de modo que los problemas de redibujado y demás se están solucionando y todos estan trabajando en la misma dirección.
En cuanto al punto 9, ya existen distribuciones con soluciones mixtas como arch que integran una herramienta tipo apt con otra tipo emerge. Pero es que Linux o GNU/Linux no es una distribución, no es un escritorio, no es una opción son muchas, si alguien quiere paquetes compilados puede optar por Ubuntu o Debian o cualquier otra, si quieres compilar pues tienes Gentoo, si quieres un sistema mixto pues Arch, ...
En fin que seguiría pero sería repetir mucho de lo que ya se ha dicho.
"Por ejemplo, el propio sistema operativo implementaría el protocolo FTP/BitTorrent/etc."
¿El autor sabe lo que es un sistema operativo? ¿Sabe la diferencia con programas de usuario ?
"Pasar de un kernel monolítico a un sistema de microkernels."
Si fuera tan sencillo hace tiempo que todos tendríamos instalado Hurd, pero debe ser más dificil implementarlo que teorizarlo...
"Utilizar un sistema centralizado para la gestión de contraseñas a modo “llavero” de una forma similar a la que lo implementa MacOS X para facilitar la organización de la ingente cantidad de contraseñas y permisos que se necesitan para trabajar en red"
Lo mismo que antes, que eso no es tarea del sistema operativo!!
los 3 últimos puntos yo diría que están ya conseguidos.
Gnome tiene un gestor de contraseñas, existe el apt-build para compilar paquetes desde el source y se puede manejar el sistema facilmente con scripts en bash usando zenity.
#42 xorg ya es un fork de xfree86 y lo primero que implementaron fue la modularidad.
Se puede criticar pero dando razones objetivas, ¿que es lo que te parece mal de xorg? ¿Por qué? Por ahí se empieza.
Y edito:
Decir que es malo y lo sabe todo el mundo o que es X11 quien monta los usb no son razones objetivas.
#34 ya se nota que llevas poco tiempo
Solo quería comentar que dar votos positivos a los que dicen que X11 es genial y es LO MEJOR, no es más que engañarnos a nosotros mismos, toda la comunidad sabe que X11 es un lastre para la plataforma GNU/Linux, pero también es cierto que hoy por hoy no hay ninguna alternativa y es complicado sustituirlo, hay tantas cosas que dependen de X11, supongo que con el tiempo o se hara un fork para aligerarlo y acelerarlo o saldrá algo nuevo.
Me parece un articulo interesante.
Sobre el punto 9, las distribuciones que usan debs y rpms (no se si todas, pero al menos las que yo cononzco) ofrecen la alternativa de los paquetes con codigo fuente también, en vez de precompilados.
Sobre el punto 10, existen programas para el tratamiento centralizado de contraseñas para KDE y Gnome (aunque no se si realmente funcionan como en OSX, porque no los uso)
La comunidad entera todavía es muy joven por lo que el desarrollo no debe parar y no lo hará. Entonces en el futuro creo que GNU/Linux tenderá a converger.
Es interesante. El punto 1 para mí es el más importante de todos.
Hay cosas con las que no estoy de acuerdo.
Habla de microkernels para modularizar el trabajo y, a su vez, pide que todos los protocolos de red (ftp, http, bittorrent, ...) se agrupen en un mismo proceso.
En cuanto a la solución que propone para el sistema de empaquetado, ya existe (más o menos): apt-build. Por desgracia, no está del todo madura y nunca ha tenido demasiada aceptación.
#34, chaval no tienes ni idea. De donde te sacas que en Linux cualquier proceso tiene una ventana de comandos por detras?
#21 X11 es monstruoso. Con la iniciativa de los responsables de Xorg se intentó modular, pero aun así, debido a que su implementación ha ido evolucionando de especificaciones "antiguas" y extendiendo su diseño como mejor se pudo, es probable que haya que enfrentarse a un temible fork que rompa la compatibilidad, y eso es algo que algún día llegará. Por ejemplo... yo creo que se debería adoptar la geometría vectorial de punto flotante como estandar de dibujado de una vez por todas para minimizar (si no eliminar finalmente) los problemas de la resolución de pantalla eternamente cambiante.
Metiendo varios puntos en un saco: Si hay algo bien sabido es que en Linux hay una enorme diversidad tecnológica.
Partiendo de un presunto sistema microkernel bien diseñado, donde las interfaces de los servicios se espera que no cambien de la noche a la mañana, la construcción de drivers sería mucho mas mantenible, ya que si hay algo que sabemos que los fabricantes odian, es tener que adaptar sus drivers continuamente debido a cambios en las interfaces de los drivers por parte del sistema operativo o "floraciones" tecnológicas que en un principio se aceptan y al cabo de poco tiempo se desechan. He ahí el por qué de los drivers unificados con su pequeña capa adaptativa que programan algunos fabricantes de hardware.
Por eso el punto 2 del artículo afirma que un sistema microkernel es algo ideal y necesario (o al menos eso supongo).
Con la misma o similar filosofía, los puntos 3,4,5,6,7,10, a mi entender, sugieren la idea de orientar lo que en muchos casos son "conjuntos de rutinas" como servicios modulares. Me explico:
- A mí, como programador, me sería mucho más comodo y haría mi software mucho mas facil de mantener el hecho de que, por ejemplo: en vez de tener que enlazar mi programa con una biblioteca dinámica para manipular el contenido de una imagen obteniendo una representación interna dependiente de dicha biblioteca, pudiese solicitar a una interfaz de soporte de imágenes del sistema la apertura de dicha imagen obteniendo una representación genérica de dicha imagen. Debido a esa modularidad podría incluso añadir, eliminar o substituir implementaciones de soporte de formatos gráficos o cualquier otra cosa.
Entiendo que es algo tremendamente complejo el hecho, sobre todo de catalogar y disponer de tal conjunto de interfaces completamente definidas (y a las que se adapten posteriormente tanto los programadores de aplicaciones como los programadores proveedores de servicios de aplicación). Algo parecido a la orientación que MacOS X da a sus FrameWorks.
Era solo un ejemplo para ilustrar lo que creo que pretende expresar el autor. Y me parece muy acertado, la verdad.
Después de leer el artículo, creo que lo que intentan es Windowsizarlo. Linux me gusta tal y como es, porque no pretende ser lo que no es.
Muy interesante.. pero no termino de entender el punto 1.
Si X no está diseñado para multimedia.. ¿qué entorno lo está? ¿La consola?
Respondiendo a deavid y algunos otros...
Hablar de "10 cosas que la comunidad Linux podría (y debería) mejorar", es eso... cosas que se pueden mejorar... nadie habla de pasarse a Windows Vista... Se trata tan solo de una crítica constructiva y no se tiran piedras a ningún tejado...
Cuando se habla de "la comunidad Linux" y no de "la comunidad de Software Libre" entiendo que se hace porque esta última no hace desarrollos exclusivamente para Linux y todos los puntos del artículo hacen mención solamente a este Sistema Operativo...
Y hablar de Linux tampoco es hablar únicamente del kernel del sistema operativo...
Con respecto al éste, tampoco creo que la crítica que se hace del núcleo monolítico sea "discriminar" (como sugieren algunos)... tan solo se trata de un tema abierto al debate y que muchos grupos de investigación y desarrollo se han planteando alguna vez, como bien se ve en GNU/Hurd...
Si se considera que hablar de Linux es, además de su kernel, hablar de todo el conjunto de librerías que lo acompañan, sus distintos niveles de aplicación y usuario, sus aplicaciones, etc... no veo tampoco dónde está el error que comete el autor...
Personalmente me parece una idea genial que se unifiquen y creen librerías estándar para hacer las cosas y evitar que todos los desarrolladores tengan que reinventar la rueda de vez en cuando... ¿que ésta no es la función de un sistema operativo? de acuerdo, pero sí de una comunidad de software que lo mantiene y hace desarrollos para el mismo...
En cuanto al tema de la distribución de paquetes de código fuente: ya desde el principio de los tiempos de Linux, éste se ha caracterizado por distribuir su código fuente, aunque en los últimos años, y dado su volumen, éste se fue relegado a CDs secundarios (no imprescindibles) y últimamente ya ni siquiera eso... aunque todos ellos se pueden descargar desde los repositorios de las distintas distros o bien desde los repositorios cvs/svn del proyecto.
Pero esa no es la discusión... Es sencillo ver la dicotomía que existe entre las distintas distribuciones de Linux... unas prefieren dar una solución rápida distribuyendo binarios genéricos compilados y otros prefieres montar un sistema de compilación de los paquetes para la arquitectura en cuestión... La solución propuesta en el artículo es una solución mixta, que bien organizada puede ayudar a mejorar el rendimiento del sistema operativo.
En cuanto al tema de la filosofía KISS... pues bueno... hay distribuciones y distribuciones, pero creo que el autor se refiere más a llevar este principio a un nivel mucho más bajo... al nivel de desarrollo e integración de los componentes... algo así como lo que propone con las librerías de formatos...
Y para finalizar, el punto principal: X11...
antes de nada os aconsejo que leáis:
- http://linuxfinances.info/info/xpersonal.html
- http://cbbrowne.com/info/xbloat.html
- http://en.wikipedia.org/wiki/X_Window_System (INCLUSO la Wikipedia!!!)
Y muchos otros post que hablan del mismo tema... X11 se ha vuelto un dinosaurio que ya no puede evolucionar...
El punto 1 no lo entiendo, para mi el sistema servidor-cliente de XWindow es el mejor, y el que da mayor flexibilidad.
Ahora si crean un modelo servidor-cliente más óptimo en según que tareas ok.
Pues que queréis que os diga, las mejoras del software no siempre tienen que ir por la linea del perfeccionamiento funcional tanto como la de la comodidad, facilidad, motivación e interés/curiosidad que pueda provocar en la gente común. Y siento decirlo pero al parecer la gente común (generalizando) no parece motivarles el cómo de efectivo es el soft que usan, el ejemplo ya lo tenéis MS.
Yo no creo que esté bien el artículo si lo que realmente propone es extender la filosifía Open Source, no linux ( no se trata de un movimiento totalitario MS VS LINUX).
No me parece tan relevante el texto. No es pragmático cambiar las cosas. Este tipo de comentarios usualmente vienen de personas sin mucha experiencia con sistemas operativos. El criterio más importante es que funcione. Y funciona.
Siempre comparando con Mac Os X...
No tiene sentido decir que Linux debería ser un microkernel, en el mismo momento en que lo hiciera dejaría de ser Linux, y nos encontraríamos ante un kernel (más herramientas GNU) totalmente distinto que configuraría un S.O que no reconocería ni la madre que lo parió. Si ya BSD es bastante diferente a Linux, si Hurd se terminase probablemente fliparíamos
.
Es el eterno dilema, cambiar lo que tenemos por algo que supuestamente es mejor pero que implica desechar todo lo que ya hay o quedarnos dónde estamos.
Linux no será nunca microkernel. Eso es una tontería. Es como querer convertir MS-DOS en un sistema operativo para mainframes, simplemente sería rehacer el sistema operativo de nuevo.
Esto es humo. Los argumentos ya han sido expuestos por docenas en los anteriores comentarios.
A ver qué dia de estos me hago un artículo similar (criticando algo de lo que no tengo mucha idea y contradiciéndome inconscientemente) para pasar como alguien conocedor y crítico.
Y claro, al final digo: "no estoy en contra, ni tirando pedradas".
¿Ah pero es que linux necesita mejorar?,¿aun más? para mi ya es perfecto.
estoo voy a hacer un apt-get upgrade......
Creo que a lo que se refiere el autor en el punto 9, es que en vez de existir paquetes con binarios o fuentes para compilar, existan paquetes con fuentes que se autocompilen en la máquina del usuario. O sea que no los tenga que compilar el usuario a mano, si no que se haga automáticamente al instalar el paquete.
Alguno veo que lo tiene claro (apt-build), pero la mayoría me parece que no lo entendió.
Sinceramente, estoy muy en desacuerdo con el punto 8. Si algo ha caracterizado al mundo Unix en general, desde sus comienzos, es la potencia de los scripts, que permiten hacer de todo, casi como si programases sobre el sistema operativo. Otra cosa es que se quiera ampliar los shells, pero eso es natural.
Sobre que X11 no está pensado para multimedia... ¿cualquier otro sistema gráfico lo estuvo ya desde sus comienzos? Todo debe ir adaptándose, corrigiéndose y ampliándose. X11 no es una excepción; pero de ahí a decir que hay que tirarlo y usar otra cosa... yo, personalmente, nunca he sido muy de "borrón y cuenta nueva". Es mejor ir evolucionando gradualmente.
La persona que redactó el texto, cuando habla del lenguaje de Scripting, se refiere a Applescript. Realmente no hay nada parecido (en cuando la facilidad de la sintaxis) en Linux (por lo menos que yo conozca, puede que me equivoque), es una herramienta bastante intuitiva, potente y que permite hacer desde las cosas mas sencillas hasta scripts bastante complejos. Su utilidad tiene, para que nos vamos a engañar, pero de ahí a ser una de las 10 cosas más prioritarias que hay que mejorar en Linux... pues no estoy de acuerdo (eh mi humilde opinión). Yo uso OSX y Linux, y cuando estoy en Linux no lo echo de menos en absoluto. Para los que no lo conozcan tell application "Microsoft Word" to quit sería un ejemplo de script. http://en.wikipedia.org/wiki/AppleScript para más información.
#26: ¿Estás seguro que usaste Kubuntu?. Simplemente con navegar una página con flash en Konqueror se muestra un "wizard" para bajar el plugin de flash.
Está visto que el tio este mucha idea no tiene.
Bien, para todos los que han dicho que no sé lo que hablo, voy a decir unas cosas. Si yo necesito salir del entorno gráfico para reconfigurar las opciones de teclado, tarjeta gráfica, ratón y demás, es que Linux no es gráfico. Si lo fuera, TODO estaría disponible en gráfico.
Si yo puedo elegir no arrancar en modo gráfico, es que Linux no es gráfico. Si yo puedo salirme del entorno gráfico, es que Linux no es gráfico. Si las X se arrancan con un comando, es que Linux no es gráfico.
Por lo tanto, si Linux no es gráfico, es que estamos usando un entorno operativo sobre una base texto. Si la base texto es la que manda, por muchos GUIs que creemos, tendremos que pedirle permiso al Sr. Texto. Puedes llamarlo como quiera, pero hace algún tiempo se le llamó Windows 3.1 y luego se le llamó Windows 95. Ahora, yo lo llamo Linux.
Soy usuario de texto, informático y programador. Procedo de MS-DOS 6.22. Me gustan las cosas lo más difíciles posibles, pero eso no significa que yo vea Linux bien para un usuario novato. Linux no es para un usuario novato porque para cualquier cosa tienes que arrancar el terminal.
El #37 me hizo mucha gracia cuando dijo aquello de "Hoy en día hay GUIs para todo". Caéis en vuestra propia trampa. Un sistema operativo que necesite instalar un GUI para hacer algo es porque nativamente esa opción está en texto y este GUI actúa de máscara o interfaz bonita, atractiva y fácil.
#46 No te parece irrelevante el texto. Muy bien, a mí, personalmente me da igual que haya o no haya texto porque tarde o temprando terminaré por conocerme el entorno texto como la palma de mi mano, pero si relees en mi comentario inicial, dije: "Si hablamos de usuario normal (el que viene de Windows y quiere jugar al buscaminas". Si sigues pensando que a estas personas les dará igual el texto, ve a casa de un amigo novato y ábrele una terminal de Windows, a ver qué cara pone. Y dile que esto lo tendrá que usar a menudo en Linux para instalar algunas cosas.
#52 Muy bien, has encontrado un símil en Windows. ¿Qué quieres demostrar con eso? Yo lo veo igual que en Linux. No se puede usar un Server como Desktop. Si tú lo usas, ya sabes lo que opino. Yo no lo uso.
Y en cuanto a los votos negativos, ya he opinado sobre ellos en otras ocasiones. Me dan igual. Yo opino y digo lo que pienso. Si no le gusta a alguien, pues que vote negativo si eso le hace feliz.
Otra cosa es que decís que se nota que llevo poco en linux. Cuando digo que llevo poco tiempo en linux, quiero decir que no he pasado más de un mes con él instalado. He tocado muchas distribuciones, pero ninguna me ha convencido. Eso no significa que no sepa nada de Linux, sino que no he estado tanto tiempo con él como vosotros.
Lo que os ocurre a los linuxeros extremistas es que no podéis asumir que Linux esté cometiendo el mismo error que Windows en su época.
Me gusta el objetivo de la comunidad GNU/Linux, pero no comparto su forma de ver/hacer las cosas en general. En cambio, Ubuntu sí me gusta porque lo intenta hacer todo sencillo, rápido y sin complicaciones. Tengo Ubuntu desde hace 1 mes o algo así. He instalado lo que me ha hecho falta y voy a quedarme si puedo.
Una de las cosas que no me gustan es que se pretenda negar la evidencia de que Linux no es gráfico y tampoco es aceptable para usuarios novatos. Pero vosotros sabréis.
Y no nos olvidemos de los drivers.
Espero que algún día saquen un asistente como el de Windows
(Agregar nuevo hardware, elegir de una lista, cojo el .inf, aceptar, siguiente, siguiente...).
Actualmente si no te lo detecta al instalarlo, un 99% se los usuarios no tenemos ni idea de cómo se instala un driver (aunque nos lo descarguemos).
#3 Yo creo que puede ser al reves, si se siguen esos pasos (algunos me sobran y otros me faltan pero bueno) para hacerlo aun mejor, se puede multiplicar por 1.000.000. Pero mientras tanto, es mas facil que la gente siga con su Windows porque es mas "facil" que no cambiarse a Linux "porque si somos muchos se hará mas facil".
Mientras solo para mejorarlo, me parece una propuesta bastante correcta...
#54 tal como lo dices parece que todas las aplicaciones gráficas están lanzando órdenes de texto contra una terminal por debajo, y no es así. Ocurre que en algunos casos cuando ya existe una aplicación muy potente via texto se hace un front-end gráfico de la misma (se me ocurre por ejemplo los codificadores de mp3 suelen usar lame) pero muchas veces ni siquiera ocurre esto, si no que se usan las librerías de dicha aplicación de texto.
No entiendo muy bien eso de que no es gráfico, y si es lo que yo he entendido, no creo que nadie quiera hacer que linux sea así de base, como tú sugieres. Y por cierto, Ubuntu no deja de ser una distribución de Linux que usa todo lo que hay desarrollado para cualquier otra distribución... (y yo uso Ubuntu).
Los 3 primeros son los mas importantes a dia de hoy. Ademas de seguir un estandart comun para todas las distros.
#44 Hay Proyectos para conseguirlo, ej: http://os.inf.tu-dresden.de/L4/LinuxOnL4/overview.shtml
Sigue buscando ¡Hay miles de premios!
#34 windows 2003 server - estamos usando un SO orientado a Desktop como servidor...
#54 Esto... ¿sabes que es un sistema operativo? ¿un kernel? ¿sabes sobre qué filosofía fué diseñado Unix? ¿dices que está mal, y que por el contrario debe ser "gráfico"?
Este tio que se fumo ...,
He escrito #26 y no entiendo pq se vota en negativo. ¿Es mentira lo que digo? ¿ofendo a alguien?.
Visto lo visto será cuestión de dejar de comentar para no ofender.
10 - El keyring o el KWaller, valen pero no dejan de ser una aplicación de gnome… quizá pensaba en una herramienta del sistema operativo… similar a lo que se ha hecho con apt-get para la gestión de las actualizaciones.
8 - Es cierto… hay decenas de lenguajes de scripting… pero ¿has probado el que tiene MacOs integrado? nada que ver… y mucho más potente… se puede hacer un script con las acciones propias de cada aplicación… muy potente para el usuario final!!!
7 y 6 - Hay librerías estándar (para KDE o GNOME), mantenidas y probadas por la comunidad... pero ¿las hay con caracter general, para todos los tipos de datos no-básicos (imagen, audio, video...) y con una funcionalidades que cubran todas las necesidades esenciales???
5 - Está sugiriendo un formato de intercambio de información estándar entre aplicaciones… sin pensar en conversiones de datos ni de formatos…
3 - Mucha de las funcionalidades que se esperan de un sistema operativo las están relegando a X11… Por ejemplo, se puede esperar que una vez que se conecte un pendrive USB, te lo monte automáticamente… o cuando se detecta una cámara web (acceso a sus tarjetas flash, sd…)
Bajo mi humilde opinión linux no llegará a ser una alternativa real a microsoft mientras sólo lo entiendan informáticos o gente dispuesta a pasarse horas para instalar una impresora.
Yo no soy informático de carrera, pero llevo delante del pc muchos años, y he intentado dar el salto a linux varias veces, pero la complejidad me ha hecho desistir a los pocos días.
Si se apostase por un linux tan sencillo de utilizar como un windows cualquiera; donde al disco duro se le llame "C" no /hdsc014568/root/..., cuando se elimien las palabras compilar, montar, que yo no digo que no estén, pero que para instalar el plug-in de flash en kubuntu, tengas que empezar a escribir comandos en una terminal..., que la informática es lo que es y muchísima gente no entiende el 80% de windows como para que den el salto a Linux.
Sólo fijaros en el artículo y en los comentarios, ¿creéis que alguien que utiliza el pc para navegar, bajar el correo y poco más se va a pasar a ubuntu después de leerlo?, creo que debéis reflexionar.
A ver, aclarémonos. ¿Estamos hablando a nivel de usuario experimentado o de usuario Desktop?
Si hablamos de usuario normal (el que viene de Windows y quiere jugar al buscaminas, chatear con las niñas y ver páginas guarras) a Linux le sobran y le faltan muchas cosas.
La más grave de todas es lo que hizo que Windows 95/98/ME fueran acribillados. Estos 3 sistemas tenían algo malo y era que estaban construídos sobre un sistema texto. Recuerdo los gritos de la gente exigiendo a Microsoft que hiciera de Windows un sistema gráfico desde el arranque. Y ahora me río porque los mismos que gritaban antes son los que ahora defienden a Linux como un sistema Desktop sin pararse a pensar que Linux arranca en modo texto y funciona en modo texto con una bonita máscara gráfica (llámese Gnome o KDE).
Conozco a Linux desde hace poco, pero lo cierto es que cualquier operación esconde una ventana terminal detrás. Y, además, hay cosas que no se pueden hacer desde gráfico.
Repito, si hablamos de mejoras de cara al usuario no experimentado, Linux se tiene que deshacer del texto.
En resumen, estamos usando un SO servidor como SO de escritorio, y eso en mi tierra es una chapuza.
#34 estoy contigo
TOTALLY NERD
HOYGAN KIERO LINUS MANDENLO A MI KORREO DARKKINGJUACKER@IAJU.OCM GRASIAS
¿Que coño es eso de cominudad?