24 Apr
2016
24 Apr
'16
10:32 p.m.
O verdadeiro problema é executar un docker de 32bits nunha máquina de 64.
El 16/04/16 a las 14:55, Ungoliant escribió:
Sergio, agora q Rafa trae o tema de volta, lembreime
de unha cousa que
me mostrou un tipo da oficina hai un par de semanas:
http://blog.hypriot.com/getting-started-with-docker-on-your-arm-device/
Se Docker funciona nas RPi 1 e 2, en ARM 32bit, malo sera que non
funcione en x86 32 bit.
Unha aperta.
El 14 de abril de 2016, 10:15, Rafa Couto <rafacouto(a)gmail.com
<mailto:rafacouto@gmail.com>> escribió:
Ao final o tes solucionado? Exploraches a opción de UnionFS nun
kernel 32 bits? (ou sexa, degradar docker a 32bits ;)
2015-09-28 11:23 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com
<mailto:rastersoft@gmail.com>>:
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
--
Rafa Couto
GNU/Linux user #99126 - _http://bit.ly/LC-99126_
GPG key - http://bit.ly/GPG-D76ABDEC
_______________________________________________
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
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