Libertonia || Sobre este tema opinas que...


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Sobre este tema opinas que...


Sun está actuando mal al no dar la información.	25 votes - 33 %
Theo está actuando mal, está exagerando.	3 votes - 4 %
algunos desarrolladores Linux están actuando mal al aceptar el NDA.	14 votes - 18 %
Sun y algunos desarrolladores Linux están actuando mal.	11 votes - 14 %
todos están actuando mal.	4 votes - 5 %
ninguno está actuando mal.	4 votes - 5 %
otra cosa...	3 votes - 4 %
me falta información.	11 votes - 14 %

75 Total Votes

Sun continúa negando información a OpenBSD | 13 comentarios (13 temáticos, editoriales, 0 ocultos)

Monstruos con dos cabezas (4.66 / 3) (#1)
por ridiculum a las Tue Jan 28th, 2003 at 04:30:05 PM CET
(Información Usuario)

No hace mucho hubo un hilo en slashdot (http://slashdot.org/article.pl?sid=03/01/24/1446217&mode=thread&tid=98)
a cerca de los problemas que hay en las grandes compañias para mantener una postura coherente.

Bajo mi punto de vista y tras haber leido la historia en kerneltrap la postura de David Miller es correcta, puesto que el no puede contar como funciona el asunto de las cachee. La forma de ver las cosas de Theo tambien tiene cierta lógica, por que es bastante complejo sacar el funcionamiento de todo el tinglado del UltraSparc III a partir del codigo.

El problema es que Sun es un monstruo de dos cabezas donde por un lado tenemos una cabeza que apoya a linux y el software libre en general (y openbsd es tan libre como linux, no lo olvidemos) y por otro lado tenemos la cabeza estilo M$.

Sun tiene codigo en la libc sin ir más lejos y yambien ha donado como SL el IDE Eclipse, asi que no es ninuna novata en estas cosas. Además, el negocio del Sun es el hardware. Si obsd es capaz de correr en SU hardware, creo que se habre puertas en lugar de cerrarlas, así que no entiendo el por que no han ofrecido a la gente de obsd la misma documentación que a David Miller (eso es lo que yo he entiendo de todos los correos que se han cruzado estos dias y que se pueden leer en kerneltrap)

Tal vez por ahí vienen los tiros (3.00 / 1) (#2)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Tue Jan 28th, 2003 at 05:46:13 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Además, el negocio del Sun es el hardware.

Pienso que el negocio del hardware se ha acabado para Sun. Es probable que por ahí venga parte de la incoherencia. No saben qué hacer, si pasar de Solaris (para IA32 según lo que comenta la mayoría no es gran cosa, por ejemplo respecto a FreeBSD) y lanzarse definitivamente al mercado Java y periféricos asociados, o tratar de mejorar Solaris y meterlo en el mercado de servidores PC (pero para eso necesita una popularización de los entornos Unix, y de ahí parte del apoyo a Linux como plataforma de "salto").

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]

Creo que sigue siendo el hardware (3.00 / 2) (#3)
por bgood (bgood@aqui.no) a las Tue Jan 28th, 2003 at 06:35:13 PM CET
(Información Usuario) http://bgood.cjb.net

Para mi el principal negocio de Sun es,y seguirá siendo vender informática por kilos.

La propia compañia lo considera así.Lo puedes comprobar en el Nasdaq.Aqui se describe como una compañía de hardware y servicios.Por cierto,ni una palabra sobre Java.

Ahora una locura por mi parte.Pienso que lo que debería hacer Sun es seguir con Sparc,potenciando dicha arquitectura,pero no seguir haciéndolo con Solaris.¿Con que S.O? Con Linux claro.

Utilizar Linux,y desarrollarlo,les saldría bastante mas barato,sería muy bien visto por parte de la comunidad.Y de paso,seguiría muy en contra de Microsoft.

[ Padre ]

No lo tengo yo muy claro (3.00 / 1) (#4)
por ridiculum a las Wed Jan 29th, 2003 at 01:39:41 AM CET
(Información Usuario)

Ahora mismo cuantas plataformas de 64 bits fiables y con soporte hay? Sparc e IA-64. La otra arquitectura que yo recuerdo de 64 bits de uso comun era alpha, pero tras la movida que hubo entre Hp, Compaq y DEC y los acuerdos de HP-Intel para el IA-64 no se como ha quedado el asunto y tampoco se si continuaran el soporte de la base de alpha que ya existe.Con este abanico creo que el negocio de hardware de Sun tiene sentido.

¿Pero para que hace falta un Sparc si i386 es más barato? Pues bien, en algunas aplicaciones es necesario que un proceso tenga un espacio de direccionamiento mayor que el que da i386 (supongo que en aplicaciones donde haya BBDD de por medio) y por lo poco que se de SMP y Sparc, es posible agrupar mas CPU's en paralelo Sparc que i386, por mucho Xeon que tenga intel, y ademas hay que tener en encuenta que Sun tiene mucho más nombre en las plataformas de 64 bits que Intel con su Itanium2.

Respecto a que gaitas hacer con Java, Solaris, Linux y todo ese tinglado, volvemos a lo que comente en mi anterior mensaje: una empresa muy grande y muy dividida, como casi todas.

[ Padre ]

Sparc y los micros de 64 bits (3.00 / 1) (#5)
por jorginius ("jorginius" en Google Mail) a las Wed Jan 29th, 2003 at 01:59:56 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Ahora mismo cuantas plataformas de 64 bits fiables y con soporte hay? Sparc e IA-64

Te olvidas de SGI, IBM con sus PowerPC de 64 bits POWER4, HP con sus PA-RISC (PA8x00) y Alpha... HP no termina de abandonar la plataforma Alpha como punto a medio camino de los Itanium2, y como muestra este nuevo servidor Alpha, en el mercado desde este mismo año.

¿Pero para que hace falta un Sparc si i386 es más barato? Pues bien, en algunas aplicaciones es necesario que un proceso tenga un espacio de direccionamiento mayor que el que da i386

De hecho, en la mmu del micro del que estamos hablando, el UltraSPARC-III, el espacio de direccionamiento es de 64 bits, en comparación con los 44 bits del UltraSPARC-IIi de nuestras Ultra 5 y de los ¿34? bits de nuestras Alpha (¿eran 34?).

Ya no hay un "agujero" en medio de la VPTE como antes, ahora la tabla está completa... 2^64 direcciones, qué fuerte =8-)

por lo poco que se de SMP y Sparc, es posible agrupar mas CPU's en paralelo Sparc que i386, por mucho Xeon que tenga intel,

¡Y tanto!... Parece que SUN ha dado un golpe de mano con este nuevo chip. Entro otros avances, ha integrado el controlador de la memoria RAM dentro del micro (en vez de ir en el northbridge, como es habitual), con lo cual se elimina la contienda por ese elemento entre varios micros. Igual con las etiquetas de la caché L2, que cada micro mantiene las suyas.

Según la publicidad de la propia SUN, el sistema escala teóricamente hasta 1024 CPUs =8-)... Eso supera a todos sus competidores (hasta donde yo sé).

... Y todo esto ligeramente por debajo de 12.000 € de nada, para la workstation más básica.

Quizás los monstruos de IBM sigan machacando en rendimiento a las máquinas de SUN, pero en fiabilidad y escalabilidad parece que de momento ésta lleva la delantera.

[ Padre ]

Las otras arquitecturas de 64 bits :) (4.00 / 1) (#6)
por ridiculum a las Wed Jan 29th, 2003 at 03:15:02 PM CET
(Información Usuario)

> Te olvidas de SGI, IBM con sus PowerPC de 64 bits > POWER4, HP con sus PA-RISC (PA8x00) y Alpha... HP > no termina de abandonar la plataforma Alpha como
> punto a medio camino de los Itanium2, y como
> muestra este nuevo servidor Alpha, en el mercado
> desde este mismo año.

No plante a SGI con sus MIPS por que bajo mi punto de vista tambien andan dando tumbos, de forma muy similar a HP con Alpha. No tienen ni idea de por donde tirar. Ademas, las máquinas de SGI, tradicionalmente se han usado como grandes manquinas de rendering. Esas Octane, Onyx2, Origin y compañia eran las grandes maquinas para hacer "dibujos"
En http://sgistuff.g-lenerz.de/processors.html podemos ver creo que todos los micros MIPS y la verdad es que son bien "bonitos", pero parece que el ultimo desarrollo es del año 98, aunque en slashdot acabo de ver que han sacado un R12000
(http://slashdot.org/article.pl?sid=02/12/27/0327255&mode=thread)
y tambien de slhasdot he sacado el último lanzamiento de SGI, que curiosamente no usa MIPS, sino Itanium-2 (http://www.sgi.com/servers/altix/configs.html). Esas Altix son mas parecidas a un cluster que a otra cosa (de hecho tienen toda la pinta de una maquina NUMA) y no usan cpus de SGI sino de intel a pesar de tener un CPU reciente salida del horno.

Respecto al powerPC de 64 bits, pense que aun no estaba en el mercado. Algo habia oido, pero no sabiada que ya estaba en producción.

Lo de HP es digno de mención. Tiene ahora mismo, por decirlo asi 3 micros de gama alta: Itanium2 (aunque no sea suyo directamente, creo que tienen unas pocas de perras ahi metidas), PA-RISC y Alpha. Lo ultimo que lei de Alpha en Slashdot (http://slashdot.org/article.pl?sid=03/01/20/199244&mode=thread)
es bastante surrealista. Parece ser que el EV7 ha salido por que así debia ser (me suena que ese micro estaba casi a punto cuando se realizo la funsion), pero es realmente gracioso los rumores que apuntan a que no habrá comparativas publicas hasta que Itanium2 sea más rapido que el EV7. Eso creo que demuestra el poco apoyo que recibiria Alpha y la cantidad de perras que tiene que tener HP metidas en el Itanium2.

Sobre el direccionamiento de nuestros cacharros no recuerdo cual era el alpha que teniamos, pero podrian ser 34 bits.

Iba a comentar algunas cosillas del SMP en Ultra Sparc II que recuerdo haber leido en el libro de Tanenbaum "Organizacion de computadores", pero no lo encuentro, asi que no puedo transquirlo :(. Era una explicacion del por que el SMP en UltraSparc II es, por decirlo asi, más escalable que en el resto de arquitecturas.

[ Padre ]

SGI sigue en activo (3.00 / 1) (#9)
por jorginius ("jorginius" en Google Mail) a las Wed Jan 29th, 2003 at 03:43:30 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

No plante a SGI con sus MIPS por que (...) No tienen ni idea de por donde tirar. Ademas, las máquinas de SGI, tradicionalmente se han usado como grandes manquinas de rendering. Esas Octane, Onyx2, Origin y compañia eran las grandes maquinas para hacer "dibujos"

Te iba a decir "leñe, los CRAY son de SGI y no se usan para 'hacer dibujos'"... Pero no, por lo visto otra empresa le compró la plataforma y la marca en el 2000.

Sea como sea, apunta otra compañía que está en esto de la supercomputación (y en plan bestia, además): CRAY Inc.

parece que el ultimo desarrollo [de SGI] es del año 98, aunque en slashdot acabo de ver que han sacado un R12000
y tambien de slhasdot he sacado el último lanzamiento de SGI, que curiosamente no usa MIPS, sino Itanium-2. Esas Altix

Altix es una máquina de gama ¿baja?. SGI sí tiene maquinonas muy gordas y no basadas en Itanium2 sino en R14000, la Origin 3000 (PDF), aquí una foto del Origin 3900, un cluster de 4 máquinas.

[ Padre ]

Puntualización (3.00 / 1) (#11)
por Tomby (tomby@QuItAeStOtomby.tkNoSpAm) a las Wed Jan 29th, 2003 at 10:50:32 PM CET
(Información Usuario) http://www.tomby.tk/

Eclipse, que yo sepa, es un proyecto de IBM no de SUN. Supongo que te estabas refiriendo al IDE para Java NetBeans.

Aparte de esto, Sun también liberó el código de Star Office a partir del cual se ha venido desarrollado Open Office.

Saludos!

[ Padre ]

Ups (2.00 / 1) (#13)
por ridiculum a las Thu Jan 30th, 2003 at 12:51:50 AM CET
(Información Usuario)

Cierto, me lie un pelin con los nombres. Gracias por la puntualizacion.

[ Padre ]

No es que SUN niegue la documentación a OpenBSD (4.00 / 3) (#7)
por jorginius ("jorginius" en Google Mail) a las Wed Jan 29th, 2003 at 03:19:02 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Tal y como se menciona en el título de la noticia. SUN está dispuesta a dar la documentación de su micro a Theo si éste firma el NDA, igual que que hizo Dave Miller. SUN no pone ningun impedimento para que después se escriba y se publique el código correspondiente creado a partir de dicha documentación.

Tampoco se trata de un caso tan extraño. Muchos de los drivers que tenemos en Linux han sido creados de esa forma: firmando el NDA correspondiente y escribiendo la implementación GPL. Por ejemplo, este es el caso de los drivers de los scanners Primax. También para el port de Linux a PA-RISC se firmaron NDA para acceder a la documentación de HP, y hay muchos más ejemplos... Haced un:

$ find /usr/src/linux -type f | xargs grep -w NDA

Y podréis ver unos cuantos más.

En el caso de OpenBSD, los principios éticos de Theo de Raadt le obligan a no firmar ningún tipo de NDA y tampoco, claro, sacar la información de un código que ha sido escrito a partir de la aceptación de uno.

Aunque siempre es difícil sacar la documentación de un chisme a partir del código de otra persona, lo cierto es que el código de Linux en torno a las nuevas características del micro de SUN (que a pesar de todo, sigue siendo un SPARCv9) está bastante bien documentado (más comentarios que la media), bastante separado del resto y no parece especialmente oscuro (incluso para un analfabeto como yo :-)), así que no creo que fuera imposible para Theo hacer funcionar todas las nuevas características en su OpenBSD a partir del estudio de aquel código.

Más importante que el problema técnico, que lo hay, pienso que para Theo el problema principal es ético.

No está claro (3.00 / 1) (#8)
por Draco a las Wed Jan 29th, 2003 at 03:31:03 PM CET
(Información Usuario)

Hay informaciones contradictorias respecto a lo que dices. Según el redactor de Kerneltrap:
An early version of this manual was allegedly made available to Linux developers once a Confidential Disclosure Agreement was signed (Sun's version of a Non-Disclosure Agreement), however no such offer has been made to the OpenBSD team, an offer that if made is likely counter to the project's goals.

En cualquier caso, aunque se hiciera el ofrecimiento, Theo no aceptaría. Es bien conocida su firmeza respecto a las cuestiones de licencias, véase el tema de ipfilter.

Respecto a lo de si mirando el código de Linux se pudiera inferir fácilmente el funcionamiento de la cache, de ser así ¿qué sentido tiene el NDA?. El objetivo de Sun, parece ser, es ocultar información a otros fabricantes, más que a los programadores. No creo que OpenBSD les suponga una amenaza en absoluto.

Por cierto, ¿la FSF no dice nada de ésto?
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]

Hummm, parece bastante claro (4.00 / 2) (#10)
por jorginius ("jorginius" en Google Mail) a las Wed Jan 29th, 2003 at 05:09:51 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Hay informaciones contradictorias respecto a lo que dices. [que SUN dará la misma documentación a Theo si firma el NDA]

Bueno, me guío por la nota de prensa publicada en el cuartel general de OpenBSD, de Diciembre del 2002. Cito:

Sun Microsistems rechaza dar la documentación apropiada sobre sus CPU UltraSPARC III al proyecto OpenBSD sin antes firmar un NDA (un contrato de confidencialidad).

Respecto a lo de si mirando el código de Linux se pudiera inferir fácilmente el funcionamiento de la cache, de ser así ¿qué sentido tiene el NDA?.

En primer lugar, fácil lo que se dice fácil... No es que sea fácil coger el código de Linux y de ahí hacer tu versión para OpenBSD. Es un trabajo complicado y pesado... Pero creo que está al alcance de genios como Theo de Raadt.

Y aún con todo, no es lo mismo saber "cómo hacerlo funcionar" que "cómo funciona realmente".

A partir del código de Linux puedes saber cómo acceder al nuevo controlador de memoria integrado en el chip, o cómo detectar errores no recuperables (no fallos) de la cache, o con qué valores hay que inicializar los registros y cuál es la información que contienen, qué bits y qué indican los nuevos identificadores de dirección añadidos, etc. Lo que no podrás saber nunca es cómo funciona por dentro ese hardware.

Al parecer, esto de sólo conocer el funcionamiento de patillas para fuera a Theo no le basta. Debido a su habitual y sana paranoia nunca podría estar tranquilo pensando que ha podido dejar un agujero por no conocer todos los detalles.

Tampoco está muy claro qué información quiere Theo. En el enlace que a News.com, que aportan en la nota de prensa que te di antes, se dice:

De Raadt is particularly interested in UltraSparc III features that are well-suited to OpenBSD's emphasis on security--for example, memory protections that make computers less vulnerable to buffer overflow attacks.

Lo que comenta el articulista de "protecciones de memoria que hacen a las computadores menos vulnerables a los desbordamientos de buffer" creo que va por lo clásico de que los permisos de ejecución, lectura y escritura van "a nivel de página" en Sparc (en Intel esos permisos se fijan a nivel de segmento). Eso no parece que haya cambiado en nada en este micro. Lo más que se ve es que hay una nueva marca por página ("No Snoop tag", que tiene algo que ver con la caché y que Linux maneja).

Como ves, ni él lo aclara (todo el mundo habla de "la cache" pero no se especifica qué es lo que quieren saber de la caché), ni el artículo arroja mucha luz al respecto.

Volviendo al principio de tu comentario. ¿Qué sentido tiene el NDA si te dejan publicar el código después?. Bueno, a lo mejor te parece una tontería pero...

Recuerdo haber leído en alguna parte con respecto a lo del port de linux a PA-RISC que HP ofrecía la documentación bajo NDA porque no estaba lista para ser publicada de otra forma. Es decir: no habían separado lo que era "documentación secreta" de lo que se supone podían conocer los desarrolladores. Nadie se había ocupado de editar aquello y generar una documentación apta para su uso fuera de HP.

Puede que en SUN esté ocurriendo lo mismo: tienen toda la documentación junta, tanto la documentación propia "secreta" acerca de cómo es el diseño hardware, como la documentación para el desarrollador y, puesto que en teoría son ellos sólos (fuera del mundo libre) los que crean sistemas operativos para sus micros, no se hayan molestado en crear una edición "apta para todos los públicos" de los manuales.

Otra explicación es que SUN quiere que Solaris se imponga como único sistema operativo con soporte completo para ese micro, pero entonces no tiene ningún sentido que haya dado la documentación a Dave Miller y que permita la publicación del código, ¿no?.

[ Padre ]

Aunque sea repetir lo que ya hay en los enlaces (4.33 / 3) (#12)
por jorginius ("jorginius" en Google Mail) a las Wed Jan 29th, 2003 at 11:07:20 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

En primer lugar, fácil lo que se dice fácil... No es que sea fácil coger el código de Linux y de ahí hacer tu versión para OpenBSD.

Evidentemente, se trata de hacer la versión de lo que te haga falta que no esté documentado en el manual del UltraSPARC-III (PDF). No es que SUN no haya publicado nada: ha publicado su manual "para programadores de sistemas operativos" (sic) de quinientas y pico páginas, pero por lo visto es incompleto.

¿Y qué le falta?. En el comentario de kerneltrap, en el que se menciona el manual se habla de que faltan codigos ASI por definir y ha simple vista parece cierto, pues hay un montón de huecos en la lista etiquetados como "dependientes de la implementación"... Peeero me he entretenido en mirarlo (sí, estoy aburrido) y en Linux sólo está definido un ASI más aparte de los que aparecen en el manual (un tal ASI_IC_PRE_DECODE, que no usa en ninguna parte).

He mirado algunos registros más: en el registro DCR, de lo que hay en Linux a lo que hay en el manual sólo hay una diferencia de dos bits "dependientes de la implementación", que parecen ser los que indican si está activada la detección de errores de paridad en código y datos (De nuevo, esos bits a pesar de estar definidos no parecen usarse en ninguna parte del kernel y más parecen ayudas para la depuración del chip que otra cosa). El registro DCU ("Data Cache Unit control": el nombre parece prometedor por lo mucho que se habla de la cache indocumentada) resulta que es el mismo que aparece en el manual.

En fin, que seguro que oculta cosas (la propia SUN lo ha dicho) pero la información no es tan, tan incompleta. Supongo que con un ojo en esa documentación y otro en el código de Linux, un mago del kernel debería ser capaz de hacer funcionar OpenBSD con ese micro... Y si no habrá que esperarse a que otra empresa fabrique su propio UltraSPARC-III con especificaciones públicas para darle soporte.

Lo que esta claro es que nadie, a parte de esos magos del kernel, tiene muy claro que es lo que falta, y como el resto no lo tiene claro, la gente se dedica a especular por esos foros de Dios (como hago yo en Libertonia, vamos :-)).

[ Padre ]

Sun continúa negando información a OpenBSD | 13 comentarios (13 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda