2 puntos por GN⁺ 2024-05-20 | 2 comentarios | Compartir por WhatsApp
  • El índice Computers de yarchive es un recurso que agrupa antiguas publicaciones de Usenet por temas como arquitectura de computadoras, lenguajes, sistemas operativos, Linux, hardware y negocio de la computación, para facilitar su exploración
  • Computer Architecture reúne discusiones de diseño de bajo nivel como procesadores de 128 y 64 bits, AMD64, cachés, RISC vs CISC, TLB, SPEC, VAX y zero registers
  • Programming Languages cubre no solo C, Fortran, Ada y COBOL, sino también temas prácticos alrededor de los lenguajes, como optimización de compiladores, ABI, punteros, volatile, long long, la GPL y linking
  • El área de sistemas operativos se extiende desde BSD, microkernels, mmap, setuid y vulnerabilidades de seguridad en FTP hasta desarrollo del kernel de Linux, sistemas de archivos, seguridad, Git, GPL y barreras de memoria
  • Cada entrada muestra el título del texto, el autor y el tamaño en bytes, lo que facilita elegir qué leer en el archivo original por tema y autor

Formato del índice y cómo leerlo

  • La página Computers de yarchive es una lista de enlaces que divide textos relacionados con computadoras por tema
  • Cada enlace suele incluir la siguiente información
    • Título del texto
    • Nombre del autor o de los participantes
    • Tamaño del texto, por ejemplo: [8913 bytes]

Computer Architecture

Programming Languages

The Computer Business; Miscellaneous

Hardware

Operating Systems

Subsección de Linux

  • Linux es una sección separada bajo sistemas operativos, con muchas entradas relacionadas con el desarrollo del kernel y la programación de sistemas
  • Trata sobre documentación de ABI, ACPI, BIOS, capa de bloques, cachés, estilo de codificación, Git, GPL, headers del kernel, locks, barreras de memoria, sistemas de archivos, seguridad, scheduler, TLB, UTF-8, zero-copy y otros temas
  • Entradas representativas
  • Linus Torvalds, Al Viro, Theodore Ts'o, H. Peter Anvin y otros aparecen repetidamente en varias entradas de Linux

