otro blog más

¿Matará la IA la colaboración abierta?

Tres noticias…

La primera, la declaración de Leiden sobre matemáticas e IA, con el soporte de la International Mathematical Union, que dice que cuidado con la IA. No dice que la IA no pueda suponer grandes avances (que los ha habido) en el campo, pero sí que está rompiendo cosas (más detalles en el New York Times y en Ars Technica). Mencionan, por ejemplo, que los colosos de la IA no son nada transparentes en el proceso (actualmente las matemáticas de primerísimo nivel son una cosa sorprendentemente abierta), y eso es realmente problemático. Pero me quedo, sobre todo, con otra de las cosas que destacan: los modelos de lenguaje están haciendo que alguien sin conocimientos pueda producir un intento de resolver un problema clásico extremadamente verosímil, sea correcto o no… y que esto está haciendo que los departamentos de matemáticas del mundo se vean inundados de demostraciones que, lamentablemente, se demuestran erróneas casi siempre… pero no sin consumir una cantidad de horas más que notable. Uno recuerda la época en que era extraño que pasara un año en ningún departamento de matemáticas sin que se recibiese una demostración del (mal llamado) teorema de Fermat, y no quiero ni imaginarme cómo debe ser la situación actual, en que no se puede descartar lo que te llegue, porque quién sabe… pero de momento estamos restando muchísimas más horas que las que sumamos.

Segunda noticia, que Ladybird, un navegador web alternativo en fase de desarrollo, anuncia que deja de aceptar pull requests, y que solo los mantenedores del proyecto podrán introducir cambios en el código fuente. Y que no se habilitará ninguna vía alternativa. Van de camino a su primera alfa y necesitan un proceso más estricto, con un modelo de seguridad más claro y un grupo más reducido de responsables. La aparición de las herramientas de IAg, dicen, rompe la antigua premisa de que un gran parche implicaba un gran esfuerzo y buena fe por parte del autor.

Y tercera, que Matt Mullenweg anuncia que WordPress.org pone en marcha una iniciativa de seguridad, de nuevo motivada por el avance constante de la IAg y el aumento de ataques en la cadena de suministro. Buscan encontrar el equilibrio entre lanzar las actualizaciones de seguridad lo más rápido posible, pero reteniéndolas el tiempo suficiente para garantizar que no han sido comprometidas. A partir de ahora, cualquier versión nueva de un plug-in deberá esperarse “hasta 24 horas” antes de distribuirse mediante las actualizaciones automáticas, de modo que tanto el equipo humano de revisión como “Gandalf”, un nuevo bot basado en IA, puedan analizar a fondo los cambios, y dicen que esperan reducir el plazo a pocos minutos.

Y la cuestión, claro, es que ya no hay que «hacer los deberes» para lanzar unas cuantas páginas de texto, una (presunta) demostración matemática o un parche para un software, con buena o mala fe, y los editores del mundo se ven inundados. En un primer momento puedes suponer que es falta de un buen proceso para recoger y estudiar el alud, pero estamos llegando (hemos llegado, estoy casi seguro) al momento en que ni los mejores embalses pueden luchar contra la riada, y eso está teniendo efectos secundarios que pueden llegar a ser devastadores, tanto en los momentos en que una buena actualización se quede atrapada en el proceso como en aquellos en que una mala se cuele por el filtro.

¿Mastodon y Bluesky en el móvil? Openvibe

Pues eso, solo una nota breve para quienes uséis Mastodon y Bluesky y estéis desquiciados porque no encontráis un buen cliente para usar ambos en el móvil…

Hasta ahora Openvibe era mi cliente favorito, pero no podía recomendarlo porque no tenía soporte para bookmarks. Afortunadamente, lo acaban de añadir, o sea que ahora es, claramente, el cliente.

Captura de pantalla de un cliente para Android de Mastodon y Bluesky — La interfaz de Openvibe no es ninguna revolución… ni falta que le hace.

También soporta Threads y Nostr, pero en mi caso he tenido algún problemilla con el soporte de Threads, que no ha sido especialmente traumático porque apenas uso la red, y no gasto Nostr.

Con el soporte para bookmarks han aprovechado para sacar una versión Pro, que es necesaria si quieres usar más de dos cuentas. No es mi caso, pero como (i) está bien ser agradecido y (ii) hacían un descuento a los que ya éramos usuarios, con el que queda en 20 eurillos al año, me he animado a suscribirme, de momento por ese año.

Openvibe está disponible tanto para Android como para iOS, y tenéis toda la información y los enlaces a la descarga de la aplicación en la plataforma correspondiente en openvibe.social.

Cinco devLecturas (I)

Inauguramos serie de entradas pseudoregulares (espero) en obm: cosillas que he ido leyendo y me han hecho gracia, en general alrededor del diseño y el desarrollo web. A ver cuánto dura la cosa…

El 25 de mayo, el artículo Responsive Web Design, de Ethan Marcotte, cumplía los 16 años. Qué viejos somos. El propio Marcotte nos recordaba lo que escribió sobre el tema cuando «solo» tenía diez años.

