Tráfico del Núcleo #99 For 25 Dec 2000

There were 453 different contributors. 197 posted more than once. 152 posted last week too.

Eckhard Jokisch tuvo algunos problemas usando una unidad Onstream, y en el curso de la discusión, Rogier Wolff dijo:

Mantenerse alejado de onstream es mi consejo en estos días.

Hemos estado tratando que la estúpida cosa trabaje desde el 8 de julio, y el soporte técnico de onstream ha sido de mucha ayuda diciéndonos que hacer y demás. Como retroceder a una versión del núcleo que tiene ataques remotos conocidos. De cualquier forma, haciendo eso no resuelve los problemas que reportameso. Después de tanto, prometieron "escalar" el problema a gente en los [E]stados [Unidos], y entonces esto no nos lleva a resultados en el mes que les dimos.

En breve: en el caso más simple, tan solo escribiendo una cadena de octetos a la unidad, funciona. Pero entonces la unidad no tiene ni cercanamente la "tasa bruta de error" que proclaman.

Si empieza usando un programa de respaldos que necesite buscar atrás y adelante algunas veces, la unidad pierde la pista de dónde está, y no se recupera de esta situación.

He regresado la mía a mi vendedor, y espero que Onstream obtenga al fin el mensaje: Ellos NO dan soporte a Linux.

Pero Kurt Garloff disentió, "¡He estado usando las versiones USB y SCSI de las citas OnStream con buen éxito!" Añadió, "Si quieres un consejo realmente útil: Usa el controlador osst y [después] úsalo con ide-scsi. Reporta los problemas a la lista de correo de osst. Hasta ahora, no estoy enterado de alguien que hayamos fallado en ayudarle. http://linux1.onstream.nl/test/" Eckhard replicó, "Eso fue real realmente de completa ayuda :-) Trabaja bien ahora. ¿No sería bueno poner una ligera pista en algún lugar de la configuración del núcleo?" Fin de la discusión.

Matti Aarnio anunció que eliminó toda alimentación de correo-a-noticias de Innominate. Éstas incluían alimentaciones de linux-alpha, linux-doc, linux-fsdevel, linux-kernel, linux-raid, linux-scsi, linux-smp, sparclinux, y ultralinux. Dijo, "Oficialmente no aprobamos alimentaciones bidireccionales noticias<->lista, ya que son propensas a este tipo de equivocaciones de mensajes atrapados en ciclos de regreso a la lista."

Sabemos que es una configuración difícil y la probamos extensamente antes de usarla, y funcionó por mucho tiempo hasta ahora. Desafortunadamente uno de nuestros administradores actualizó el servidor de noticias hoy sin pensar en las implicaciones :-(

Lamentamos profundamente esto y honestamente nos disculpamos, pero también quisiéramos resuscribirnos...

Rik van Riel sugirió hacer la alimentación de una sola vía en esta ocasión, ya que las alimentaciones bidireccionales siempre tienden a dar problemas, en su opinión. Juri respondió que eso es lo que tendría que hacer, ya que no parecía tener muchas opciones. Pero Miquel van Smoorenburg ofreció:

En ftp://ftp.cistron.nl/pub/people/miquels/software/cistron-m2n-1.36.tar.gz encontrarán algún software de enlace que es unidireccional, aunque bidireccional. ;)

Funciona marcando los grupos como moderados. Un mensaje publicado al grupo será enviado por correo electrónico al moderador, que es un guión que revisa y reescribe el mensaje de noticias, y lo envía a la lista.

De esta forma es casi imposible que los ciclos sean creados.

En otro lado, Marco d'Itri anunció "Si a los administradores de correo de vger no les molesta, la próxima semana voy a enlazar unidireccionalmente linux-kernel (y tal vez otras listas vger de gran tráfico, ¿alguna sugerencia?) a un grupo en la jerarquía linux.*." Matti replicó, "Eres bienvenido a hacer eso. Es solamente al enlace BI-direccional al que nos oponemos por razones bien observadas... (La gente hace enlaces bidireccionales a pesar de nuestra oposición -- "somos buenos, no haremos nada malo", pero cuando las cosas de cualquier forma van mal, tenemos que ejecutar algunas medidas drásticas para cortar los ciclos.)"

3. Limpieza De sysklogd; Usando Encabezados Del Núcleo En Programas Del Espacio de Usuario

Georg Nikodym reportó que sysklogd 1.3-31 no compila más usando los encabezados de 2.4.0-test11, porque linux/module.h ha cambiado en una forma incompatible. Añadió, "Estrictamente hablando no es un error del núcleo" [...] "No es claro para mí, de quién es el código que necesita cambiar así que estoy enviándolo tanto a linux-kernel como a algunas de las gentes que tienen la mala fortuna de estar enumeradas en la página de manual de sysklogd." Keith Owens replicó:

Hablando como el que mantiene modutils y la persona que añadió list.h a module.h, sysklogd *no* debe estar incluyendo linux/module.h. Linus ha hablado, es un error de las aplicaciones del espacio de usuario incluir encabezados del núcleo. Aún modutils no incluye linux/module.h, en lugar de eso tiene una definición local portátil (2.0 a 2.4) de struct module.

ksym_mod.c está solamente presente para tratar de decodificar reportes de oops en klogd. klogd solamente maneja algunas arquitecturas, y frecuentemente obtiene la decodificación de oops mal y destruye la información de log que es necesaria para otros decodificadores de oops. EMNTHO ksymoops hace un trabajo mucho mejor de decodificar los oops, pero yo mantengo ksymoops por lo que estoy solamente un poco polarizado ;)

Yo preferiría ver la decodificación de oops eliminada completamente de klogd. La única justificación para que klogd convirtiera los oops es salvar a los usuarios de correr ksymoops a mano. A mí no me molestaría que klogd capturara el texto de oops, haciendo un 'fork' para correr ksymoops y después registrar la salida de ksymoops. Sólo mientras el texto original fuera dejado sin cambios y la salida de ksymoops fuera obviamente distinguida de la salida del núcleo real.

Georg implementó esta sugerencia y publicó un parche, pero Keith replicó, "Solamente eliminaste el manejo de símbolos de los módulos. El problema es que el manejo completo de oops de klogd está desactualizado y descompuesto. Recomiendo remover todo procesamiento de oops de klogd, lo cual significa que klogd no necesita ningún símbolo ni System.map." Georg replicó que revisaría eso, y agregó, "mientras estamos haciendo cirugía extrema, ¿Porqué tenemos klogd después de todo? En cualquier otro unix, los mensajes del núcleo son manejados por el sistema syslog. ¿Qué problema resolvió klogd y ese problema aún existe el día de hoy?" Sugirió que la proposición de Keith sería el equivalente funcional de 'cat < /proc/kmsg > /dev/log &'. Keith explicó, "klogd mapea los mensajes del núcleo del texto<n> a los niveles de syslog levels y hace algún manejo con niveles de registro del núcleo en el arranque. Necesita ser algo más que un simple 'cat'. Cuando el manejo de símbolos fue agregado a klogd, ksymoops fue construido dentro del núcleo y era muy poco fiable. Desde entonces ksymoops ha sido movido a un paquete separado y ahora es confiable. Pero el manejo de oops en sysklogd no se ha mantenido al día y ahora es el área problemática." Georg realizó una apendicectomía, sacando todo el código de procesamiento de símbolos de sysklogd, y sugiriendo la remoción de varios ficheros de ese paquete también. Pero ahora Keith objetó, "Se ve bien, excepto que necesitas conservar las banderas de opciones por la compatibilidad hacia atrás. Hay *muchos* guiones que invocan klogd con varias opciones y fallarán con este cambio. Es OK mostrar un mensaje de advertencia "klogd options -[iIpkx] are no longer supported" mientras klogd continúe corriendo. De otra forma obtendrás un grupo de usuarios iracundos quejándose que klogd falla al momento de arranque." Georg publicó un nuevo parche para mostrar varias opciones de comando de línea como obsoletas, y la discusión se detuvo.

4. Actualización Del Módulo Ethernet Para La Tarjeta D-LINK DFE-530-TX Card En 2.2

Mike A. Harris preguntó cuál módulo ethernet debe usar con su tarjeta D-LINK DFE-530-TX card. Peter Horton replicó, "Si el ID de dispositivo PCI es 3065 entonces es via-rhine, pero no tiene soporte con el controlador en el núcleo. Obtén el via-rhine actualizado del sitio de Donald Becker http://www.scyld.com/network." Pero Jeff Garzik puntualizó, "2.4.x-test tiene algunas correcciones para via-rhine que no parecen haber entrado en el controlador de Becker aún..."

Simon Huggins preguntó si cualquiera de ambos entraría a via-rhine del 2.2, y Jeff dijo, "Becker nunca contesta a parches y cambios que le envío, así que quién sabe. Pregunta a Becker..." Alan Cox también dijo que incluiría código portado en 2.2.19pre si alguien lo escribía. Urban Widmark publicó un largo parche y explicó:

A continuación un parche que actualiza el controlador via-rhine 2.2, derivado de la versión 1.08b de Becker, excepto por la prueba pci que está sin cambios, macros para compatibilidad y código muerto que no es necesario en 2.2 eliminado (eliminación de ifdef CARDBUS es de 1.08b) y "clear_tally_counters" de 2.4.

Sería bueno si la gente que está usando 2.2 y una de estas tarjetas pudiera probarlas también.

El parche incluye:

nuevo id pci VT6102 & soportando buffers de datos no-alineados para ese chip
completamente sin probar (por mí, así es) cosas de big<->little endian
liberar memoria alojada en la descarga del controlador
no más writel a 0x7c.
2 valores de 16bit accedidos como un valor de 32bit (¿porqué? no esto seguro, ¿optimización pci?)
cambio en el tamaño del anillo de transmisión

y otros cambios/limpiezas más o menos menores.

Esta es casi una operación de copiar y pegar. Si prefieres hacer un cambio más pequeño para solamente dar soporte a VT6102 es fácil de hacer.

De cualquier manera, es muy similar al controlador 2.4 (el bloqueo es una diferencia mayor) por lo que espero esté ok. También, si no incluyo la mayor parte del controlador 1.08b no estoy seguro de que nombre de versión darle ... :)

Jeff V. Merkey señaló que ya ha enviado cientos de sus herramientas de reparación para NTFS, a gente que lo contacta después de corromper sus sistemas de ficheros con el soporte horriblemente descompuesto de lectura/escritura de sistema de ficheros NTFS bajo Linux. Añadió, "Seguiré proveyendo este servicio, pero solamente estoy tratando los síntomas de la enfermedad y no estoy curando al paciente. Basado en el nivel de contaminación de TRG con IP" [Siglas de Propiedad Intelectual, en inglés] "de Microsoft, me han aconsejado que si yo publico un reemplazo de NTFS antes de que la doctrina de 18 meses de la "ventana" de inevitabilidad haya pasado, Microsoft casi seguro nos demandará, y ganará." Sugirió alertar a los usuarios de que la funcionalidad era peligrosa e inestable, y que no debían usarla. Peter Samuelson replicó:

Esta es una idea: hagamos el soporte a l/e una opción separada de CONFIG y la etiquetamos como "DANGEROUS" [PELIGROSA].

Oh esperen, ya hicimos eso.

Tal vez deberíamos advertir a los usuarios que respalden su partición NTFS antes de intentar esta opción. Poner esa advertencia en el texto de ayuda para CONFIG_NTFS_RW.

Oh esperen, ya hicimos eso también.

¿Que tan estúpido tiene que ser uno para habilitar una opción marcada como "DANGEROUS" para un sistema no-experimental?

Más tarde, Michael H. Warfield también agregó, "No puede siquiera habilitarse a menos que se activen las opciones de código experimental. Entonces, está deshabilitada por omisión y primero se debe habilitar NTFS S/L. Entonces debes escoger explícitamente la opción para habilitar acceso LE que está claramente etiquetado DANGEROUS. Esta cosa no es armada y peligrosa por un acto de omisión. Está viva y activa solamente a través de tres actos de comisión. Acerca de la única acción dejada fuera, además de eliminarla del núcleo por completo, es hacer oculto el control de la opción, como algunas de las opciones de depuración, que requieren editar un fichero de encabezado o un Makefile para habilitarlas." Posteriormente en la discusión, Peter también sugirió, "comentar la línea CONFIG_NTFS_RW por entero. Actualmente, creo que *sería* una buena idea. Cualquiera que tenga algún negocio lidiando con NTFS_RW es más que capaz de editar Config.in." Jeff Garzik coincidió, y agregó, "Preferiría que los sistemas de ficheros con soporte a escritura conocidos como descompuestos dependieran de CONFIG_BROKEN (que siempre debería estar definido como 'n')"