2 comentarios

 
GN⁺ 2024-05-20
Comentarios de Hacker News
  • Mientras más envejezco, más siento que Usenet fue una oportunidad perdida. Con unas pocas mejoras, podría haber ocupado el lugar de Facebook —cuando dejó de centrarse en conectar amigos— o de Reddit, y también habría sido excelente para promocionar negocios locales y distribuir noticias.
    Era descentralizado, tenía varios clientes y podía dividirse en temas tan específicos como se quisiera, así que la estructura de grupos habría correspondido casi directamente con los subreddits.

    • @asjo, de koldfront.dk, todavía usa NNTP para varios fines, como agregador RSS, motor de blog y servidor ActivityPub: https://koldfront.dk/just_call_me_mr_nntp_1871
      Realmente fue una oportunidad perdida; el protocolo es fácil de entender y encaja bien con la descentralización y el self-hosting. Es una lástima que, después de Python 3.12, nntplib esté previsto para eliminarse en 3.13; NNTP merece revivir.
    • Usenet tiene bastantes problemas difíciles. En especial, la moderación y eliminación son problemáticas: uno debería poder editar o borrar sus propias publicaciones, o publicaciones que más tarde resulten ser ilegales, y eso incluso implica revisar el contenido antes de publicarlo.
      El spam también es un gran problema, y para evitar la suplantación habría que firmarlo todo, pero usar criptografía correctamente es, por experiencia, muy engorroso. Ya hemos visto que ni siquiera funciona de forma satisfactoria en el correo electrónico. Además, me pregunto si Usenet podría manejar la escala de hilos calientes como los de Reddit, con decenas de comentarios por segundo. ¿De verdad todo eso se resolvería con “unas pocas mejoras”?
    • En el hilo sobre email 2.0 hubo una discusión algo similar: https://news.ycombinator.com/item?id=40392709
      Así como el dinero malo desplaza al bueno, parece que los malos servicios desplazan a los buenos. Por conveniencia, lo centralizado vence a lo descentralizado, y esa conveniencia atrae a la gente hasta terminar encerrándola dentro de la plataforma. El Usenet clásico todavía existe, y si tienes una dirección de correo puedes crear una cuenta en Eternal September. No hay muchos usuarios, pero puedes ser uno de ellos.
    • Todavía uso directamente algunos grupos, pero el tráfico disminuye día a día. Era simple, no te obligaban a tener una cuenta y el threading era excelente.
      Hoy, pensando en la suplantación y demás, las cuentas podrían ser útiles, pero la puntuación y el plonk eran herramientas realmente poderosas para gestionar y filtrar lo que querías leer. Había problemas para sincronizar el estado de lectura, pero hoy eso podría mejorarse fácilmente.
    • Al solicitar un feed nuevo, sobre todo si querías un feed moderado, unos gatekeepers arrogantes ponían muchísimas trabas. Esos gatekeepers no vieron venir el tren de la web, y cuando se dieron cuenta ya era demasiado tarde.
  • Una de las publicaciones de Usenet que todavía me pone la piel de gallina es esta, publicada desde Berlín el 10 de noviembre de 1989: https://groups.google.com/g/eunet.politics/c/LbrVEM7zp-Y/m/a...

    • Que hubiera comentarios del estilo “Alemania solo estuvo unificada entre alrededor de 1890 y 1945, y ni siquiera fue precisamente un gran éxito” muestra una mordacidad muy de los años 80. Me pregunto si hoy alguien podría escribir algo así en un entorno respetable.
    • Vi esto en HN hace un año[1]. Me sorprendió ver a la gente debatir en HN, como si fuera cualquier otro tema, sobre un acontecimiento que yo solo conocía por documentales.
      [1]: https://news.ycombinator.com/item?id=35937637
    • Me pareció tan sorprendente que se lo envié a mi padre, que vivía en Berlín Occidental desde 1950.
    • Vale la pena leer ese hilo. Deja claro que predecir el futuro es difícil.
    • Acabo de enterarme de que Usenet empezó en 1980; es realmente impresionante.
  • https://yarchive.net/comp/sandboxes.html es un ejemplo interesante de la primera ley de Clarke: “Cuando un científico distinguido pero mayor afirma que algo es posible, casi siempre tiene razón; cuando afirma que es imposible, muy probablemente está equivocado”.
    El texto de Theodore Ts'o sostiene que el sandboxing de software, si no imposible, sí es bastante difícil. Su razonamiento es que el usuario o el programa aislado tendrían que configurarlo, pero el usuario no sabe qué hacer y no se puede confiar en el ejecutable. Pero omite el enfoque en el que el sistema operativo define todas las formas de sandboxing y el software se adapta a ellas. Android e iOS, y cada vez más Linux mediante snap y flatpak, usan este modelo. El sandboxing no solo es posible, sino esencial.
    Equivocarse no es un gran pecado; a todos nos pasa a veces. Además, el autor siguió haciendo un gran trabajo en el kernel de Linux. Es interesante pensar por qué la gente inteligente se equivoca y mantener una postura escéptica ante las afirmaciones de “imposible”.

    • No necesariamente es solo eso. Un programa puede presentar sus requisitos como un manifiesto comprensible, y el usuario puede elegir permitirlos o rechazarlos.
      Un sandbox estandarizado facilita la usabilidad y el análisis, y permite que los desarrolladores de aplicaciones apunten a un modelo de seguridad fácil de entender. El problema del texto original es que asume que todos los programas no maliciosos deben ejecutarse sí o sí, por complejos que sean. Es la misma forma de pensar absurda que decir que los métodos formales son imposibles por el problema de la parada. Si no lo hacen fácil de analizar, simplemente lo rechazas, y así evitas el problema de la parada.
    • También se puede perfilar la ejecución en un entorno menos confiable y luego definir el sandbox a partir de esos resultados. Por ejemplo, ejecutar Linux en modo de aprendizaje NSA SEL.
      Este enfoque de vigilancia de sistemas tipo caja negra funciona bien incluso con sistemas secretos, olvidados o propietarios, y es una buena práctica de ingeniería para la mayoría de los sistemas, sean de hardware o de software, porque las anomalías suelen detectarse bastante bien.
  • Podría pensarse que NNTP no escala, pero incluso en su apogeo Usenet no era la única red NNTP. Había numerosos servidores NNTP de nicho que no hacían peering con Usenet, y algunas comunidades NNTP de nicho todavía funcionan bien.
    Incluso una red pequeña y cerrada con unos pocos peers puede manejar cientos o miles de personas. La estructura de las redes sociales nos acostumbró a que todo el mundo se nos venga encima en el feed o la bandeja de entrada, pero no tiene por qué ser así. Por eso NNTP es bueno. Que no haya participación masiva abrumadora no es un bug, sino una feature.

  • Para usarlo sin conexión, se puede descargar desde aquí: https://yarchive.net/downloads/
    En GNU/Linux o BSD, usar algo como Midnight Commander es práctico porque permite leer los archivos directamente sin descomprimirlos.

  • Ojalá hubiera una forma de ordenar esto por fecha.

  • El problema de que “el público principal de un nuevo lenguaje de programación son los programadores existentes, es decir, personas que ya están acostumbradas a lenguajes que usan palabras clave en inglés. Quienes tienen dificultades con las palabras clave en inglés probablemente no trabajen como programadores, así que su voz no se escucha”[1] va mucho más allá del inglés y los lenguajes de programación.
    [1]: https://yarchive.net/comp/english.html

  • Ya no se puede encontrar el hilo incendiado ni el archivo de correos de julio de 1992, cuando se anunció SimCity corriendo sobre HyperLook de NeWS para SunOS 4.1 y se distribuyó por ftp.uu.net, lo que provocó críticas por supuestamente abusar de Internet para distribuir software comercial.
    Se podía descargar por FTP una demo completamente funcional, pero después de unos minutos la ciudad se derretía; si llamabas a un número 800 y comprabas una clave de licencia con tarjeta de crédito, podías desbloquearlo de inmediato. Por un costo adicional, también te enviaban por correo una caja con disquetes y un manual impreso. En ese entonces no existía https y no había muchos servidores web http; enviar números de tarjeta de crédito por email no era una decisión prudente.
    Hasta antes de eso, el uso comercial estaba prohibido por la política de uso aceptable de ARPANET del Departamento de Defensa de EE. UU., pero alrededor de 1991 la NSF levantó las restricciones al uso comercial de NSFNET. Sin embargo, cuando SimCity para Unix se lanzó comercialmente en julio de 1992, no todo el mundo estaba al tanto, así que naturalmente recibió críticas.
    Rick Adams, que estaba en la primera línea de la comercialización de Internet, dio una cuenta para distribuirlo por FTP anónimo en ftp.uu.net; como él consideró que estaba bien, ignoré a quienes se quejaban. Como una buena parte del tráfico UUCP de Usenet pasaba por el hub de uunet, a veces recibía correos enviados por error a don@uunet / uunet!don, pero ninguno contenía números de tarjeta de crédito.
    https://donhopkins.com/home/SimCity_HyperLook.gif
    https://donhopkins.com/home/HyperLookSimCityManual.pdf
    https://groups.google.com/g/comp.windows.x/c/ukCskm_x410/m/G...
    En los primeros tiempos de ARPANET, el uso comercial estaba prohibido, y durante el proceso de comercialización y privatización de Internet, el alivio de las restricciones de NSFNET en 1991 y la privatización del backbone en 1995 fueron puntos de inflexión importantes. Rick Adams y UUNET también desempeñaron un papel importante en la comercialización de Internet al expandirse desde servicios de Usenet y correo basados en UUCP hacia un backbone comercial de Internet.
    https://en.wikipedia.org/wiki/Rick_Adams_(Internet_pioneer)
    Suck.com Net.Moguls Internet Mogul Trading Cards: https://web.archive.org/web/20181211075708/http://www.suck.c...
    Rick Adams, Front: https://web.archive.org/web/20180802115113im_/http://www.suc...
    Rick Adams, Back: https://web.archive.org/web/20180802143444im_/http://www.suc...

    • Ojalá no se use ChatGPT para producir basura al escribir comentarios en HN.
    • UUCP e Internet no son lo mismo, pero ambos alojaban Usenet y correo.
      El gran punto de debate en la comercialización de Internet era que originalmente las empresas conectadas a Internet tenían prohibido enrutar paquetes para terceros, y lo que realmente cambió el juego fue la modificación de esa política. Después de eso, cualquiera pudo participar.
  • Me parece notable la frase: “¿Por qué creen que Linux se convirtió en el Unix más ampliamente distribuido? Porque evitó los nichos, evitó la endogamia y no estuvo demasiado dirigido, así que no sufrió los problemas que se ven en los sistemas desequilibrados”[1].
    [1]: https://news.ycombinator.com/item?id=40404440

 
jangsc0000 2024-05-20

Publicaciones clásicas de Usenet sobre arquitectura de computadoras, sistemas operativos y lenguajes