28 Sep
2015
28 Sep
'15
1:04 p.m.
Sergio, sinceramente, y sin interes niguno de desanimarte, sino todo lo
contrario, por que a mi tambien me pasa de querer perfeccionar demasiado
las cosas.
creo en mi humilde opinion, que para el caso que estas descriviendo el
esfuerzo de la mejora es superior al beneficio y resultaría mejor dejarlo
tal y como esta y dedicar tu tiempo y esfuerzo a una tarea que tenga un
beneficio mayor.
El 28 de septiembre de 2015, 11:23, Sergio Costas <rastersoft(a)gmail.com>
escribió:
A ver, lo explico mejor: se trata de mejorar el
rendimiento de mi programa
MULTIPACKAGER, que me permite generar paquetes para cualquier distro y
arquitectura. Hoy en día me genera sin problemas paquetes de 32 y 64 bits
para debian, ubuntu, fedora y arch, tanto en 32 como 64 bits, y dado que
está todo automatizado me parece absurdo discriminar a los 32 bits, cuando
aún hoy siguen teniendo uso (marginal, sí, pero es que ya digo que el
proceso de generación está automatizado, y una vez que tengo listos los 64
bits, los 32 no suponen trabajo alguno). Si meto docker (que haría que
fuese algo más rápido) perdería la ventaja de generar paquetes de 32 bits.
Ese es el motivo de no querer renunciar a los 32 bits.
El 28/09/15 a las 10:59, Ungoliant escribió:
Ya tienes que tener una muy buena razón para no migrar a un entorno de 64
bit.
Por ejemplo, RHEL7 ya no esta soportada en 32 bit y se empieza a ver cada
vez mas software en el cual la version 32bit se queda rezagada.
El 28 de septiembre de 2015, 10:49, Sergio Costas <rastersoft(a)gmail.com>
escribió:
--
<<< this email was written with 100% recyclable electrons>>>
Si, la parte de las imágenes podría solucionarlo.
El problema sigue
siendo los 32 bits. Hay imágenes no oficiales, pero dado que docker en sí
no funciona en modo 32 bits, y parece que tiene que copiar su propio
ejecutable dentro de la imagen, obliga a que el contenedor funcione en modo
64 bits aunque todo el código interno sea de 32. Y eso me puede dar
problemas :(
El 28/09/15 a las 10:45, Ungoliant escribió:
Combinando el proceso de "crear" y el de "lanzar" puedes mezclar lo
que
quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas un contenedor a
partir de una imagen, y tras los cambios, si funciona, haces un commit para
crear una imagen a partir del contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas < <rastersoft(a)gmail.com>
rastersoft(a)gmail.com> escribió:
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Pero eso obligaría a meterlo dentro de la imagen,
y una vez hecho el
"chroot", el código de la biblioteca ya no tendría acceso a la carpeta
donde guardar los cambios, pues se supone que estaría fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
HDYS, si exportas la variable LD_PRELOAD, al ponerlas en el entorno, le
afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn pero supongo que
si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas
<rastersoft@gmail.com><rastersoft@gmail.com> <rastersoft(a)gmail.com>
wrote:
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
>
> Puedes tirar de LD_PRELOAD.
> Creas una libreria que implemente tu propia funcion write, que lo que haga sea una
copia del fichero que se pasa como parametro a write (en forma de FD).
>
> Tiene la ventaja que valdría para cualqier programa.
>
> Un saludo
>
> On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <rastersoft(a)gmail.com> wrote:
>>
>> Hola gente:
>>
>> Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
>> si alguien sabe si hay algo como lo que busco.
>>
>> En estos momentos
>> tengo una carpeta, digamos "A". Quiero hacer una
>> serie
>> de operaciones en ella, pero no seré yo, sino una serie de programas,
>> que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
>> como quiero poder revertir todo en caso de que alguna operación salga
>> mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
>> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
>> "A.BACKUP" encima de A.
>>
>> El problema es que la copia inicial es muy lenta, tarda demasiado
>> tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
>> Copy-On-Write. Supongo que la idea sería un sistema de ficheros
>> virtual,
>> como AUFS. El problema de este es que, aunque me permite conservar el
>> contenido de una carpeta, y grabar en otra los cambios, no veo que me
>> permita mezclar los cambios sobre la carpeta original si, al final,
>> todo
>> fue bien.
>>
>> Empecé a
>> escribir un sistema de archivos para FUSE, pero antes de
>> seguir
>> quería saber si ya existe algo así.
>
>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon