[ATARI] Linux, TOS, Kylix (= mierda)

[Gabriel Huertas]

	Saludos.

	Resulta que hace unas semanas (2 o tres), recién estrenado el Virus
Worm.Gibe nuevo, se expandió por la red de la empresa como la espuma. Y
como lo contrajimos recién aparecido, no había antivirus para él. Y como
tampoco sabçiamos que es lo que hacía exactamente, decidimos eliminarlo
a lo bestia, matando nó sólo al virus, sino dejhando tocados los
registros de Windows y a la larga volviendo a tener que reinstalar todo.
Para cuando acabamos (3 dias después) ya había antivirus, pero no era
aplicable a nuestros sistemas porque no reconocía el troyano debido a
los cambios a toda prisa que habíamos hecho. Kafkiano.


	¿Cual es el resultado final? Algo bueno a pesar de todo. Linux dejó de
ser un entorno de prueba, y Windows ha sido definitivamente abandonado
(también a título personal). Hay que decir, que Los ordenadores llevan
ya 2 semanas funcionando a pleno rendimiento y ni un cuelgue, todo
parece funcionar bastante bién (y rápido). A partir de 1 Ghz parece ir
el asunto mejor que con Windows en cuanto a rapidez en todos los
sentidos. Los programas que tenemos desarrollados en VS corren sin
demasiado problema bajo wine, y salvo alguna pequeña incidencia ( como
knews, que a veces tras abrirse no se puede cerrar, aunque no se cuelga)
todo parece magnífico en el RedHat9

	Y a pesar de todo hay que acordarse del ST...
	Veamos, resulta que decidimos probar Kylix de Inprise (Borland, aunque
parece que de Borland queda el Logotipo, como sucede con
Atari/Infogrames). Se instala... y no funciona. Carga, pero no compila
un simple "Hello world" dando errores de linkado. Te encuentras parches
por toda internet (¡Pero no de Borland!) para corregir esto. Una vez
corregido , otro problema, el compilador se cuelga... esta vez debido a
problemas con el "autocorrector" de código. Basta con desactivarlo, y
una de las opciones más comodas del programa desaparece a la vez que el
problema. Pero ahí no queda la cosa... EL IDE NO SOPORTA LENGUAJE
ESPAÑOL!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
No se pueden escribir tildes. Esto ya suena como el Borland C++ clásico
para PC, en el que para introducir nuestros caracteres própios los
tienes que llamar por su código ASCII, o utilizar convertidores externos
y chorradas. Y digo yo, ¿tan difícil es limitarse a leer los caracteres
del propio SO? Así se podria trabajar con cualquier idioma, narices. El
TurboC y el PureC de Atari no presentaban este problema. Pero es que el
problema en los ST no lo presentan ni los Basic (GFA por ejemplo). ¿Será
posible que sólo Microsoft soporte el lenguaje correctamente? . AL final
tenemos que reconocer a regañadientes lo que todos sabamos, que el mejor
paquete de desarrollo de Windows es el Visual Studio de MS.

	Kylix desde luego, es un producto descartable, desechable, e incluso
ofensivo para el usuario, que te hace perder tiempo en descarga, sujeto
a extrañas condiciones de licencia, y además sencillamente ineficaz,
lento, falible y chapucero. Alguien de la lista me dijo que Kylix 2 era
C++ Builder corriendo bajo Wine... No lo llegue a ver, pero todavía hay
componentes wine en Kylix3. Buen ejemplo de hasta donde pueden llegar
los emuladores... , pues resulta que el entorno de desarrollo gráfico en
vez de ser diseñado para Linux corre gracias a un emulador de Windows...
	¿A donde estamos llegando, no es esto sencillamente vergonzoso? Porque
encima es que no funciona... , y te recomienda que utilices versiones de
Linux obsoletas. Muy buen producto, si señor. A los programadores de
software libre no se les ocurriría ( al menos aún no ha sucedido) lanzar
al público chorrada semejante.

	Y esto nos lleva a otro desagradable asunto, el soporte para teclado e
idioma Español en RH9. Resulta que dentro del entorno gráfico (léase
desktop de X), el soporte para español es perfecto. En distribuciones
antiguas, encontraba algunos programas que parecían "olvidarse" de que
el entorno estaba en español, y no atendian al mapa correcto de
caracteres, en esta nueva esto se ha solucionado. Todo programa de X
parece funcionar perfectamente (excepto los emuladores de Atari que no
sean XSteem, que siguen haciendo de las suyas con la configuración del
teclado español, lo de siempre, al final clocky lo vamos a tener quie
considerar como una extensión del TOS). Pero HE AQUÍ LA
SORPRESA!!!!!!!!!!!!!. Ahora resulta que es la cónsola la que no
responde correctamente, sino que hace locuras cuando se intenta
introducir un acento. Los terminales de X funcionan correctamente, por
supuesto, me refiero al modo texto real. Cuando escribes un acento, el
cursor retrocede aleatoriamente los espacios que le da la gana
eliminando o alterando a su antojo los caracteres que encuentra en su
camino. Cómico. No encuentro sin embargo comentarios en Internet sobre
ésto. ¿Habrá que pensar que nadie usa el modo texto? (que es
precisamente dónde se explota toda la potencia de Unix). Esto significa,
que si te gusta programar en VI, o introducir textos sencillos con él,
vas listo. El caso es que esto no pasaba en versiones antiguas de RH.
Por cierto ¿CONOCE ALGUIEN LA SOLUCIÍON AL PROBLEMA?.

	La conclusión final es fácil: Kylix es basura, los mejores lenguajes de
programación son los de la GNU. Se instalan sin problemas, funcionan a
la primera, son nativos (y no corren ofensivamente con ayuda de
emuladores) con entornos como KDevelop se parecen cada vez más a VStudio
con la ventaja de que siguen sin necesitar entornos gráficos para
compilar el software desarrollado (ideal para la distribución de
fuentes, etc). No obstante, me he encontrado también un problema con el
dichoso teclado en Español con el GNU Prolog (otro emulador, no lo
olvidemos).	
	Y ya que parece que estamos obligados a utilizar gcc, la siguiente
pregunta es ¿como se adapta de bien esto a un atari?. ¿Hay algún
tutorial por ahí para programar Atari con gcc? ¿Existe algún GCC con
soporte para procesadores sencillos (68000) o hay que trabajar con 68030
en adelante (lo que nos empuja a pensar en destinar el resultado a
correr en emuladores).

	En fin , resulta que mientras me aclaro con las utilidades de
desasrrollo para Linux, y en el montaje de CDs con ISOLINUX para
correrlas, hace unos dias hubo que hacer un programa de cálculo de
estructuras metálicas, y lo hice para Atari... para ser corrido en un
emulador. El programa hacía falta a pié de obra (para ajustar diagramas
cremona a las medidas exactas resultantes en obra para vigas de
celosía). La solución: CD autoarrancable con el OS host, emulador +
software incorporado... Y todavía el ingeniero flipa por lo rápido que
el programa carga... (menos de 10 segundos y ya cargado sistema y
software bajo el emulador).
	
	¿A donde estamos llegando cuando los emuladores corren más rápido que
los programas nativos y dan menos problemas? ¿A donde vamos con empresas
como "Borland" vendiendote patatas que ocultan que corren bajo
emuladores? ¿A donde vamos con lenguajes como JAVA? ¿No es risueño que
el JIT sea más rápido que la compilación de toda la vidad? ¿Que un
pocesador emulado con otro distinto pero de potencia similar pueda
correr más rápido? (en realidad deberíamos estar contentos los
programadores, pues esto es en definitiva el "triunfo del software sobre
la máquina"). La semana pasada me compré un piano electrónico Kurzweill,
por aquello de que son portables (a pesar de sus veintitantos kilos, el
piano real pesa 600), frente al acústico... Aquí si que no admito
emuladores (de hecho no hauy forma de emular los armónicos que produce
el piano, porque dependene de toda combinación de teclas y otros
factores que tienden hacia infinito, sucede lo mismo con muchos
instrumentos). Los instrumentos acústicos son mas pesados y difíciles de
utilizar, pero como suenan... Hay que estar acostumbrado a escuchar
música clásica en directo, para saber que hasta el sonido de los CD
puede considerarse detestable. Los sintetizadores por su parte, dejaron
de ser creativos cuando se emplearon para imitar sonidos acústicos, en
vez de para crear sonidos nuevos, convirtiéndose en emuladores. En
principio constaban de osciladores, generadores de envolvente, etc, para
producir armónicos, y sistemas más o menos complejos de modulación y
procesado. Finalmente hoy, Roland te vende emuladores de sus sintes
clásicos. EL mismo Kurzweill, ha resultado ser un puñetero ordenador
escondido en el teclado, con un emulador de un módulo anterior de la
misma Kurzweill, que a su vez imitaba el sonido de los pianos mediante
técnicas de sampling y resíntesis. El nuevo modelo, ya , simula el
sampler y los osciladores y los generadores de envolvente del
sintetizador original, que a su vez trataba de emular el sonido del
piano acústico. Emuladores de emuladores que corren emuladores... para
emular sonidos que exisen desde hace siglos.

	Y hasta quines más detestan los emuladores... utilizan emuladores
(sintetizadores antiguos, ganan "identidad propia" y son admirados por
sus propias capacidades e incapacidades) etc.

	También la religión nos promete que algún dia seremos emuladores de
humanos. No realmente humanos, sino seres con sus ventajas y sin sus
"inconvenientes" (como argumenta todo emulador para fundamentar su
existencia), que no obstante no serán humanos.

	Ya lo decían Platon y Plotino (fundamentador filosófico del
cristianismo en cierta medida). El mundo en que vivimos es una emulación
del mundo verdadero, por eso es imperfecto.