28 Sep
2015
28 Sep
'15
1:23 p.m.
Estoy de acuerdo...
El 28/09/15 a las 13:04, Odo escribió:
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 <mailto:rastersoft@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ó:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
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 <mailto:rastersoft@gmail.com>> escribió:
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ó:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
<<< this email was written with 100% recyclable electrons>>>
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
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 <mailto:rastersoft@gmail.com>> escribió:
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ó:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon 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(a)gmail.com>
<mailto:rastersoft@gmail.com> wrote:
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>
<mailto:rastersoft@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 list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon