Bennu en la lista de Fedora Games

[osk]

Buenas.
Envié una nota a la lista de correo de Fedora Games indicando la existencia de Bennu, y han contestado un par de personas.
En concreto, mi mensaje está aquí: https://www.redhat.com/archives/fedora-games-list/2009-November/msg00031.html
Si veis lo que contesta la gente, podéis ver que hay una chica llamada Miriam Ruiz (¿inniyah, no?)que, sin haber dicho yo nada, sabe que Bennu viene de Fenix, que viene de DIV.... Lo que dice ella es que lo malo de Bennu es que "the direct conversions between integers and pointers in the code do not work at all in 64 bits". Entonces ha escrito un tal Jon preguntando: "I saw that there's no 64-bit version, would this fact preclude running the 32-bit version on 64-bit platforms?", con lo que Miriam ha vuelto a contestar (citando referencias que no pongo): "AFAIK, it can be compiled with -m32, but not with -m64, that's the reason I haven't packaged it for Debian yet, although I've been following the project since its birth. Maybe it could be fixed with  intptr_t and uintptr_t (Linux equivalent for Window's UINT_PTR and INT_PTR ), but as that numbers are part of the virtual machine code, that would make code not portable between architectures (I seriously doubt that it is now, even in 32 bits with different endianess, but I haven't checked so I might be wrong). The proper way to fix it would probably be to have a dictionary (or something EQUIVALENT), and put the key to the dictionary in the id and the pointer in the value, thus avoiding having the actual pointer in the 32bit id . Whatever the solution might be, it seems to imply a hard work, so for the moment I would only consider using it in 32 bits arches."

Splinter, ya sé que estás muy ocupado, pero yo me compromento a ir respondiendo en esta lista a las cuestiones que vayan saliendo alli, siempre y cuentoa me pudiérais echar una mano en este foro sobre las cosas que se dicen allí y que yo os transmita, porque yo no sé ahora qué contestar. Estaría muy bien, para ir manteniendo el contacto, ¿no os parece?

Venga, hasta luego.

[panreyes]

Hello,
Sobre el tema, PiXBros y PiXFrogger están en Ubuntu 64 bits, pero no está Fénix xD

[josebita]

¡Hostia, colega! ¡Cualquier día te meten a la cárcel por spammer!.

En fin, voy a salir de mi asombro y seguir con la mañana...

[panreyes]

Inniyah es quien metió Fénix en Debian, que luego entra en Ubuntu xD
ESTABA RELACIONADO, VALE? XD

[josebita]

:D

[osk]

Vale...pero respecto lo que dice Inniyah de los 64 bits, vosotros que sabéis más del tema...¿qué pensáis? Según ella está chunga la cosa.

[josebita]

Está chungo de momento, sí.

[splinter_work]

miryan es conocida entre varios de nosotros, es la culpable de que fenix este en debian, y junto a josebita sera la culpable de que proximamente este bennu en debian...

por otro lado, ya pronto tendremos una version 64bits de bennu... lo que no me queda aun claro, no lo decido, es si sera una version propia de 64bits, incompatible con la version 32, tanto a nivel interfaz dlls como dcb (obviamente que las dlls binarias 32bits no correran con los de 64bits) o sera compatible...

por otro lado, habra que agregar un nuevo tipo de dato que sera 64bits... y demas esta decir que sera el dato base... esto puede generar (o generara) incompatibilidades con los actuales dcb/dlls.

[Drumpi]

Hasta ahora ya nos hemos acostumbrado (más o menos) a tener versiones 32 y 64 bits de los mismos programas (al menos, los que suelo usar son así, y tiendo a quedarme con las de 32). Por eso no creo que hubiese problemas.
La pega es la de los DCB, esos sí deberían ser compatibles. Entre 32 y 64 bits podemos pensar que son plataformas independientes, pero si cambiamos los DCB se pierde la portabilidad.

Entiendo que se vayan a hacer un nuevo tipo de dato (que me parece recordar que ya existía en lenguajes para arquitecturas 32 bits), pero no que sea el tipo base...
Bueno, si, pero en 32 teníamos el int como base y aun así se podía usar tipos de 8 o 16 bits sin problemas... Seguro que se me escapa algo.

[osk]

Ese tal Jon (que parece ser un empaquetador)ha dicho en la lista lo siguiente:

"So, looking at this, I see that it needs (and bundles) libdes, which looks long dead upstream, and uses a static lib.  libdes isn't in Fedora, or Debian as far as I can tell, so we may have to bundle it. That makes me nervous, since if it's dead, it may have vulnerabilities that are going unpatched, which makes me additionally nervous if we then go on to package games that make use of this."

A lo que Miriam le ha contestado que se ponga en contacto con Splinter, y yo también. Así que a lo mejor se pasa por aquí.

[SplinterGU]

no entiendo cual es la preocupacion con la libdes... alguien me explica?

por otro lado, tipo base, sera que las funciones retornaran valores de 64 bits, los opcodes seran de 64bits... se rompera si o si la compatibilidad con los dcb actuales, esto es, habra que recompilar... ya que no se podran devolver 64bits en 32bits...

[josebita]

miryan es conocida entre varios de nosotros, es la culpable de que fenix este en debian, y junto a josebita sera la culpable de que proximamente este bennu en debian...

por otro lado, ya pronto tendremos una version 64bits de bennu... lo que no me queda aun claro, no lo decido, es si sera una version propia de 64bits, incompatible con la version 32, tanto a nivel interfaz dlls como dcb (obviamente que las dlls binarias 32bits no correran con los de 64bits) o sera compatible...

por otro lado, habra que agregar un nuevo tipo de dato que sera 64bits... y demas esta decir que sera el dato base... esto puede generar (o generara) incompatibilidades con los actuales dcb/dlls.

Lo cual me recuerda 2 cosas:

• Debo escribir a Miriam.
• Tal y como comenta miriam en sus mensajes, ahora mismo los DCBs no son compatibles entre máquinas con distintos endian (como seguro que sabes..)

Y bueno, me alegro mucho de que finalmente vaya a haber una versión nativa de 64 bits :) Ya veremos cómo solucionar el problema de incompatibilidad de dcbs...
Igual voy a decir una chorrada, pero se me ocurre que ahora mismo el intérprete ya soporta abrir dcbs con offset. Si fuera posible que el compilador generara dcbs tanto de 32 como de 64 bits, los podrías pegar uno detrás de otro y que el intérprete lea uno u otro, dependiendo de la arquitectura de trabajo.
Algo así como los binarios universales de MacOSX:
http://es.wikipedia.org/wiki/Binario_universal
http://en.wikipedia.org/wiki/Universal_binary

Por supuesto, no tengo ni idea de cuánto trabajo llevaría modificar el compilador para que pudiera hacer algo así, ni si la arquitectura actual lo permite.

En cuanto a la libdes: hay un poco de alergia a mantener paquetes que dependan de otros que no están soportados por los autores.

[Drumpi]

Lo cierto es que ayer me llevé un par de sorpresas relacionadas con la libdes: no se por qué, la linea de comandos me tira un error de que no puede acceder a un puntero que no existe. No recuerdo exactamente el mensaje, sé que primero me salió en GP2X, lo cual achaqué a mi torpeza (lo cual es factible, dado que se me cuelga intentando abrir un XM diciendo que no existe el HW), pero luego me salió en Ubuntu.
Mañana lo miro y lo copio.

[SplinterGU]

el tema con la libdes no es muy prolijo, ya la vamos a cambiar...

[SplinterGU]

ya se cambio la libdes por la libssl (openssl), agradeceria si pasan la noticia a la gente de fedora...

saludos.