28 Sep
2015
28 Sep
'15
11:23 a.m.
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 <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 http://www.rastersoft.com
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
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