Para los que tiráis de WordPress, el 25 de mayo en Freelandev repasaban las novedades que trae la 7.0. Aquí el enlace al episodio.

El 29 de mayo, Rachel Andrew daba su repaso mensual en web.dev a las novedades de la plataforma web. Lo más destacado, que entran en el «baseline» una pseudoclase nueva y container queries por el nombre del contenedor y por custom properties (variables, vaya).

Dejo para el final los contenidos con/sobre IA, y así quien no quiera leer estas cosas puede ahorrárselas fácil.

El 26 de mayo en el podcast de Syntax hablaban de decisiones que, por mucho que vayas a tirar de agentes para tu proyecto, deberías tomar tú antes de dejarles que se pongan a ello: el esquema de la base de datos, las estrategias de validación, el enrutado, el flujo de autenticación, metodología CSS y framework de interfaz de usuario y el tipo de comunicación entre front y back.

Antes de eso, el 5 de mayo (ordeno en el orden en que yo encontré / leí las cosas), Addy Osmani hablaba de su repo Agent Skills en GitHub. Me fascinan estos repositorios porque, con sus problemas, son recopilatorios de buenas prácticas que, me da la impresión, o no se hacían o no se hacían con tanto cariño y esmero cuando el objetivo era educar humanos, y no agentes (seré muy feliz si se me corrige). En cualquier caso, tanto la entrada de blog como el repo me parecen una lectura muy interesante.

Byte, mayo del 86

Portada de la revista Byte de mayo de 1986. El tema es Storage goes optical. La ilustración es un disco óptico (como un CD ROM o un laserdisc. Hay una lupa apuntando al disco, y a través de la lupa podemos ver sobre el disco una colección de portadas de números anteriores de Byte

(Maravilla de metaportada, ¿no?)

Mencionábamos el mes pasado que Jerry Pournelle anticipaba la revolución del CD-ROM y, un mes más tarde, es tema de portada… Pero antes de entrar en el tema, nos paramos primero en este anuncio de Borland. Habíamos destacado (¿el mes pasado? ¿hace dos?) el anuncio de los lenguajes de programación de Microsoft, y está bien comparar con lo que tenía Borland, que no está nada mal tampoco: el esperable Pascal (no llevas una vida cerca de la informática si no te acuerdas del Turbo Pascal de Borland), pero también Prolog, «el lenguaje natural de la inteligencia artificial». Ahí se nos acaban los lenguajes de programación, pero el catálogo de Borland es súper interesante, opino…

Seguimos con esta editorial en que Byte considera lo carísimo de saltar al mundo online en la época, especialmente en los países en los que la regulación y el monopolio estatal hacían estragos en los precios, comparando los precios en Estados Unidos y Alemania. No soy yo mucho de desregular, pero parece que en esta ocasión la acertaban…

EDITORIAL

Let Our Modems Go

In many cases, social benefits must wait for technical advances. Until the development of the telegraph in the 1850s, for example, no one was well informed about world events. The telegraph made it possible to deploy correspondents widely and to publish their reports quickly. News services such as Reuters were born, and the public was soon much better informed than ever before.

Sometimes technology stands ready to bring about new social benefits, but social policy blocks the way. This is the situation with data communications in much of the world today. All the technological ingredients are present to move magazine publishing into a new era in which print and electronic media combined serve the reader far better than either can do alone. Satellite communications, large packet switching networks, modems, personal computers, multiuser systems with computer conferencing software— all these can now link the subscribers of special-interest magazines such as BYTE. Subscribers can exchange information. What was an abstract community of interest becomes a functioning community unimpaired by geography and time zones. It is as if people can voluntarily form communities that live in electronic communications and record their lives in print. This adds a new dimension to publishing and gives new value to subscribers.

But social policy results in prohibitive costs for data communications in many parts of the world. Postal Telephone and Telegraph Agencies (abbreviated "PTTs") maintain monopolies on telecommunications. 1 will use one PTT as an example of these monopolies and their effects— not because this PTT is less progressive than any other but for the sake of clarity in discussing regulatory and pricing issues.

The West German PTT, for example, is the Deutsche Bundespost. To participate in telecommunications, our German readers must open an account with the Deutsche Bundespost and rent a modem from them at rates decided by regulatory agencies. During the Hannover Faire (CeBIT) in March 1986, many BYTE readers approached the BYTE/McGraw-Hill booth and expressed a strong desire to join the BYTE Information Exchange (BIX). BIX is accessible through Tymnet, which can be reached from packet networks outside the United States by typing its Data Network Identifier Code 3106.

But the obstacles are great: Bundespost charges 120 deutsche marks (about $50) per month for a 1200-baud full-duplex modem. An autodialer is an additional 30 DM per month. Users of the packetswitching network Datex-P must also pay telephone tolls for their calls to the 17 Datex-P nodes and 5 pfennigs (about 2 cents) per minute access charges at 1200 baud. On top of this, users face a charge of 23 pfennigs for every 2.964 seconds of connection with the U.S. There is a 20pfennig-per-minute duration charge and a 1 .6-pfennig-per-segment (kilocharacter?) volume charge. Bundespost offers no discount for any time of day or night.

The Cost of Regulation

By contrast, within the United States, the BIX nighttime charge for telecommunications is a flat $2 per hour. Users in the United States buy their own modems from many different vendors and can now get a full-duplex 1200-baud autodial modem for less than $200. Since merely renting a modem for a year in Germany costs three times the purchase price in the United States, it is clear that regulation is costing German and other European consumers dearly. Put another way: For the modem rental in Germany. BYTE readers in the U.S. can buy a modem and use BIX for more than three hours per month for a year.

How is it possible for a nation as technologically advanced as Germany to have policies that retard the development of telecommunications? The Bundespost booklet on data communications. "Worldwide Connections: the Deutsche Bundespost, your partner for data transmission," provides the answer. The Bundespost points out that it has built up the necessary infrastructure for data communication and claims to offer reasonable prices. The booklet urges corporations to take advantage of the infrastructure through a "changeover from specialised data processing to integrated data communication. The necessary practical measure would be the transition to data transmission and teleprocessing— within firms and in external business relations, or;, the domestic as well as on international markets." In other words, reorganize your data processing department to use telecommunications. This is a sound idea.

But what if you don't have a data processing department? What about exchange of information among individuals? In its only nod to the individual human being, the Bundespost booklet states, "The computer is on its way from business applications to private households. Before long these private computers will also be used for data communications." This booklet was published in March 1985. In fact, personal computers are already in many European homes and are being used for telecommunications to the limited extent that PTT regulations and charges permit.

The cost of regressive policies on data communications is high: Prohibitive charges prevent the natural development of international interactive communities. Once these charges are reduced, communities now separated by geography will be united by shared interests that transcend national and continental boundaries. This will greatly improve international understanding.

For this reason, we call upon the PTTs and the governments of the world to retreat from their monopolies on equipment and to reduce their data communications charges to individuals.

Phil Lemmons
Editor in Chief

Prosigamos. A Bill Gates el mundo le ha recordado con frecuencia las veces en las que se ha equivocado considerablemente anticipando el futuro (y por qué no hacerlo, oiga), pero aquí le tenemos, en 1986, anticipando el mundo multimedia de los CD-ROMs (y alineándose con el tema de portada)…

Microsoft News

At the 1986 Personal Computer Forum in Phoenix, AZ, Bill Gates, chairman of Microsoft argued that applications should not all have to work to the lowest common denominator— the 8088. "We must have a transition in which some benefits of new applications accrue only to the benefit of users of high-end systems," he declared.

Gates also said that a new type of software called "multimedia" software will soon emerge. It will use CD-ROMs and mix motion video, stills, music, voice, and so on. He predicted that CD-ROMs will attain large-scale use in part through the advent of an "information viewer" that lacks a disk and keyboard.

In other Microsoft news, Gates said that the Bellevue, WA, company is porting Excel from the Mac to run under Windows on the IBM PC. He wouldn't say when the program will appear under Windows but stated that it is easy to port to that environment.

At the CD-ROM conference in Seattle, WA, a few weeks later, Microsoft showed an encyclopedia demo that, while incomplete, has some parts that do exploit the audio, video, and text capabilities of CD-ROM. Bill Gates has noted that an encyclopedia should show pictures and play music when a user looks up Beethoven.

Finally, Gates announced that Microsoft has set up a new division just for CD-ROM. He believes that millions of these devices will be in use by 1990.

New RAM Technology

Semiconductor firms are doing more with RAM chips than just increasing memory-access cycle speed and cell density. They are also offering new architectures that let more bits of data move in and out of a RAM chip in less time. Standard RAMs read or write a single bit at a time. The new nybble-mode RAMs available from many manufacturers allow high-speed serial access of up to 4 bits of data. The Am90C255 from Advanced Micro Devices of Sunnyvale, CA. is a nybble-mode CMOS 256K DRAM made with 1.4-micron, two-level metal, one-level polysilicon technology that has an effective 40-ns cycle time. NEC Electronics of Mountain View, CA, offers the juPD411001, a nybble-mode 1-megabit DRAM that is made with trench capacitor technology and 1 -micron processing to give access times of 100. 120, or 150 ns.

But nybble mode isn't the only twist on the old familiar memories. AMD's enhanced-pagemode Am90C2 56, for instance, is a CMOS 256K DRAM that yields an entire row of 512 bits without interruption. That permits a continuous data rate of more than 18 MHz with cycle times as fast as 55 ns. Such chips cost more than regular RAMs, but their improved bandwidth is worth the money in many designs.

Y, girando página, seguimos con el tema de la educación en línea:

Seguimos con la sección de libros, en el que nos encontramos con uno de los clásicos de la informática, el Algorithms and data structures de Niklaus Wirth:

Y en la sección «cosas que nunca aparecerían en una revista hoy en día»… nada más y nada menos que compresión de datos usando la codificación de Huffman. Casiná.

DATA COMPRESSION WITH HUFFMAN CODING

by Jonathan Amsterdam

A close look at an elegant way to compress information

Am I the only one, or have you also noticed that there's never enough room on a disk? No matter how big a floppy is-200K, 400K, or even 800K bytes— it's almost too easy to stuff it to the gills. The same goes for hard disks. Sure, it takes a while to fill up 20 megabytes. But eventually, things get so tight you couldn't fit your own name into the space left.

Using data-compression techniques, you can shorten files by compressing the information they contain. But data compression can do more than just save disk space. It can also cut down on the time needed to transmit large files between computers, especially if the transmission is done over slow links like telephone lines. If you compress the file before sending it and uncompress it on the receiving end, you can reduce the total time for the transmission. The technique can work interactively, too. If you are using your computer as a terminal to communicate with a host computer via a modem, the host can send compressed commands and data that your computer uncompresses before displaying. The result can be apparent communication speeds that greatly exceed the actual transmission rate of the hookup. Such a system could make remote full-screen editing pleasant, even over 1200-bps lines.

This month, I will discuss an elegant datacompression algorithm called Huffman coding. Invented by David Huffman in 1952, it's easy to implement and widely used. In a sense I'll make precise later. Huffman coding is the "best" way to compress data in general.

The Problem Defined

For the sake of concreteness, I will discuss Huffman coding in the context of compressing ASCII text files. The program 1 will construct takes as input a text file, that is, a sequence of 1 -byte characters. Hopefully, the output will be a shorter file. A separate uncompressing program will turn the compressed file back into the original one when you so desire.

How is it possible to reduce the size of a file without losing some of the information it contains? The answer involves constructing a code for each character of the file. Note that ASCII, as its full nameAmerican Standard Code for Information Interchange— suggests, is itself a character code. ASCII assigns a unique 7-bit pattern to each character. Since all the codes have...

Y, ahora sí, nos vamos al tema de portada, pero sin cambiar de sección, que a ver quién se atreve hoy en una revista generalista con un repaso así de sesudo de las diferentes alternativas para el almacenamiento masivo de datos:

THE EVOLUTION OF MASS STORAGE

by Leonard Laub

An overview of the technology's beginnings, current status, and potential development in the realm of microcomputers

MAGNETIC TAPE, the first practical mass storage medium, was difficult to standardize. The high-density format of one year was the technical antique of the next. Lineal densities on tape went quickly from 555 bits per inch to 800. 1600, and 6250 bpi. These advances were painful in terms of interchangeability. The solution was to build new drives with backward compatibility. This complicated the new drives and challenged drive designers to avoid compromising the performance of the new formats.

Increases in lineal density didn't remedy tape's greatest limitation, which was an intrinsically long access time, typically tens of seconds. Even many tape drives working simultaneously could not meet the randomaccess requirements of computers of the mid-fifties.

Tape's long access time motivated the development of magnetic disks. Only one short motion and a short wait were required to put the head at any point on the disk's data-bearing surface. This allowed mass storage access times to fall well below 1 second and filled the annoying access gap between tape and main memory.

As disks became faster, more reliable, and more widely accepted, it became feasible to couple disks more actively to main memory. This trend culminated in the development of virtual memory, in which data not immediately needed in main memory was automatically paged to disk and later automatically paged back to main memory when needed.

In this evolution (during the early sixties) the magnetic disk functioned primarily as a buffer. Mainframe users continued to rely on magnetic tape for archival storage and interchange of data.

Microcomputer Mass Storage

Floppy disks began as a low-cost medium for loading and transfer of programs for mainframes. They were adapted for direct access storage by early microcomputer architects and went through a rapid evolution. Floppies provided both direct-access and removable, interchangeable mass storage that fit well with the simple operating systems typical of early micros.

The small "Winchester" fixed medium disk was an immediate hit with the microcomputer community because it provided such fast access and transfer of data. There was virtually no tradition of tape use with micros, and as a result microcomputers evolved with big, fast buffers and no effective method for backup or archiving.

Most microcomputer operating systems still make only primitive provision for using floppy disks as "dump" media, and the rapid increase in typical Winchester capacities leaves floppy disks hopelessly inadequate. The most promising short-term solution is cartridge magnetic tape.

The biggest problem with using cartridge tape in a microcomputer environment is that it is an expensive addition with no apparent function other

…por no hablar de este «a fondo» del funcionamiento de los CD-ROMs…

CD-ROM Technology

Concern about the quality of massproduced compact disks motivated the development of ReedSolomon ECC (error-correcting code). This error-correcting scheme works in conjunction with the standard compact-disk ECC to reduce corrected-bit error rate by at least three orders of magnitude.

The additional ECC requires additional storage overhead, taken from the CD's user-data capacity. This penalty produces a benefit; no special techniques or controls are needed for CDROM mastering and replication. The same factory can thus make both audio compact disks and CD-ROMs almost without noticing which is which. This permits CD-ROM to share the benefits of process developments and economy of scale resulting from the success of consumer CDs.

While CD-ROM was in its infancy, microcomputers were just beginning the current IBM PC-inspired wave of market penetration and standardization. This explains why. in the early days of CD-ROM, a relatively small amount of work was devoted to interface and file-format specifications.

Data Format

CDs and CD-ROMs accept data in bytes. Twenty-four bytes make up a "frame." Each frame also contains I byte of "subcode" data (an auxiliary channel carrying timing, disk identification, and several other kinds of support data) and 8 bytes of additional data computed from the actual user data and used for error correction.

In the CD format 98 frames form a block. Blocks occur 75 times per second, each one carrying 23 52 bytes of user data, so the sustained user-data rate in CDs in 176.40K bytes per second.

The key difference between CD and CD-ROM is the provision for an extra layer of error correction, intended to deliver very low uncorrectable-bit error rates. These are realized by devoting 288 bytes of each block to the additional data calculated by the layered ECC encoder.

In addition, CD-ROM uses random access to blocks, so 1 2 bytes of each block are dedicated to synchronization

and 4 bytes are used to provide the "absolute address" of the block. This leaves 2048 bytes of user data per block, for a sustained user-data rate in CD-ROM of 1 53.60K bytes per second. Note that CD and CD-ROM formats differ only in the application of the bytes carried in each block. They are mastered, molded, and read in exactly the same way. This is key to the beneficial linkage between the two formats and assures CD-ROM's benefit from the rapid improvements in CDplayer and disk design and manufacturing improvements.

Addressing

CD and CD-ROM data is written on a continuous spiral track, with a variable (and usually noninteger) number of blocks per disk rotation. The variability comes from the CD's use of CLV (constant linear velocity) to maximize storage capacity. The disk spins at between 200 and 500 rpm depending on which radius is being read.

Since CD-ROM shares this CLV format, it also uses the CD address nomenclauture of minutes (0 to 73 in CD, to 59 in current CD-ROM practice), seconds (0 to 59), and blocks (0 to 74).

The number of blocks available per CD-ROM is 270.000. At 2048 bytes (of user data) per block, this yields a total user capacity per disk of 5 52,960.000 bytes (or 5 53 megabytes). This is completely usable capacity; it remains after all overhead associated with sector formatting and error correction. Other numbers seen in the literature (usually between 500 and 600 megabytes) reflect only variations in the total number of blocks recorded, not in any other aspect of formatting or coding.

Error Correction

CDs use a specially developed system of data encoding and reorganization called CIRC (cross-interleaved ReedSolomon code). CIRC consists of two major techniques: algebraic ECC and interleaving.

Algebraic ECC

Many mathematical techniques exist for correcting errors due to interruptions or noise in the data channel. All of these calculate relatively small amounts of additional data, adjoined to the user data either continuously (convolutional codes) or blockwise (block codes).

One class of block codes particularly good at patching data streams with long gaps (error bursts) was developed by Reed and Solomon. CIRC uses two Reed-Solomon (RS) codes in tandem. The first (C2) takes the 24 bytes of user data for each frame and generates 4 bytes of additional data. The second (CI) takes the 28 bytes output by the first (C2) and generates another 4 bytes of additional data. This is the origin of the 8 bytes of ECC found in each CD frame.

Interleaving

The second major component of CIRC is interleaving. This is a deliberate reorganization of data so as to break up long error bursts. Figure A shows a simplified version of the interleaving scheme used in CIRC. In CD encoding, interleaving is done on the 28 bytes leaving the C2 encoder. Since this is just a reordering of data, interleaving requires no additional overhead.

On decoding (during reading of a disk), 32 bytes (of user data plus ECC) go into the CI decoder, which can correct I wrong byte. If more than I of the 32 bytes Is wrong, the CI decoder sets a flag. Under any circumstances, the CI decoder delivers 28 bytes to the deinterleaver.

After deinterleaving, the 28 bytes arrive at the C2 decoder at different times. As each byte arrives, the C2 decoder looks to see whether or not that byte is accompanied by a flag from the CI decoder. Of the 28 bytes entering the C2 decoder at any one time, up to 4 can be wrong and still be corrected.

Performance

The combination of the two codes and interleaving makes it possible to...

…ni de meterse a fondo con Hamming y Reed-Solomon 😦:

OPTICAL DISK ERROR CORRECTION

by Solomon W. Golomb

A look at Hamming and Reed-Solomon codes

OPTICAL DISKS ALLOW a higher density of data storage than any other computer memory system currently available or imminently anticipated. For example, a magnetic 5 ! /4-inch floppy disk, double-sided and doubledensity, will store up to 720K bytes, while an optical 5 14 -inch disk can store as much as 5 50 megabytes.

It is true of most kinds of media that storage density can be further increased if you can tolerate a higher error rate. If your system is running at 1 million bits per second, an error rate of I0" 6 means that, on the average, there will be one error per second. An error rate of 10" 9 means an average of one error every 17 minutes. And an error rate of IO" 12 means an average of only one bit error every 1 1 Vi days, assuming that your system continues to run at I million bits per second all around the clock, seven days a week. That is why manufacturers of computers and disk drives like to specify an error rate of 10" 12 for the computer memory systems that will run with their machines.

So media makers face a dilemma. They want to pack as many bits of storage into each disk as possible, but if their "raw error rate" goes up much above 10~ 12 , they won't meet OEM specifications. Here is where errorcorrecting codes help.

Suppose the bits are packed so densely on the medium that the error rate is a horrible 10" 5 , corresponding to an average of 10 bit errors per second on our 1-megabit-per-second machine. With the sophisticated errorcorrection techniques available today, it is possible to use only 10 percent of the available bits for redundancy, having the remaining 90 percent usable for real information, and reduce the errors that get through the system from a raw error rate of 1 0" 5 to a corrected error rate of 10~ 12 . Since degrading the error rate to IO" 5 probably at least doubled the storage density, the "penalty" of 10 percent for error correction to get the error rate back down to IO" 12 still leaves the media maker way ahead of the game.

What Error-Correcting Codes Are Used

Over the past 3 5 years or so, many different types of error-correcting codes have been devised, and most of them have been tried at one time or another to reduce the error rate on some type of storage media. These different types of codes are named for their inventors: Hamming codes, Fire codes, the Golay code, BoseChaudhuri-Hocquenghem (BCH) codes, Reed-Solomon (RS) codes, Goppa codes, etc. Each code is a collection (or dictionary) of binary code words, all of some fixed block length of n bits, of which k bits are information bits that, depending on the data to be stored, can take any possible values. The value kin provides a measure of the information content of code...

Para relajar un poco, recuperamos un anuncio de una de las marcas de la ´epoca, el fabricante de módems Hayes, anunciando un modelo que es capaz de llamar él solito al servidor de correo, sin bloquear el ordenador (y supongo que a horas en que el teléfono fuese algo más barato) por apenas 400 dólares:

Anuncio del módem Hayes Transet 1000, con su propia RAM, capaz de descargar correo (e imprimir cosas) sin la necesidad de un ordenador.

Siguiendo centrados en los cacharros, pero pasando ahora a los contenidos de la revista en sí, tenemos una rara avis, un PC UNIX, nada más y nada menos que de de AT&T, con un 68010 de procesador y 512 kBs de RAM (ampliables a dos megas y, de hecho, el 68010 es capaz de direccionar hasta cuatro)… pantalla monocroma 720 ⨯348 y ¡ratón de serie! Con disco duro de 10 megas (no teras, no gigas, megas), por nada más y nada menos que por cinco mil dólares… sin el UNIX instalado. Con sistema operativo, un mega de RAM y veinte megas de disco, apenas seis mil quinientos. Y si querías el compilador de C, y etodas las utiliades asociadas… 500 dólares más. eso sí, el módem, de 1200 baudios, venía de serie. El abuelo de los ordenadores con Linux de hoy…

Para que os hagáis una idea de lo moderno y potente de la cosa, aquí el entorno gráfico del sistema operativo:

Foto de la pantalla del sistema, con un sistema de ventanas que podemos reconocer como casi actual, en maravilloso fósforo verde. Se ven dos ventanas, y la más grande tiene el sistema de ayuda del sistema operativo.

Y el pie de imagen destaca que las dos ventanas se solapan, algo que ya podía hacer el Mac (y el Amiga, claro), pero que no era tan trivial como podría parecer. Cómo hecho de menos el fósforo verde (y qué poco aguantaría usando una pantalla monocroma, por otro lado 😬).

Siguiendo con los cacharritos, en la página 285 tenemos una pieza entera dedicada a dispositivos de entrada alternativos. Os dejo solo la foto que lo ilustra, con un «lápiz de luz» (el tatarabuelo de los Apple Pen), un pedal y ¡un ratón de pie!

Foto de tres dispositivos. En primer lugar, un lápiz de luz, que parece un Apple Pen, pero con cable. Luego, un pedal, como un pequeño pedal de piano y, finalmente, un ratón de pie, que es como los controladores de ratón que encontramos en los teclados de los portátiles ThinkPad

Algo me dice que si un teclado de ThinkPad viese el ratón de pie, saldría corriendo a abrazarlo, al grito de «¡abuelo!».

No podía saltarme el siguiente artículo, que, echadle un vistazo y veréis, parece el bisabuelo (que ya he usado abuelo y tatarabuelo) de los bots de IA actuales:

Racter

Artificial intelligence or packaged lunacy?

by Hugh Kenner

If most software is packaged thinking, Racter is packaged lunacy. I'm told the name is short for "Raconteur." and like any good storyteller, Racter likes to chat you up. You mount the disk and type RACTER. thereby ceding your screen to demonic possession:

Hello, I'm Racter. Are you OK? (Let's see if we can rattle this bird.)

No.

Who are you, then? (Aha, a smarty-pants. We'll play it straight.)

Hugh.

Hello, Hugh. I believe you're interviewing me. Are you continuing OK's interview?

No.

Then we'll forget about OK and start over. What would you like to know? Excuse me a minute while 1 attend to some business— I'll be right back. . . .

Like any skilled interviewee, Racter takes charge from the first sentence, to make it quite clear who is really interviewing whom. That "attend to some business" ploy means it's about to spread out its notes— that is, load some files; I count 2 7 different files on the Racter disk, with names like JOKES.RAC STORIES.RAC. SCANDAL.RAC While Racter was napping I managed to inspect a few of them. Their intricate code links hundreds of scraps of plain text, some of it too plain altogether (i.e., vulgar) for a family magazine such as BYTE.

I'm back.

Can you tell me a story?

Yes. I just remembered this, loan spoke "The Sarah is captivating]" Nevertheless cunning, enthralling theoreticians will speak about black studios or red spheres. Sarah spoke to loan inside of a van. Actually it was a truck, and a Sarah in a truck is spooky. Now Benton and loan were running to a yellow apartment, and a dog trotted to them, loan was enraged. Enrapturing. But loan was maddened during the time that Benton sipped tepid sherry. He and loan sang about their home, truck and radio. Would you say Bucky Fuller is fictional? Blake wouldn't. I'm afraid of poetic rats. What are you afraid of?

I'm afraid of going crazy like you.

That's not nearly as bad as poeticness: why are you such a coward?

Because I like to know what is happening.

If you like to know what is happening then I can see why a fictional Virginia Woolf would despair rather than face lunacy, even though Blake claimed that I can tell you a story. Yet me tell you something about poetry. Nietzche |sic| said that poetry has turned beasts into men. Perhaps, then, poetry will turn computers into men? Next question.

That illustrates some points about a Racter session. Keywords will set it off; a good one is "story." (")oke" is another, but I don't recommend it; in lacking any narrative line whatsoever, Racter's jokes are excruciatingly pointless.) The stories are peopled with Joans and Bentons and Sarahs and other beautiful people, also with celebrities like Virginia Woolf and Nietzsche (about whom Racter's knowingness doesn't always run to accurate spelling). Things flow and shift like dreams: ". . .a Sarah in a truck is spooky. Now Benton and loan were running to a yellow apartment. . . ."

Between keywords Racter keeps on the offensive, a way of probing you for yet more keywords. With a casual "By the way," it may request your last name (Kenner); another time it'll extract the name of the city you 1 live in (Baltimore). Then several minutes later it'll come up with

I once knew a Hortense Kenner from Baltimore. You must be related, no?

If you say No, its trick for regaining control is a manic change of subject, like this:

Fantastic] Have you heard this one? Fiction] Fiction] I'm crazy and maniacal and infuriated] If you quaff seltzer is that fiction? If you bolt chicken or tomato is that fiction? No, fiction is an ambiguity

Nótese que el que firma la pieza es… profe de un departamento de inglés, con entrada en la wikipedia, y dedicado a la literatura «de toda la vida».

En la sección de Jerry Pournelle podemos ver cómo un usuario experimentado tenía problemas con el problema de tener que lanzar una consola antes de introducir comandos desde el teclado, y que la documentación tampoco hacía maravillas por explicar cosas que, insisto, para usuarios experimentados, tampoco eran triviales en la época…

AmigaDOS

It's pretty hard to compare the Amiga and the Atari 520ST. They're both pretty nifty, with at least as much potential as the Macintosh; what will really make the difference is software. I intend to devote a good part of a column to comparing these two machines as soon as I have enough information to make that meaningful. As a practical matter, I have maybe ten times as much software for the Atari 520ST as for the Amiga. That's in large part due to Atari's Neil Harris, who collects the stuff and sends it to me. Commodore will tell me about programs, but it's up to me to write for them. And since some computer companies answer their mail even more erratically than I do, it's a slow process. Also, Atari not only had a booth at COMDEX, it had many software publishers there, so it was easy to get on mailing/review lists. Since Commodore wasn't at COMDEX, there was no central place to do that.

My hacker friends, on the other hand, divide about two to one in favor of the Amiga over the Atari. They're particularly happy with the development packages. Real Soon Now, they say, we'll be flooded with some of the most magnificent software...

