To Be or not to Be, por Álex
Tras ver los comentarios de mi anterior artículo, y volver a escuchar algunos comentarios acerca de "Be", la alternativa de Jean Louis Gassée a NeXT, voy a volver a analizar (ya que este debate lo he tenido bastantes veces) esta opción y por qué Apple la desechó.
Lo primero Be era un sistema operativo nuevo, joven e inacabado, y como tal era potente, pero le faltaba madurar... mucho.
Las bases del BeOS estaban inspiradas en XINU. Un sistema operativo pequeño, rápido y elegante, la frase que lo define es: XINU no es UNIX, ni lo pretende (XINU es UNIX, al revés).
Pero Be si lo pretendía. Be tenía un microkernel impresionante, y las bases del OS eran de lo mejor del momento. Todas las llamadas eran multihilo intensivo (Pervasive multithread), multiprocesador (hasta 8 procesadores), sistema de archivos de 64 bits, multitarea apropiativa (preemptive multitasking), memoria protegida, y el sistema era orientado a objetos.
El sistema tenía una base solida, pero como ya he dicho, esa base no se completaba con las capas necesarias:
1- El sistema era mono-usuario, de base, y en principio no se había desarrollado una capa que pudiera complementar el acceso de diversos usuarios a una misma máquina. Eso cerraba las puertas, por ejemplo, a tener un sistema cliente-servidor.
2- Tampoco permitía compartir ficheros a través de la red (en realidad podías acceder a través de Telnet, pero ¿quién comparte archivos a través de Telnet? Más tarde pusieron un servidor FTP.... mono-usuario, en un intento de paliar esa gran deficiencia.
3- El sistema no era multilenguaje, no es que en aquella época fuera una gran necesidad, pero después de sufrir la traducción de los programas y el sistema "a mano", la verdad es que podrían haber previsto que los sistemas mono-lenguaje son complejos de actualizar. Tampoco tenía soporte completo de Unicode y los programas que utilizaban fuentes de 2-bytes tenían que hacer redirecciones (esto lo arreglaron en la última versión pero estuvo así muchos, muchos años.)
4- No tenía soporte para JAVA... glups
5- El sistema no tenia ninguna capa de seguridad ni de cifrado (claro que no se podía acceder a ella fácilmente, por lo que no era necesaria), pero todos sabemos que ya en aquella época no se podía tener una máquina aislada del mundo.
6- El sistema no implementaba Postscript, era capaz de imprimir en impresora láser y las tipografías podían ser TrueType (y en las últimas versiones Tipo 1), pero no tenía un intérprete Postscript y hasta ellos dudaban y hablaban de lo rudimentario del único programa capaz de leer PDFs (Ghostscript).
7- El soporte del sistema operativo para la reproducción de vídeo estaba limitado a la reproducción de películas acopladas en formato Cinepack de QuickTime (con el tiempo salieron reproductores de terceras empresas que permitían reproducir MPEG y otros formatos, pero el sistema no tenía ningún sistema de vídeo, como QuickTime o Windows Media File.
8,9,10,...- El sistema gráfico sólo permitía un monitor, el sistema era mono-teclado, mono-ratón, sin soporte RAID, sin compatibilidad X11 y con un sistema de impresión deficiente.... y un laaaaarrrrgoooooo etc.
Pero aparte de estas deficiencias, que, en mayor o menor medida podrían haberse arreglado o añadido, donde BeOs pinchó catastróficamente, fue en una de sus aparentes ventajas: el sistema multihilo.
Be implementó un sistema multihilo impresionante, rápido, y muy bien organizado, pero tremendamente tedioso a la hora de programarlo, y además era de uso obligatorio, así que todo programador tenía que usarlo, quisiera o no.
Los resultados saltaban a la vista: los programas volaban, el sistema no se congelaba, todo en Be fluía de manera increíble, pero a costa de horas de programador.
Y todos sabemos lo vagos que somos los programadores. Programar tan intensamente un programa, como Photoshop, en multihilo desde la primera línea, sería un trabajo casi titánico.
Para un programador es mucho más sencillo empezar por partes: primero los plug-ins o los programas que aprovechan profundamente el multihilo, como los de 3D (mental-ray) o los efectos de Photoshop, después vas creando partes del programa que requieren de un proceso menos exigente, para, en última instancia, si quieres y el cuerpo te pide guerra, atacar aquellos que son meramente de interfaz o de diálogo con el usuario.
Porque la realidad es que, por mucho que lo queramos, y salvo casos de estudio científico, todos somos "mono-cerebro" :D:D:D y muchas de las funciones que realizamos con el ordenador son una detrás de otra (que conste que no estoy en contra del multihilo, sino en contra del multihilo inútil.)
El fin es el mismo: programas multihilo, pero el camino no tiene nada que ver, y cambiar la mentalidad de todos los programadores para Mac, así, de un plumazo, no creo que hubiera sido factible.
Conclusión
La elección de Apple creo que fue más que acertada, y el resultado final creo que es y será mucho mejor que lo que hubiera podido ser con Be.
No todo es velocidad. Un sistema tiene que estar bien pensado, y bien acabado. Apple podía haber acabado el sistema operativo de Be, sí, pero sin cambiar sus bases (sobre todo el multihilo obligatorio), ningún programador importante la hubiera respaldado. Y el hecho de cambiar sus bases hubiera sido como quitarle el corazón. Be sin el multihilo intensivo no sería Be... así que la elección, para mi, fue la acertada. Apple hizo bien al quedarse con NeXT en vez de Be.
http://www.dmi.unict.it/~pappalar/lab3/xinuhome.html
Noticia Siguiente: Desarrollo con Ruby on Rails en Mac OSX (I): El entorno
Los comentarios que vulneren los derechos de otros usuarios, estén relacionados con actividades ilegales , supongan un claro ejemplo de interés comercial o sean ajenos al contenido de la noticia serán borrados sin aviso previo. Una buena ortografía y sintaxis ayudará a otros usuarios a entender mucho mejor sus inquietudes. Una vez enviado el comentario, se hará visible en unos minutos. Si cree que alguno de los comentarios publicados vulnera sus derechos, por favor, envíenos unas líneas a través de nuestro formulario de contacto. Al colocar un comentario en esta web, acepta que sus datos queden recogidos en una base de datos propiedad de Entremaqueros, SL., ubicada en EE.UU., cuya finalidad es el exclusivo almacenamiento de los mismos.
Esto solo me confirma algo que desde hace tiempo p
Esto solo me confirma algo que desde hace tiempo pienso.
El C++ es una mierda absoluta.
Fantastico articulo, tanto como el anterior, sigue
Fantastico articulo, tanto como el anterior, sigue asi Álex ;)
De donde se deduce que, en realidad, todo es una c
De donde se deduce que, en realidad, todo es una cuestión de dinero.
- Un procesador/chipset ideal es perfectamente factible pero caro.
- Un SO rapidísimo y maravillosamente adaptado a dicho hard es caro (por los tiempos de programación).
- Programas rapidísimos y maravillosamente adaptados dicho SO son caros (por los tiempos de programación).
Así que en realidad sólo tenemos lo que podemos pagar... ¿Alguien estaría dispuesto a pagar el doble por un Macintosh con un auténtico procesador IBM Power dentro? ¿Y a soportar el ruido de sus ventiladores (o a tener la CPU metida en un cuarto aislado y refrigerado)? ¿No? Pues eso.
estoy totalmente de acuerdo. Trabajé durante años
estoy totalmente de acuerdo. Trabajé durante años con Next y con Be con programas propietarios de los dos sistemas (que eran fantásticos). Solo añadiría que Next fue invención del propio Jobs y era totalmente lógico que escogiese el sistema que conocía (creo que tampoco se llevaba muy bien con Gasset?, esto ya es cotilleo puro y duro)
Dupo, Jobs no estaba en Apple cuando la compra de
Dupo, Jobs no estaba en Apple cuando la compra de NeXT. Seguro que influyó mucho, pero no pudo ser él puesto que vino junto con la compra de NeXT ;-)
No puedo negar las evidencias del artículo, pero desde mi punto de vista Be era más "Mac OS" que NEXTSTEP. Era como ver el Mac OS del 2000 en 1996!
No estoy de acuerdo. Be era eso, pero todo evoluci
No estoy de acuerdo. Be era eso, pero todo evoluciona, una "cutre empresa" como Yellotab ha incorporado multiusuario y multilenguaje a Be y comprobad la lista de soporta hardware que ya ha alcanzado..., respecto a "horas de programador", por favor, ¿cuántas horas de programador cuesta hacer cualquier mínimo desarrollo en java?? compáralo con el equivalente en Delphi, VB, etc..., al final se hubiera sacado un XCode o similar para Be y ya está...
Respecto a Java, una máquina virtual se hace, como ha hecho Apple con su máquina virtual para OSX ¿o acaso es la de Sun o la de IBM, ni siquiera la de blackdown.org la que instalamos en los Mac?? Pues igual hubiera sido para Be.
Volviendo al multiusuario, ¿cuántos maqueros hacen uso de eso??, cuántos mac se usan como servidores de X11 remotos???
En suma, que eligiendo Be, y con el esfuerzo de Apple, sus productos seguirían estando en la punta de lanza tecnológica, seguirían fieles a las necesidades reales de sus usuarios, y seguirían teniendo el "espíritu" distintivo tradicional...
Ahora, con un Unix más (más bonito), ya ha perdido gran parte del encanto, y, con el pase a intel, pues el resto...
En pocos años, cuando los escritorios Linux se vayan acercando, y comparando hardware intel con intel (o AMD, etc...), un Mac, ¿qué me aportará frente a un Linux, OpenSolaris, FreeBSD???
Más bien me veo montando Linux en una Playstation 3...
Saludos
El No estoy de acuerdo es con la conclusión del ar
El No estoy de acuerdo es con la conclusión del artículo, no con la opinión justo anterior a la mía, que dice básicamente, y con menos palabras, lo mismo que yo...
Saludos otra vez...
Viva BeOS, mas bien creo que se esta interpretando
Viva BeOS, mas bien creo que se esta interpretando la profesia luego de esta a ver pasado, o sea, adaptando nuestras respuestas y analisis a lo ya sucedido, buscando la razon de ser y dandolas por logicas y razonables. Si la eleccion hubiera sido BeOS los articulos dirian exactamente lo mismo, del por qué Be fue la mejor eleccion y no NextStep. Indudablemente cada uno tiene pros y contra, ambos de mucho peso para crear debates. Seguro que el que Jobs fuera propietario de Nextstep jugo un papel importante en la seleccion. Personalmente prefiero BeOS. Viva BeOS.
No estoy de acuerdo con la programación multihilo
No estoy de acuerdo con la programación multihilo - los procesadores multicore están demostrando que la programación multihilo va a ser necesaria (se van a seguir añadiendo cores...) y los programadores "vagos" tendrán que dejar de serlo lentamente...
Con el articulo no estoy diciendo que el multihilo
Con el articulo no estoy diciendo que el multihilo no sea importante y que no haga falta programar en multihilo, que hace falta y mucho, lo que digo es que no siempre es necesario y que el coste de hacer todo en multihilo, muchas veces no se justifica y por eso la obligatoriedad (recalco la OBLIGATORIEDAD) del Multihilo de BeOs ya entonces e incluso ahora está fuera de cualquier medida razonable. (aun existiendo procesadores duales y multihilo)
Y es evidente, BeOs era un sistema con buenas bases, pero inacabado y NextStep era un sistema con buenas bases y buenos acabados.
Creo que hay un error, y es que BeOS no tenia un m
Creo que hay un error, y es que BeOS no tenia un microkernel. Si, tenia pinta de serlo, porque tenia el App_Server, el Print_Server, etc.. pero no era un microkernel. De todos modos, sus "deficiencias" podrian haber sido subsanadas por la gente de apple.
De todos modos, nunca he sido mas feliz con mi S.O. que con mi BeOS. Y era super super rapido....
En realidad Apple escogió NEXT porque en realidad
En realidad Apple escogió NEXT porque en realidad no compró Openstep. Lo que Apple en realidad compró fue a Steve Jobs.
Y como diria el poema de Robert Frost, "The Road Not Taken"
'And that makes all the difference'
(y eso hace toda la diferencia)
Evidentemente Alex o quien quiera que seas que hay
Evidentemente Alex o quien quiera que seas que hayas sido capaz de publicar semejante barbaridades, No tienes ni la más minima idea de Sistemas Operativos ni has llegado a programar la mas minima línea de código en BeOS o ZETA(EN EL LENGUAJE QUE SEA).
Solo comentare unas partes, por que ya es suficientemente vergonzoso tener que leer eso una y otra vez para comentarlo.
Hay una considerable comunidad utilizando a diario auna ahora BeOS, además de una empresa llamada yellowTAB manteniendo el trabajo que Be hizo en su dia, ya que ZETA (BeOS R6)que está ahi fuera, y vendiendo. Por ello desecho totalmente que el "sistema inacabado" que comentas.(en todo caso, lo fue)
El 90% de las deficiencias que dices se solventaron hace tiempo.
Estas desechando el multihilo.....!"$§%&/ Tienes algun idea de informatica chico?
NO puedes ser un programador en condiciones piensas que la API que BeOS ofrecia era tediosa. La has leido quizas?? o quizas seas programador por algún cursillo de poca monta en "Academia Tecla Feliz" ?
Tampoco te veo enterado que cual fue la vedadera historia de Apple interesado en Be ... asi que... por favor abstente, de comentar algo que no tienes ni idea.
Espero no tener que volver a leer algo asi.
También hay que recordar que NEXTStep se adaptaba
También hay que recordar que NEXTStep se adaptaba mejor para realizar el salto del sistema 9 al 10. No recuerdo bien eso de las diferentes capas o colores (dos ya desarrolladas entonces) que luego se convirtieron en Classic, Carbon y Cocoa.
Aunque también creo que compraron el kit completo; habría que saber que hubiera pasado sin Jobs.
Bueno, con el paso a Intel, vamos a poder disfruta
Bueno, con el paso a Intel, vamos a poder disfrutar también de BeOS, seguro…
Oliver, respecto a criticar la API de BeOS, te puedo decir que estuve registrado en las listas de programación de Be, y recibí los interesantísimos —sin coñas, de verdad que eran interesantes— mails de Gasèe… pero Be era mucho más difícil de programar que Cocoa, y tanto como Carbon.
Y cualquiera que haga programación multihilo te dirá que hay muchísimos casos particulares que hay que considerar, y que la mayoría de las veces las soluciones que se adoptan para arreglar problemas no permiten obtener una eficiencia completa en los hilos…
También digo una cosa: en un momento en el que nos movemos hacia multiprocesadores, la programación multihilo cada vez va a tener más importancia…
Respecto a las horas de desarrollo en Java, la ver
Respecto a las horas de desarrollo en Java, la verdad es que últimamente lo estoy utilizando mucho, y hay muchas cosas del lenguaje que me gustan, y me encantaría que Xcode fuese a Objective-C lo que IntelliJ IDEA es para Java…
Que yo sepa, estoy en más parte de acuerdo con Oli
Que yo sepa, estoy en más parte de acuerdo con Oliver que con el artículo de cabecera. Be era el sistema. Apple siempre eligió lo mejor: Motorola cuando estaba la porquería del 8086, disquetes de 3'5 cuando los pcs y todos usaban 5 1/4, etc... y aquí, ¡vuala! vuelve Jobs de una gran experiencia, la del NeXT, que fue muy aplaudida y zas!! se queda en lo más antiguo. UNIX. Sin embargo Mach, el kernel de Darwin es, según los expertos en UNIX, el mejor kernel de UNIX que hay, por lo minimalista, que es lo más deseado.
Y por otro lado NeXT era ya una experiencia andante. Aquellos que estén programando Cocoa lo saben: Cocoa es la adaptación del la interfaz gráfica del NeXT al MacOSX.
En aquél entonces la decisión era muy difícil. Recuerdo meses tensos, pruebas con Be... Cuando se decidió Darwin... todos nos quedamos fríos, mejor dicho, callados. Sabíamos que UNIX, a pesar de los achaques, es un sistema muy probado y NeXT más aún. No eran tiempos de más experimentos. Apple se hundía. Creo que Jobs es muy sensato cuando lo tiene que ser.
Lo que es más interesante de analizar es el trabaj
Lo que es más interesante de analizar es el trabajo que se hizo para que Rhapsody fuera compatible con Mac OS 9. Cajas amarillas, azules... a ver si con el paso a Intel sale ya la maldita ROJA!
Hay algunas cosas que se echen en falta en el Kern
Hay algunas cosas que se echen en falta en el Kernel Kit de BeOS. Unas se solventan solo escribiendo los recursos que echas en falta con los basicos que ofrecen(colas bloqueantes), otros por desgracia no es posible...(asignar thread a procesador explicitamente...) AUN.
Peo NUNCA la API es tediosa o dificil de programar. En (casi) la UNICA parte en la que el programador se tiene que preocupar de "los Threads" es en el Kernel Kit. Todo lo demas es totalmente transparente.
Yo he adaptado de código UNIX y Linux en este contexto, y he podido hacerlo sin problemas ni y sin incrementar el número de lineas.
Y lo siento, pero escribí una tesis sobre ello.
Y lo de XINU ya es... en fin... por favor...
Todo el mundo (de la comunidad BeOS) sabe perfectamente que si se han de buscar antepasados a BeOS estos se han de buscar en el mundo Amiga.
Por lo que pones no has programado en BeOS en tu v
Por lo que pones no has programado en BeOS en tu vida. El multihilo es perfecto ya que es obligatorio usarlo pero sin que el programador tenga que poner ni una sólo línea de código. Cada vez que se crea una ventana se crea un hilo ¿qué hace el programador?:
BWindow* w = new BWindow();
w->Show();
Listo, una ventana con multihilo. ¿Tedioso?
Cierto es que tenía muchas carencias (que no errores) pero el mercado tampoco lo dejó madurar. Y, realmente, Apple fue el peor error que cometió al no elegir a Be como fabricante de su sistema operativo, ya que, recordemos, MacOS X es un UNIX con un pseudo-micro-kernel que tiene un cuello de botella impresionante a la hora de gestionar los hilos... lee un poco más de las noticias importantes y sabrás por qué.
Por cierto, no hablas nada de la arquitectura general del sistema, que va con servidores y demás, no como en MacOS que va con daemons... solución obsoleta ¿qué tipo de comunicación hay entre daemons dentro del sistema? ¿con sockets? En BeOS es con ports, mucho más rápida y moderna y, sobre todo, mucho más fácil de programar.
Por tu artículo veo que eres un auténtico "experto" en BeOS... y supongo que no lo habrás probado (y mucho menos programado) en tu vida.
Si AmigaOS hubiese madurado creo que seria el mejo
Si AmigaOS hubiese madurado creo que seria el mejor sistema operativo para todos y para todo.
Si AmigaOS hubiese madurado creo que seria el mejo
Si AmigaOS hubiese madurado creo que seria el mejor sistema operativo para todos y para todo.
Definitivamente la mejor parte del articulo son su
Definitivamente la mejor parte del articulo son sus comentarios, al final la mayoria opina a favor de BeOS y difiere totalmente de la conclusion del articulo. De los muy, muy, muy, muy, muy, muy, muy, muy pocos articulos negativos sobre BeOS en internet y al parecer totalmente desacertado.
Enviar un comentario nuevo