En otro lado, Jeff V. M. agregó, "He obtenido aún más malas noticias -- porque está en Linux, Microsoft ya está alterando las estructuras en-disco de nuevo, así que está a punto de descomponerse en modo S/E también cuando Whistler salga." En respuesta a la idea de que no se necesitan ser tomados más pasos preventivos o advertencias adicionales para evitar que la gente eche a perder sus sistemas, añadió, "Ustedes chicos hacen la llamada. Aquí estaré para recibir los 100+ mensajes que normalmente son publicados a la lista del núcleo con "Linux destruyó mis datos", y que yo he estado manejándolos. Solamente los estoy alertando que el número de gente necesitando esto se está incrementando, lo cual es una indicación de que más y más gente está usando Linux para migrar NT a Linux, y vice-versa, y metiéndose ellos mismos en problemas. Necesitamos hacer una tormenta de ideas para obtener una solución a más largo plazo para este problema. Sospecho que si publico esas herramients en nuestro servidor de FTP para descarga gratis, MS rápidamente se presentará con abogados. Normalmente, esto es lo que yo haría, pero estas herramientas fueron desarrolladoas a través del acceso a IP de MS, y mientras yo esté ayudando a clientes MS a recuperar datos en una capacidad de "consultoría", no creo que interferirá, particularmente desde que cada vez que esto sucede, Linux obtiene un gran ojo ennegrecido con el cliente afectado. Pero muy pronto (como después de que 2.4 se libere) el número de personas necesitando esto podría incrementar a una capacidad a la que no puedo dar soporte adecuadamente sin liberar esas herramientas para distribución generalizada -- entonces la mierda pegará en el ventilador con MS si hago eso."

Eric W. Biederman dijo que si Microsoft está deliberadamente evitando la interoperabilidad entre Windows NT y Linux, que Jeff V. M. debería alertar a los abogados antimonopolio. Pero Jeff V. M. replicó:

Creo que los asuntos antimonopolio son discutibles -- ya han tenido su efecto con Microsoft. Fueron dejados golpeados y lisiados a la vista del público en general. Los Grandes Clientes parecen no estar tragando .NET.

Su conducat es inconsistente con la decisión del Juez del Juicio. Técnicamente, al buscar .NET, no están atendiendo al espíritu del dictamen. Si se aplica un dictamen sobre tí en una corte, se supone que observarás lo que dice y corregirás tu conducta, aún si la orden de ejecución estuviera detenida por la apelación pendiente en la corte. El Juez no parece haber retirado la decisión -- sigue ahí.

Por esto, cualquier inversión en estrategias de Microsoft por clientes de grandes empresas son una incógnita hasta que la corte de apelaciones tome una determinación. Microsoft también se está preparando para una orden de desprecio al hacer esto. La corte del juicio le dijo que se mantuviera fuera del negocio de internet con su unidad de negocios de sistemas operativos. Su cumplimiento ha sido ilusionario con la decisión de la corte, y a menos que la corte de apelación revoque el dictamen, podrían estar en grandes problemas.

Si yo fuera el DOJ, ya habría preparado un OFC para llenar con la corte del juicio. También están haciendo las peores cosas que puedes hacer mientras un caso está en apelación, que es ignorar el dictamen del juicio de la corte, y recurrir a la descalifiación del carácter del juez del juicio.

En otra parte, aproximándose al problema entero desde un ángulo diferente, Ren Haddock dijo, "Pienso que parte del problema es que hay otras cosas marcadas DANGEROUS que realmente funcionan de forma bastante confiable (de momento, estoy pensando en las cosas de configuración de IDE..). Tal vez necesite decir explícitamente 'Está descompuesto y está garantizado que destruirá sus datos. No lo use'. La etiqueta 'DANGEROUS' parece sugerir que -podría- destruir datos, lo cual conduce a 'a mí no me sucederá' mentalmente." Andre Hedrick replicó históricamente:

DANGEROUS == GO_FOR_IT_DUMB_ARSE_SCREW_YOURSELF_WILDLY

Esa es la intención, cuando puse e inicié las opciones DANGEROUS. Debido a la naturaleza volátil del código en extermo alfa en el inicio. De cualquier manera mientras pasó el tiempo, la gente no pensó que tuviera significado, pero así es como originalmente fue definido por mí.

David Feuer coincidió con Ren, la etiqueta "Dangerous" no parece ser una advertencia absoluta para no habilitar una característica dada. Daryll Strauss sugirió reetiquetar esas opciones como "Broken" [Descompuesto], pero Jes Sorensen replicó, "Dudo que haga una diferencia de cualquier forma que lo escribamos. He visto varias veces como los usuarios activan cada opción porque 'no quieren perderse nada de nada'."

Si esto fuera un negocio, y estuviéramos distribuyendo software con conocimiento de que fuera peligroso, probablemente estaríamos en riesgo de acción legal.

¿Por qué estamos distribuyendo software tan severamente descompuesto? Caramba, parecemos reticentes a incluir reiserfs, un sistema de ficheros con soporte y de muy alta calidad. Y continuamos distribuyendo esta !@#$%... Debe haber alguna agenda extraña destinada a limitar el uso de Linux.

Pero Horst von Brand replicó que no sería legal, porque hay avisos prominentes mostrados. Añadió, "Es tan solo que NTFS ha estado en el núcleo por eras, y se pudrió. Nadie se ha tomado el tiempo para removerlo (sería mucho menos que lo que se ha desperdiciado hasta ahora discutiendo el tema aquí...)."

Compilé la distribución Debian del código fuente de 2.2.18pre21 en y para una AcerNote-950, con APM habilitado.

Todo está bien excepto que puedo hacer "oops" consistentemente simplemente intentando leer de /proc/apm (p.e. cat /proc/apm).

salida de oops y salida de ksymoops-2.3.4 se han anexado.

¿Hay algo más en lo que puedo contribuir?

La latitud y longitud de la posición actual de los escritores de bios, y un misil balístico.

Por favor arranca 2.2.18pre24 (no pre25) en la máquina y envíame sus cadenas DMI impresas al momento de arranque. Las agregaré a la lista de 'morones estúpidos que no pueden programar y no reconocerían QA [Control de Calidad, por sus siglas en inglés] si los golpeara en la cabeza con un mazo

Neale lo hizo, pero no pudo ver nada parecido a una "cadena DMI", y Alan replicó, "Ok tu máquina probablemente no tiene DMI entonces. Eso desafortunadamente signfica que es difícil de identificar la máquina específica." Después de transitar por una breve escala juntos, Neale salió con un parche para trabajar alrededor de su BIOS defectuoso.

Fabien Ribes notó que la información del estado de Linux con respecto a RFC 1122 (Requerimientos para Hosts Internet -- Capas de Comunicación) están dispersas a través de numerosos ficheros. Preguntó, "¿Hay un documento completo mostrando el estado RFC1122 como un todo para una versión dada de núcleo ?" David S. Miller respondió brevemente, "No, desafortunadamente nadie ha tenido el tiempo para hacerlo." Andi Kleen added, "La evaluación del RFC es también desactualizada y debe ser reescrita o eliminada." David coincidió, y dijo que eliminará todos los comentarios de "RFC1122 Status" de net/ipv4/*.c a menos que Andi quisiera arreglarlos. Andi replicó, "Mátalos ;)" David replicó, "Hecho. En serio, si alguien quiere hacer este trabajo por favor contacte a Andi o a mí mismo, estamos dispuestos a dar alguna asistencia." Fabien dijo que él podría tener tiempo para hacer algún trabajo en eso; pero no hubo más discusión.

Steven Cole usó tiempo de compilación del núcleo como prueba patrón, y concluyó que en sistemas uni-procesador, 2.2.18pre26 era 3% mas rápido que 2.4.0-test12-pre7 para construir núcleos. Pero remarcó con cierta ironía, "De cualquier manera, el margen de victoria es lo suficientemente pequeño para que un recuento sea necesario." También agregó que había usado gcc 2.91.66 (kgcc) para compilar el núcleo 2.2.18 usado como el SO en la prueba, y gcc 2.95.3 para el 2.4.0 usado como el SO para la prueba. Varios individuos objetaron que kgcc haría un núcleo más rápido que gcc, y para ser justos, los sistemas donde residen las pruebas debían ser compilados con el mismo núcleo. Steven replicó con algunos resultados nuevos, en los que mostraba que de hecho kgcc creaba núcleos ligeramente más rápidos que gcc. Pero al volver a correr una de sus pruebas mostró solamente unos cuantos segundos de mejora sobre la prueba anterior. Agregó consistentemente, "pero pienso que estamos ante el embarazado o sábalo con hoyuelos en este punto." Así que su reporte inicial parecía sostenerse, y hubo una breve discusión de porqué 2.2.18 podría ser más rápido que 2.4.0. En cierto punto, Alan Cox remarcó, "Es una demostración interesante que 2.4 tiene algunos problemas de rendimiento ya que 2.2 es más lento que 2.0 aunque en estos días no mucho."

Después, Steven corrió un conjunto similar de pruebas patrón en sistemas SMP, y reportó que para esos sistemas, 2.4.0 era 2% más rápido que 2.2.18; Linus Torvalds replicó:

Noten que la compilación del núcleo realmente no es una prueba patrón relevante, porque las diferencias de porcentaje en este rango pueden ser básicamente tan sólo ruido: cosas como diferencias de versiones de controladores que aparecen, pero impactan a diferentes máquinas en formas diferentes (tal vez un controlador es mejor para ciertas máquinas, y peor en otras. Cosas como esas).

La configuración que describes es solamente muy intensiva en CPU, con poco potencial para diferencias verdaderamente interesantes.

Steven había mencionado que en la prueba SMP, había "corrido X y KDE 2.0 durante las pruebas para proveer una carga mayor, pero reproducible en el núcleo probado." Linus sugirió, en su propia respuesta:

Podrías hacer lo mismo en 32-64MB de RAM. Y en ese momento mover tu ratón alrededor un poco para evitar que KDE/X sean paginados fuera de memoria, punto en el cual se vuelve des-interesante de nuevo. No se cómo hacerlo repetible de cualquier manera, pero una cosa que hago ocasionalmente es leer mi email (que no es muy intensivo en CPU, pero mantiene el escritorio activo y también me da una indicación para conducta interactiva).

En este punto los números probablemente irán a mostrar mayor diferencia (y la variación probablemente irá a ser mucho mayor).

Steven trató la misma prueba de nuevo, haciendo un 'make -j3', moviendo el ratón alrededo, y cambiando de escritorios algunas veces; y reportó, "Estos resultados son aún más cercanos. Las diferencias son tan ligeras, que no son estadísticamente significativas. Hmmm, tal vez que no hay noticias es buena noticia en este caso." Linus sugirió:

De hecho, hazlo con:

make -j3 'MAKE=make -j3' bzImage

Un solo "-j3" no hará mucho. Solamente construirá tres directorios a la vez, y nunca verás mucha carga. Pero haciéndolo recursivamente significa que contruirás tres al mismo tiempo en todos los directorios hojas, y deberás ver cargas mayores a 20+, y mucho más presión de memoria también.

Steven intentó esto, y reportó que 2.4.0 aún terminó 1.3 segundos más rápido que 2.2.18, y que la carga del sistema también se mantuvo más baja. No hubo más discusión.

En el transcurso de la discusión, Alan Cox proporcionó su esperada línea de tiempo para 2.2.19. En relación a algunos posibles cambios, dijo, "No sucederán en 2.2 hasta 2.2.19, lo cual probablemente significa 6 meses." Horst von Brand solicitó un 2.2.19 rápido, para incluir tan sólo las composturas a errores particulares en discusión, pero Alan replicó, "Debo hacer una liberación 2.2 para cada trivialidad. Creo que no. Ya hay bastante para llegar a 2.2.19." Fin de la discusión.

Mark Symonds reportó sistemas bloqueados con muchos errores "VM: do_try_to_free_pages failed" llenando la pantalla en 2.2.18; agregó, "Algo más que he notado es que la Carga promedio está generalmente alrededor de 0.08, pero cuando la dejo inactiva por unos cuantos minutos, tan solo al teclear la barra espaciadora causará que deje de responder por 10 o más segundos con la carga promedio elevándose a más de 6. Después de eso el sistema algunas veces se recupera y comienza a responder normalmente, otras veces morirá." Alan Cox replicó, "el parche global-MV de Andrea parece ser una cura maravilla para aquellos que lo han intentado. Dale una prueba y deja a la gente saber." Mark y alguien más intentó el parche y reportó éxito completo, punto en el cual Alan remarcó, "Pienso que Andrea acaba de ganar su estado de Dios oficial ;)" Otra persona preguntó si el parche de Andrea sería incluído en 2.2.19, y Alan replicó:

La pregunta es meramente 'en qué forma' . Yo quiero conservarlo separado de los otros grandes cambios en 2.2.18 por obvias razones.

Andrea - ¿Podríamos tener los cambios de MV nucleares que hiciste sin adoptar el cambio en la semántica de semáforos para bloqueos de sistema de fichero que les dará dolores de cabeza a los que mantienen fs de terceras partes y que tampoco coincide con la conducta de 2.4 ?

Andrea Arcangeli replicó con algunos comentarios técnicos, y él y Alan estuvieron ida-y-vuelta por un rato.

Rob Landley dió un apuntador a un artículo de noticias de de LinuxToday, and explicó, "Scott McNealy aparentemente ha llamado a Solaris la implementación de Sun de Linux. Tiempo de violación de marca registrada." Citó el artículo, donde cita a Scott (CEO de Sun) mientras dice, "Ustedes las personas no lo captan, ¿o sí? Todas las aplicaciones Linux corren en Solaris, que es nuestra implementación de Linux." Rob admitió que la fuente de la cita era cuestionable, pero asumiendo la exactitud de la cita, "esto me golpea como una violación de marca registrada mundial, y exactamente el tipo de cosas para las que la marca registrada Linux fue diseñada para prevenir. Solaris NO es Linux."

Hubo varias tomas diferentes en esto. Rik van Riel dijo, "Yo no me preocuparía por eso. Es sólo una cuestión de tiempo antes de que la gente comience a preguntarle porqué Sun no está distribuyendo el "Linux original" y tiene su propia y extraña versión ;)" Esto hizo a Igmar Palsenberg revolcarse de la risa, pero Rob replicó, "Seguro. Entonces ¿Por qué TENEMOS una marca registrada si no la hacemos cumplir? El apoyo popular siempre es una cosa maravillosa, y educar al público es extremadamente importante. Entonces de nuevo, lo que McNealy está tratando es confundir a sus clientes. Haciendo cumplir la marca registrada entonces serviría con propósito educativo, ¿o no? :)"

En otro lado, Kevin A. Burton sintió que los comentarios de Scott, aunque fueran exactos, parecían mas como un comentario "al margen", y no había motivo para preocupación; pero Rob replicó:

La ley no es una cosa de todo-o-nada. Obviamente esto no merece una demanda. Por sí mismo no esta ni siquiera cerca.

Pero enviando una carta oficila pidiéndoles que respeten la marca registrada cuenta como "defender la marca registrada" por si es abusada en el futuro y REALMENTE queremos ser serios al respecto. (Neutraliza eso como un precedente para que los abogados poco escrupulosos no puedan apuntar que "Linux" no es defendible como una marca registrada y en su lugar debe ser un término genérico.)

Y si el patrón de conducta FUERA a continuar/empeorar, haber pasado a través de los pasos apropiados anteriormente (respuestas proporcionadas, mesuradas a incidentes tempranos) hacen una base más firme para una demanda posterior.

Y, porque los abogados de Sun conocen este último punto, ellos seguramente lo tomarán lo suficientemente serio para hacer saber a McNealy que su curso de acción conlleva ciertos riesgos. (Recuerden aquella plática de Hackeo de Meme, en las empresas Fortune 500 todo está alrededor de reducir y administrar el riesgo.)

Es un poco como decir el nombre de tu gato cuando lo ves sobre la mesa del café donde se supone que no debería estar. No es lo mismo que castigarlo, tan solo hacerle saber que sabes lo está haciendo.

Esto acarrea una situación interesante.

La comunidad Linux sigue diciendo que "Linux es una re-implementación de Unix."

Esto mantiene a todos los de X/Open molestos con nosotros, porque Linux no ha pasado los juegos de pruebas de calificación que ellos utilizan para la marca. Así que le hemos sacado la vuelta diciendo "Unix se parece mucho a Linux, excepto que cuesta mucho dinero, viene en forma binaria, etc. etc."

Aún no hay una definición real para "Linux".

Algunas personas (la FSF por ejemplo) dice que Linux es solamente el núcleo, pero hay diferentes núcleos, con diferentes parches.

Hubo incluso una versión Microkernel de Linux llamada "MKLinux".

Otros dicen que Linux es la distribución completa, pero hay muchas distribuciones, todas diferentes (Red Hat, SuSE, etc.) Hay diferentes ubicaciones de ficheros en el árbol de ficheros.

Sé por conversaciones con Linux que él anticipa tener (tal vez) núcleos radicamente diferentes sobre máquinas "BIG IRON", donde los núcleos (y las distribuciones) vengan de los fabricantes de la "BIG IRON".

El licenciamiento de la marca registrada Linux ha permitido básicamente a alguien usar el término "Linux" en su propia marca registrada, pero no ha hecho nada para prevenir a alguien de comparar su acumulación de código con "Linux", y nada para definir lo que Linux es actualmente.

Si es verdad que "todas las aplicaciones Linux funcionan sobre Solaris", ¿que estándard los previene de llamar a Solaris como tan sólo otra implementación de Linux? ¿Y debería hacerlo?

Desde una perspectiva ISV, entre más distribuciones de software haya que corran sus productos binariamente compatibles, mejor que estemos contra Microsoft. Si Linux no maneja las máquinas de alto high-end (aún), entonces ¿por qué no dejar que esas aplicaciones corran en Solaris? Si la gente quiere pagar por Solares, tomar la distribución únicamente binaria de Sun y ejecutarla en aquella gran máquina, ¿por qué no?

Por otra parte, pienso que necesitamos algún tipo de definición para lo que sea llamado "Linux". Tal vez esto es donde Linux Standard Base pueda ser apropiado.

Rob coincidío con muchos de los puntos de Jon, pero aún sintió que "Sun es libre de sacar una versión de Linux. Pero llamarla Solaris Linux es, en mi opinión, ir sobre el borde y diluir la marca registrada." Él dió una liga a un mensaje de Linus Torvalds explicando la postura general de Linus sobre el tema de la marca registrada. Agregó, "Si decimos que Linux es Solaris, Sun estaría sobre nosotros con Abogados. Ellos tienen que proteger su marca registrada. Si Red Hat llama a su próxima liberación de Linux" [...] ""Red Hat Solaris", serían demandados."


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	30 Nov 2000 - 13 Dec 2000	(7 posts)	Problemas Con Unidades De Disco Onstream
2.	6 Dec 2000 - 12 Dec 2000	(7 posts)	Problemas En El Enlace A Noticias De linux-kernel
3.	6 Dec 2000 - 11 Dec 2000	(11 posts)	Limpieza De sysklogd; Usando Encabezados Del Núcleo En Programas Del Espacio de Usuario
4.	6 Dec 2000 - 14 Dec 2000	(15 posts)	Actualización Del Módulo Ethernet Para La Tarjeta D-LINK DFE-530-TX Card En 2.2
5.	7 Dec 2000 - 11 Dec 2000	(76 posts)	Soporte para Lectura-Escritura En NTFS Descompuesto Y No Debe Ser Usado
6.	7 Dec 2000 - 12 Dec 2000	(13 posts)	Problema de APM En AcerNote-950
7.	8 Dec 2000 - 13 Dec 2000	(18 posts)	Alguna Limpieza De Documentación
8.	10 Dec 2000 - 15 Dec 2000	(28 posts)	2.0 Más Rápido Que 2.2 El Cual Es Más Rápido Que 2.4 (Excepto Para SMP)
9.	13 Dec 2000 - 14 Dec 2000	(11 posts)	Línea de Tiempo Para 2.2.19
10.	13 Dec 2000 - 17 Dec 2000	(17 posts)	Problemas de MV En 2.2.18
11.	14 Dec 2000 - 16 Dec 2000	(16 posts)	Posible Violación De La Marca Registrada Linux Por Sun

Tráfico del Núcleo #99 For 25 Dec 2000

By Zack Brown

Translated By: Cristian Othón Martínez Vera