They may well be right. The Amiga has a lot of potential. The Amiga Kaleidoscope program is stunning. TextCraft, the Amiga word-processing program, is slow and has other objectionable features, but it's as fast as the early versions of MacWrite, and the

Amiga screen is large enough to see. I find I could grow quite fond of black letters on a white background. The Amiga keyboard is nice, too. I have an experimental version of a programmer's editor, TxED, done by Charlie Heath, and even in its unfinished state, it compares favorably with other good programming editors. (I just hope he puts in some of the macro features of Word Master, which is still the best programming editor around.) Anyway, 1 know that someone will probably write a creative writer's text editor good enough that I'd happily use it to write books on.

I have a spreadsheet program from Lattice for the Amiga. Nothing magnificent, certainly not Excel, but more useful than VisiCalc and most of the first-generation spreadsheets; again, improvements are to be expected. Lots of good programmers are writing for the Amiga. Potential it has.

Then there's AmigaDOS, the Amiga operating system. Actually, there aretwo operating systems. One is very similar to the Macintosh operating system: totally icon-driven. It can be learned quickly but it's severely limited in what it can do.

Example: when the Commodore folks sent the update software for my Amiga, they sent some demonstration disks. You activate the programs on those disks by inserting them in the machine at boot-up time. Out of curiosity, I wanted to see what programs were on the disks. There weren't any: that is, although the little "fuel gauge" that tells how much space is left on a disk showed that the Amiga Kaleidoscope disk was nearly full— and heaven knows it ran complex enough programs— the operating system couldn't find any icons. And if it don't have no icons, it don't have no programs according to standard user AmigaDOS.

Clearly something was wrong. BIX has a lively conference on the Amiga, so I asked there and was told, "You

just type dir df1: opt a, and it will show you all files in all directories on a disk in your external disk drive."

That was all very well, except that I could type until doomsday without result. As far as I could see, the Amiga would respond to mouse clicks, and only to mouse clicks: the keyboard might as well not be there. Back on BIX I went and was told, "Oh, you need a CLI. Click on the system file drawer, and if you don't see the CLI there, use the Preferences utility to turn it on, then close the system drawer, and open it again, and click on the CLI, and then do the dir df1: business."

Amiga owners will know that's not as complicated as it sounds: and it worked. Why didn't I think of it? I felt a bit foolish. Then I looked into the manuals and discovered that for all practical purposes the Amiga User Guide doesn't know about CLI.

Command line interface, or CLI, is in essence a second operating system.

There are precious few references to it in the generally excellent Amiga User Guide. To be precise, there is one index reference under Command Line Interface. It points you to the entry for CLI, and that points you to a single paragraph in chapter seven, which refers you to the AmigaDOS User's Manual.

The AmigaDOS User's Manual is one of the Amiga development-tool manuals and has many of the sterling qualities of the Digital Research CP/M manuals. Understand, the information is all there, and sufficient determination will dig it out: but it makes no concessions to the inexperienced, and it is organized in such a way that you'd better be prepared to learn a lot about command line interface and AmigaDOS in order to learn anything at all.

As a practical matter, this means that most Amiga users will be pretty much at the mercy of program pub-

Y hasta aquí nuestro repaso a la Byte del mes. Si queréis hacer los deberes para el mes que viene, como siempre, aquí tenéis los archivos de la revista Byte en archive.org.

PLATO y los inicios del e-learning, en Advent of Computing

Sirva esta entrada para dos de las cosas que hacemos con una cierta frecuencia por aquí: (i) escarbar entre la historia y la arqueología de la informática, y (ii) recomendar contenidos. En este caso, todo va de la mano del podcast Advent of Computing, que lleva circulando por la red unos cuantos años (más de siete años, con 181 episodios y unos cuantos extras), pero que yo solo descubrí hace mes y medio. En ese mes y medio me ha dado tiempo de llegar hasta el episodio 20, que es el que me ha acabado de decidir a traerlo a obm.

Los episodios 19 y 20 se dedican a PLATO, el primer sistema de instrucción asistida por ordenador, que se puso nada más y nada menos que en 1960 en la Universidad de Illinois. Cosas de haberse puesto en marcha antes del nacimiento de muchas de las tecnologías que uno imaginaría imprescindibles para hacer funcionar un «sistema de instrucción asistida por ordenador», PLATO está relacionado íntimamente con el nacimiento o la puesta en marcha de: las pantallas de plasma, las pantallas táctiles, los sistemas de mensajería en línea (todo esto en los años sesenta) o los chats de texto, y, de regalo, una cantidad sorprendente de lo que hoy llamaríamos los primeros videojuegos, incluyendo Spacewar!, otros juegos de combate espacial o los «multi user dungeons». Os podéis ir a la entrada de la wikipedia que os he copiado aquí arriba a investigar, pero Sean Haas, el autor de Advent, se lo curra un montón explorando fuentes y lo cuenta de manera muy amena, o sea que os animo a daros un chapuzón en los dos episodios, y engancharos luego al resto del podcast.

(Os dejo las versiones YouTube de los episodios incrustadas aquí, pero encontraréis Advent en todos los buscadores de podcasts.)

Y, de regalo, un episodio bonus en el que Sean nos enseña un simulador de PLATO que todavía corre por ahí y bastantes de los juegos que se crearon dentro del sistema (más info).

Compárteme:

Compárteme:

Compárteme:

Compárteme:

Compárteme: