Temas de investigación

Inquietudes y problemas que tengo con la informática, y que me gustaría ver resueltos.

No lo tomes muy en serio; es sólo la sección de utopías dentro de mi lista de cosas por hacer.

Desde marzo-06, actualizado (aunque poco) hasta 20.m03.2023; en 2017 esta página necesita una gran ampliación y organización, y un mejor sistema de hipertexto. Daniel Clemente Laboreo (web, correo). Este fichero .html se ve mejor abriendo el .org con org-mode (Emacs)

Otras listas: Índice (varias tareas) Temas de investigación (tareas mayores) Emacs Bazaar Conkeror Sobre este sistema (y org-mode)


Índice


1. Sobre esta lista de temas

Aquí recopilo descripciones de problemas que alguna vez he querido ver corregidos, todos del área de la informática/computación. Creo que pueden servir como temas para trabajos de investigación porque son largos y complicados de resolver, y requieren pensar y tomar decisiones. A la vez son problemas reales que estaría bien solucionar, así que un trabajo sobre estos temas será algo útil y apreciado.

De vez en cuando me escriben para preguntarme ideas para trabajos. Pues es bien sencillo: busca problemas en el mundo, y propónte corregirlos. De problemas hay muchos: de educación, de ética (los peores), économicos, científicos, … Si no se te ocurren… bueno, pues para eso hay gente que publica sus listas de problemas por resolver… :-)

Y si quieres un trabajo con utilidad práctica real: elige un programa libre y de desarrollo abierto, entra en su base de datos de errores, y elige varios para corregir (idealmente los más solicitados). En serio, sería muy bonito un trabajo final (de Bachillerato, universidad, …) como «Corrección de 20 fallos importantes de OpenOffice». O Ubuntu. O GNU. O gcc. Etc.

2. Arreglar Wikipedia

Quiero:

  • Sistema fácil para revertir cambios. Ahora es manual y es difícil comprobar que se está haciendo bien.
  • Uso fácil de metainformación; ya hay bastantes proyectos sobre esto (ej. en univ. Karlsruhe), pero hace falta que se empiecen a usar. Por ej., este problema se puede solucionar así.
  • Un solo índice de relaciones entre idiomas.
  • Etiquetado de versiones de una página, para permitir crear un subconjunto de Wikipedia mediante una lista; no de páginas, sino de versiones de páginas. Así es fácil hacer una versión estable, con versiones fijas de las páginas. También facilitaría descargar una versión reducida; sólo hay que tener la lista de versiones de páginas.
  • Introducir la idea de progreso: un número que diga cómo de acabada está una página. También se tiene que poder apuntar qué es lo que falta en cada página.
  • Aclarar si se puede usar anónimamente o no: no obliga a registrarse, pero tampoco ha sido capaz de funcionar con usuarios anónimos (ver lío entre Tor y Wikipedia). Investigar.
  • Programa libre que haga de interfaz a Wikipedia, para evitar tener que usar un navegador web. Con ncurses, y quizás usando unas bibliotecas de Python que ya hay hechas. O integrable en Emacs

Desde <25.m03.2006>

3. Interfaces estables

Los controladores (módulos) que se hacen para una versión de Linux no sirven para la siguiente; hay que adaptarlos, o, como mínimo, recompilarlos. Muchos sugieren hacer una interfaz estándar para esto (una API): si todos la cumplieran, se evitarían algunos problemas. Pero los expertos creen que esto es malo (ver discusión), y probablemente tengan razón.

Lo mismo pasa con Firefox; con cada actualización dejan de funcionar las extensiones.

Estaría bien investigar el tema de las interfaces estables: cuándo son buenas, cuándo no, qué consecuencias éticas y técnicas traen, utilidad en proyectos de software libre, etc.

Apuntado el <25.m03.2006>

4. Lenguajes de marcas

Pensar en un sistema universal para convertir la sintaxis usada por wikis y otros lenguajes de marcas sencillos (como txt2tags), de forma que se pueda convertir de cualquiera a cualquiera. Quizás hace falta diseñar un formato de intercambio para representar la gramática de cada lenguaje. Puede ir bien hacerlo en XML.

Apuntado el <15.m12.2006>

5. Distribuciones de teclado

Un buen análisis sobre cuáles hay, grupos en las que se clasifican, diferentes necesidades en el mundo, estadísticas de letras más usadas para cada idioma, … para acabar construyendo "la mejor" para cada necesidad, de forma justificada.

Incluir tutoriales sobre cómo crearse la propia en Linux, tanto para X como para consola.

Desde <25.m03.2006>

5.1. toca analizar los errores comunes que se hacen al escribir

