#9090 Sale y mucho, sobretodo cuando lo juntas con kubernetes
#9090 la cosa es que no virtualizas. Los contenedores tiran del kernel del host
#9091 hace apenas 1 mes que hemos pasado gran parte de nuestra aplicacion a dockers con kubernetes, y aunque el cambio es costoso, merece mucho la pena.
Los deploys ahora son rapidísimos, los developers no han de tener en cuenta el entorno dodne se va a deployar el código, y me ahorro el "Pues en local me funciona"
#9090 El problema de docker no es el rendimiento. El problema es la seguridad, que al no tener centralizados los paquetes puedes estar tirando de un docker con software sin parchear y ni te enteras. Tienen su propia jail, pero por lo general tienen acceso a las bases de datos y archivos que son lo jugoso de cualquier sistema.
#9098 Siempre puedes tirar de la imagen del SO que te salga del pito, hacer un upgrade/update e instalar todo a manita. De todos modos es raro que las imágenes que más usa la gente estén sin actualizar.
Cómo narices ejecuto el gestor de ventanas sin un gestor de pantallas? Es decir, cómo abro cinnamon desde el terminal (tty).
He probado a crear xinitrc en mi carpeta personal y poner 'exec cinnamon-session' pero no hay suerte.
Siempre que ejecuto startx se me abren las tres ventanitas y el reloj independientemente de lo que ponga en xinitrc
Vale, resuelto. Bendita wiki de arch
#9090 pues sale todavía más a cuenta en producción, porque te quitas de muchos problemas. Aparte de lo comentado en otras respuestas, el hecho de tener todo el entorno descrito a nivel de código y poder desplegar con un click/comando no tiene precio.
La pérdida de rendimiento, de haberla, me resulta imperceptible, y además se facilita mucho limitar máximos de uso de CPU y RAM a nivel de contenedor (para que un servicio no se coma todos los recursos de la máquina). El hecho de que vaya fino funcionando sobre Raspberry ya dice mucho.
@kaiserlau en /dev/cuca alguien me definió un container como una vm pequeñita -.- y no fue el chino precisamente.
Entiendes mejor lo que es un entorno enjaulado cuando has jugado con netintalls/installs from scratch y no con las putas mierdas con asistentes gui de UBUnTOoO
Tirarte hasta las 2 de la mañana, teniendo que currar a las 8 al día siguiente, removiendo la mierda de ipv6 y por qué tu ubuntu server no pilla la ipv6 del router, culpar a netplan y a dhcp hasta la saciedad, y que al final el problema sea nftables no tiene precio. Para que luego digan que linux no es bonito.
aaah the good old times...
Ahora que estoy pasando el BleachBit a fondo y me va el pc a lagazos, aprevecho para preguntar: ¿Cómo hacéis vosotros mantenimiento y limpieza en vuestro PC?
#9110 Pues no sé cuanto tiempo llevarás con tu instalación, pero debe de tener bastante mierda residual de las actualizaciones, desinstalaciones y uso diario
#9111 Algo más de año y medio, lo uso todos los días para currar y ahí va como un tiro.
Si tengo que probar movidas o compilar cosas de node lo tiro en un container y el sida que me ahorro.
#9109 limpiar la caché de pacman cuando veo que el espacio flaquea si acaso y aún así casi siempre compilo a RAM. Huérfanos una vez al año?
Perfiles y caches de navegadores a RAM. La caché muerte en cada reinicio, perfil sincronizado a disco. Un programa llamado profile-cleaner cada mil para compactar bases y eso.
Y creo que ya. Que mas basura va a quedar? Alguna pasada por .cache y .config de vez en cuando por algún config suelto? Comprobar enlaces simbólicos rotos una vez al año también si acaso. "ncdu" para ver gráficamente dónde se va el espacio. No se.
Bleachpollas y cleanleches me dan más miedo que un virus a mi :s
#9115 a ram, no la ram, o bien usa algo para montar una unidad en la ram o bien el programa le da la opcion de hacer algo al mismo efecto
basicamente tienes 16 gigas de ram y de ellos 8 los reservas para /ramdisk, por explicarlo asi a lo bruto
https://www.jamescoyle.net/how-to/943-create-a-ram-disk-in-linux
la ultima vez que use algo similar fue en msdos, que recuerdos
#9116 ¿Y eso no sería contraproducente? Quiero decir, la RAM no es precisamente lo que sobra, por ello la partición swap. ¿Qué ventajas tiene usar 8G de la RAM como disco ultrarrápido? sin tener en cuenta que cuando apagues el PC los datos se van a la mierda.
#9117
velocidad de acceso, cuando compilas se leen y se crean muchisimos ficheros pequeños
primer resultado de google a la busqueda de ramdisk to compile https://dzone.com/articles/accelerating-build-using-ram-disk, hace años en una empresa donde compilar eran 5 horas con disco mecanico, eran 40 minutos con memdrive, tenian una maquina especifica para eso con 2 o 4gb de ram, era por la epoca del windows 98 creo recordar
#9117 pues muy posiblemente ya lo haces.
Hay una cosa llamada tmpfs, montada en /tmp, que por defecto dedica la mitad de tu RAM a un ramdisk de estos. Y es comportamiento por defecto de systemd, así que 99% que como digo ya lo usas si no me equivoco.
Pero no reserva la totalidad de la memoria del tirón, sino que va reservando según lo va necesitando/gastando al momento, así que descuida en ese sentido.
#9119 De hecho, hay más de un punto de montaje en tmpfs (Debian 10):
$ mount | grep tmpfs
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=972236k,nr_inodes=243059,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=197392k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
tmpfs on /run/user/1001 type tmpfs (rw,nosuid,nodev,relatime,size=197388k,mode=700,uid=1001,gid=1001)
