28 Sep
2015
28 Sep
'15
10:49 a.m.
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
<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 http://www.rastersoft.com
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
https://listas.galpon.org/listinfo/galpon