Yo una vez me detecté éstos:

  • cambiar vocales (esto en Dvorak, porque están juntas)
  • acentuar varias letras seguidas (en mi teclado)
  • poner letra con y sin acento: máas, etc. O eñne
  • duplicar consonante equivocada (Bolle en vez de Boole, etc.)
  • añadir más vocales de las necesariaas
  • equivocarme con símbolos porque en cada modelo de teclado los tengo en un sitio
  • ninguna de las anteriores :-)

Quizás iría bien saber cuáles son los errores de tecleo más comunes, para intentar evitarlos al crear una distribución de teclado.

Desde <21.m03.2010>

5.2. Cómo hacerse distribución de teclado compleja en GNU/Linux

Hay muchas funcionalidades que se le piden a una distribución de teclado:

  • diferentes alfabetos, conmutables: ahora escribo en ruso, ahora en español, ahora en griego
  • teclas modificadoras crean varias combinaciones para cada tecla; además en cada plano (alfabeto) pueden ser otras
  • hay diferentes métodos de entrada; ej. para chino; cada uno muy complejo y que necesita tecnologías aparte
  • ha de funcionar en diferentes teclados, por eso hay que tener en cuenta:
    • los códigos de tecla cambian
    • hay combinaciones de 3 y 4 teclas que no son posibles en teclados baratos
    • no es lo mismo apretar A+B+C y soltarlas que B+A+C y soltarlas
  • hay implicidas tecnologías muy complejas de configurar (XKB) que deberían ser más sencillas y mejor documentadas
  • la creación de este mapa de teclado ha de ser sencilla

Se puede hacer un análisis muy extenso de todo esto, y mejorar muchas cosas. Un trabajo de investigación podría tener dos partes: preparación de la infraestructura para definición de teclado cómoda en GNU/Linux y luego Creación de una distribución de teclado cómoda, potente y razonada.

Yo llevo peleándome con esto desde hace años; avísame si te interesa.

Desde <21.m03.2010>.

6. Unicode

6.1. Guía para cambiar a Unicode (para usuarios)

Dar instrucciones para configurar un Linux completamente para que use Unicode, en cualquier escenario:

  • en la terminal (Ctrl+Alt+F1, etc.)
  • en xterm (explicar diferencia entre xterm y uxterm)
  • en el sistema de ficheros
  • al grabar un CD
  • en el navegador web cuando abre páginas locales y remotas
  • etc.

Y explicar cómo convivir con el resto de codificaciones una vez que usemos Unicode.

<21.m04.2006>

6.2. Guía para cambiar a Unicode (para programadores)

Buscar programas (ej. en el repositorio de Debian) que aún no funcionen bien con Unicode. Arreglarlos, y por el camino crear un documento explicando cómo se hace y qué problemas da la transición, para que sea más fácil arreglar el resto.

<25.m03.2006>

6.3. Unicode en Internet

Hacer una guía que facilite la transición a Unicode, pero estudiando los problemas que da en Internet:

  • codificaciones de caracteres (definidas en varios sitios),
  • navegadores en los que va y en los que no,
  • HTML o XHTML, diferencias en cuanto a codificaciones
  • servidores web en los que se puede configurar Unicode
  • etc.

También hay que hablar de los nuevos problemas que da Unicode, y cómo evitarlos (ej: letras parecidas, o tipos de letra no disponibles del todo).

Además irá bien pensar cómo se escribe en Unicode, qué editores web permiten incluir cualquier carácter, o dónde encontrar grandes tablas para copiar+pegar caracteres de forma fácil al hacer una web.

<25.m03.2006>

6.4. Unicode en LaTeX y LyX

Hice un trabajo con LyX en el que quería escribir en varios idiomas con varias codificaciones (como árabe, griego, japonés y catalán), todo mezclado. Tuve que abandonar esa idea porque LyX no permite usar Unicode, y eso es debido a que LaTeX también tiene algún problema con codificaciones de más de 256 caracteres, creo.

Me gustaría que Unicode funcione en LaTeX, pero en un solo LaTeX; no entiendo por qué hay que hacer versión para CJK (chino/japonés/koreano) y otra para el resto. Después, que se pueda usar en LyX.

Por cierto, al final mezclé idiomas a base de chapuzas; el trabajo (y código) está en: Lógica y lenguajes.

<21.m04.2006>. <21.m03.2010>: toca revisar

7. Programas que faltan

7.1. Reparación de ficheros comprimidos

Quiero un programa (que sea software libre) que permita extraer los ficheros de un archivo ZIP dañado (uno que no se abre con los programas normales).

Y lo mismo, para otros algoritmos de compresión: gzip, bunzip2, RAR, … Puede estar bien un solo programa que lo haga todo. Si no se puede por problemas de patentes, investigar y dejarlo explicado en algún lado.

<04.m04.2006>

Hay varias alternativas para extender: links2, conkeror, … y otros. Con conkeror las adaptaciones para hacerlo usable son pocas.

7.2.1. extendiendo links2

Hacer un buen navegador que se adapte a mis necesidades, arreglando links2. Nota del <25.m08.2009>: quizás no es la mejor base para mi navegador favorito, pues cuesta más de manejar que conkeror.html

Le falta:

  • editor de cuadros de texto que vaya bien: cómodo, rápido, usable, y que permita abrir un editor externo (como vim) para hacer la edición, igual que en elinks
  • opción de página de inicio
  • tecla para ir adelante
  • poder moverse fácilmente por el historial (en forma de árbol)
  • arreglar el bloqueo en JavaScript al hacer a[10000000]=1
  • soporte completo de Unicode
  • que sea fácil cambiar el tamaño de letra una vez ejecutado
  • avisar si al salir se va a cortar una descarga
  • XHTML
  • incorporar las cosas buenas de elinks:
    • navegación por pestañas
    • búsqueda con expresiones regulares
    • colorear y navegar por el código fuente
    • numeración de enlaces (navegación espacial)
    • "seguir enlace y recargar sin pasar por la caché"
    • gestión de cookies
    • CSS
    • etc.
  • incorporar las cosas buenas de dillo:
    • contador de errores en el código
    • navegación por las secciones de la página
    • buen cumplimiento de los estándares
    • programa pequeño (quizás usando libdl)
    • etc.

Mirar el proyecto links-hacked. El autor ya tiene experiencia con estos cambios, y entre otras cosas propone añadir una interfaz gráfica a Elinks. Hay que decidir con cuál de los navegadores nos quedamos.

<08.m04.2006>

7.3. Editor potente, actual, libre e instructivo

El editor GNU Emacs es un universo de funcionalidades y de código instructivo. Le he dedicado una página para las pequeñas tareas que voy encontrando: tareas para Emacs.

Pero lo listo aquí porque también hay varias utopías que merecen ser realizadas, ej: hacerlo rápido, multinúcleo (esp. Gnus), multiidioma, usable con Guile, capaz de incrustar GTK, capaz de tener interfaces complejas, … Además el proceso de desarrollo necesita cambios críticos: usar bazaar, una interfaz para comunicar fallos, un proceso de gestión de parches, pruebas unitarias, subcomunidades unidas, …

Es un programa que da para muchos proyectos de investigación, pues con todo lo que ofrece se hace muy entretenido.

<25.m08.2009>

7.4. Sistema de control de versiones fácil de usar

El programa de control de versiones del proyecto Ubuntu y del proyecto GNU es Bazaar (bzr). Se caracteriza por ser fácil de usar (y hasta ahora, algo lento). Le he ido encontrando pequeños fallos; están en la página tareas para Bazaar.

Aunque el funcionamiento básico es sencillo de cara al usuario, hay muchos algoritmos, formatos y protocolos que aún hay que optimizar mucho para hacerlos lo más rápido posible; creo que hay mucho por descubrir y mejorar. Además las interfaces han de seguir siendo fáciles y rápidas.

Puedes aprender mucho de trabajo en comunidad con este proyecto, porque hay formas de trabajo bien definidas, gente dispuesta a ayudar a los principiantes, e infraestructura: juegos de prueba, gestión de parches, … y claro, control de versiones.

Esto es muy importante porque los proyectos de GNU van a usar el control de versiones de GNU, que es Bazaar, y necesitan que sea agradable.

<25.m08.2009>

7.5. En Debian

Los paquetes en Debian pasan por las ramas unstable -> testing -> stable. Yo uso la testing, pero echo a faltar varios programas en el apt-get, que tengo que bajar e instalar a mano. Ejemplos:

Alguien debería ponerse con uno de estos programas y ayudar a los encargados hasta que entre finalmente en Debian. Mucha gente lo agradecerá.

<21.m04.2006>. En <21.m03.2010>: tocar actualizar

8. Problemas básicos del servidor X (X.org)

En casi todos los GNU/Linux se usa como servidor gráfico X.org. De vez en cuando veo que hay cosas muy básicas (como escribir) que aún no están solucionadas del todo, y pienso "¿Cómo es que aún no se han puesto de acuerdo en algo tan básico?". Doy sólo unos pocos ejemplos:

  • autorepetición de teclas: cuando se mantiene apretada una tecla un rato, pasan cosas raras: X simula varias pulsaciones (falsas), pero no todos los programas lo quieren así; además cada biblioteca de interfaz gráfica de usuario ("bibigu" para los amigos) añade pequeñas chapuzas para que los programas acaben funcionando. Ver fallo que envié a FLTK: orig., coment., y fallo correspondiente en X.org: autorepetición. Sugieren algo con Xkb. En este caso, X.org, FLTK, y los programas tienen que ponerse de acuerdo.
  • copiar/pegar: el sistema es magnífico y a la vez asqueroso. El caso normal funciona muy bien, pero el problema es cuando hay que traspasar cosas entre programas que usan distintos sistemas. Hay muchos: selección con ratón + rueda, selección con Shift, Shift+Ins/Supr, Ctrl+C/V/X, gpm en terminal, screen, y después los proporcionados por gestores de escritorio (Klipper, …).
  • definición de teclado: también hay muchos sistemas para definir qué signo escribe cada tecla. Configuración en xorg.conf, xmodmap, setxkbmap, configuración en programas, y lo correspondiente para la terminal (loadkeys, kbd-config, …). Además los formatos de cada fichero de configuración son distintos.
  • configuración: ¿por qué hay tantas formas de configurar X? xf86cfg, xf86config, XFree86 -configure, editar el fichero xorg.conf (o XF86Config-4), dpkg-reconfigure xserver-xfree86, gestor de ventanas, … ¡Todo es para lo mismo!. Algunos sistemas están obsoletos y otros van bien, pero en general, es todo un lío.

Hay muchos más casos en los que varios programas y X.org han de ponerse de acuerdo. Habría que buscar los más básicos, hacer un resumen de los intentos que hay por solucionarlos (entre ellos, estándares como LSB), decidir para cada uno cuál es el camino correcto para facilitar las cosas, explicarlo todo, y conseguir solucionarlo (o que alguien lo solucione).

<09.m03.2007>

9. Multimedia

9.1. Reproductor de vídeo eficaz

Hace falta alguna guía o programa que ayude a ver vídeos (en cualquier formato) en ordenadores no muy potentes. No hacen falta consejos como "yo uso esta opción y me va bien" o "compra un ordenador nuevo", sino un análisis completo y cierto sobre:

  • qué parámetros influyen al ver un vídeo: cantidad de RAM, velocidad de la RAM, velocidad del disco duro, porcentaje de caché, opciones de compilación, etc.
  • en qué medida influye cada parámetro; cómo se pueden medir en un ordenador (para esto se pueden hacer 'perfiles' con gprof para ver en qué se pierde más tiempo)
  • estudiar un reproductor, como el mplayer, y medir distintas posibles formas de aumentar la velocidad. Ejemplos:
    • dejar de aplicar filtros y conversiones (que puede que ralenticen todo)
    • aplicar más filtros que, aunque requieren trabajo, evitan una cantidad mayor de trabajo durante la reproducción. Esto es muy difícil, porque hay muchos posibles filtros y parámetros
    • convertir el vídeo antes de verlo, a un formato que requiera poco trabajo. Esto también es muy difícil, porque hay muchísimos formatos y parámetros; antes hay que conocer el formato más apropiado )ver sección siguiente sobre formatos)
    • perder fotogramas de vídeo, o de audio
  • etc.; hay mucho por hacer; el objetivo no es "que mi vídeo se vea bien", sino entender por qué se ve bien/mal/lento/fluido/…

<13.m02.2007>

9.2. Formatos de vídeo

Un fichero de vídeo está codificado según varios parámetros: contenedor, códec de vídeo, de audio, tasa de bits en vídeo, en audio, calidad, fps, … Hace falta una lista detallada y completa (que no se deje nada) diciendo en qué consiste exactamente un fichero de vídeo. Todas esas cosas influyen en la reproducción.

Entonces, para cada una de ellas, habría que comparar cómo se puede cambiar para conseguir el máximo rendimiento en la reproducción (o sea, que el vídeo se vea fluido). Ver sección anterior para más detalles. El objetivo es conseguir el parámetro óptimo en cada una de las opciones. Naturalmente, hay que definir qué significa "óptimo"; eso es subjetivo y habrá que hacer varios grupos (configuración para que se vea con la máxima nitidez, configuración para que se vea fluido, para que la sincronización sea lo prioritario, etc.).

<13.m02.2007>

10. Idiomas artificiales

Esto sigue tratando de "informática" pero ya no de ordenadores. A muchos informáticos nos gustan los idiomas artificiales (y todo lo que tenga gramática).

10.1. Situación general

Hay muchísimos; estudiar por qué. Buscar qué grupos de necesidades lingüísticas hay en el mundo, y razonar por qué no puede haber un solo "idioma perfecto". Estudiar cómo debería ser un buen idioma, y uno malo, para cada una de esas necesidades, sin dejarse influir por los idiomas ya existentes ni por la pertenencia a uno de esos grupos de necesidades.

Un fenómeno curioso es el de los idiomas medianamente buenos que se venden como la solución universal a todos los problemas (ejemplo: Fasile; ahora no va la web pero fue (ej.). Si tuviera tiempo, me gustaría dar una visión más razonada; por ejemplo, si alguien inventa un idioma, debería poder justificar que es el idea para la finalidad que ha sido diseñado.

También habría que estudiar la (¿típica?) pregunta de: ¿qué idioma artificial me recomiendas aprender? Para eso hace falta una visión muy general del tema.

<25.m03.2006>

10.2. Lojban

  • conseguir arreglar el Lojban for beginners; hay una lista de erratas en algún lado
  • traducirlo al español. También había gente que lo empezó, y varias veces :-)

<17.m04.2006>

10.3. Esperanto

10.3.1. Requisitos

Antes de empezar con esto, se necesitan buenas condiciones de trabajo:

  • Programas que funcionen bien con Unicode.
  • Teclados capaces de escribir caracteres especiales, sin que cueste mucho (con una buena distribución de teclado).

Estas dos cosas son proyectos que también me gustaría ver acabados; están también en mi lista de cosas por hacer, aunque no esperes que lo haga yo todo… :-)

<31.m03.2006>

10.3.2. Evitar discriminaciones

Dicen que el idioma es "sexista" por lo de la terminación -ino para el femenino, pero en la práctica, hay muchos sistemas para evitarlo: la terminación -iĉo para el masculino está bastante aceptada, y hay métodos experimentales, como los pronombres ties, ĝi, ŝli.

Poner un poco de orden en estas soluciones: descartar las malas (o las que funcionan a medias), y recomendar y explicar las buenas, de forma fácil y corta. Creo que hace falta algo de entrenamiento para ser capaz de leer homo en sentido general (sin pensar en ningún género en concreto), y saber que la versión con sexo es homiĉo y homino.

Estudiar también lo del prefijo ge-, y palabras que hacen pensar en el género, como "patro" o "viro". Evitar cambios importantes, como el pronombre ri.

<31.m03.2006>

10.3.3. Hacerlo "lingvolernilo"

Es un idioma muy bueno para aprender otros idiomas (naturales o artificiales). Debería ser una herramienta, de forma que cualquiera pueda aprenderlo en unos meses y después poder usarlo para seguir un curso de cualquier otro idioma. O sea, hacen falta: cursos de idiomas naturales, escritos en esperanto.

Todas las condiciones son buenas: los hablantes están interesados en el tema de idiomas, el lenguaje incluye algunos conceptos lingüísticos, la fonética incluye sonidos propios de la pronunciación de las lenguas europeas, etc.

Hace falta también alguna lista para organizar todos estos cursos, y, como el resto de temas de los que hablo aquí, que tengan licencia libre (para permitir su modificación, redistribución y uso).

<31.m03.2006>

10.3.4. Folleto informativo

PakEO es una hoja con información sobre el esperanto para gente que quiera saber cómo es. Creo que esta idea está muy bien, y me gustaría:

  1. Comprobar si hay otros proyectos parecidos, e incorporar las cosas buenas.
  2. Convertir a formato OpenDocument los ficheros, o a cualquier otro que sea libre.
  3. Simplificar el diseño para que no hagan falta programas complejos. (Si es posible).
  4. Traducir al español y al catalán.
  5. Anunciar, imprimir copias, etc. Especialmente, enseñarlo cuando alguien pregunte qué es lo del esperanto. Este folleto es una buena explicación (ya que tiene la gramática).

<31.m03.2006>

10.3.5. Terminología básica de informática

Asegurarse de que hay un nombre claro y bueno para cada concepto de informática. Un buen sitio donde anotar todo esto es la Wikipedia.

Se pueden importar los conceptos de Komputada Leksikono (ésa es una de mis cosas por hacer), o de otros sitios.

<31.m03.2006>

11. Arreglar fallos de un programa

Tal como explico arriba, un trabajo de investigación maravilloso sería: «Identificación y corrección de les 10 principales problemas de […]» y ahí un programa libre. Ver más datos ahí. Un programa con mucho potencial de investigación y aprendizaje es Emacs; mira la sección de Emacs.

12. Otras listas

Hay otras listas de cosas interesantes por hacer: