Portada
mis comunidades
otras secciones
#4:
Es importante decir que esto solo lo mejora con muchos cgroups, para plataformas donde se usen cgroups de forma extensiva (como por ejemplo kubernetes) es la hostia, para los usuarios domésticos donde el uso de cgroups es marginal, no debería haber una mejora dramática.
Si uno mira en su workstation los contenidos de /sys/fs/cgroup o systemd-cgtop es evidente que no hay mucha mejora posible.
Si uno mira en su workstation los contenidos de /sys/fs/cgroup o systemd-cgtop es evidente que no hay mucha mejora posible.
#9:
#8 Inesperado para nada, Facebook contribuye mucho código a la comunidad. Ha hecho un huevo de mejoras en PHP, rocksdb y cassandra son bases de datos de facebook, cgroups tiene muchísimo trabajo de gente de facebook, btrfs y del subsistema de redes hacen bastante.
Puede ser una empresa éticamente cuestionable a muchos niveles, pero en cuanto a contribuciones open source, sin ser Red Hat, es una empresa impecable, y su blog técnico, aunque en general es flojo, tiene alguna que otra joya.
Puede ser una empresa éticamente cuestionable a muchos niveles, pero en cuanto a contribuciones open source, sin ser Red Hat, es una empresa impecable, y su blog técnico, aunque en general es flojo, tiene alguna que otra joya.
#2:
La fuente original, gracias: https://thenewstack.io/a-new-linux-memory-controller-promises-to-save-lots-of-ram/
...
...
#8:
Ingeniero de Facebook que trabaja en el kernel de linux. Facebook hace algo bueno por la humanidad, eso si que es algo inesperado.
#11:
#10 Cuando tienes tantas máquinas que además suelen ir bien exprimidas, vas a necesitar gente capaz de arreglar bugs del kernel si o si, y con el tamaño de facebook (google, twitter, netflix, etc.) es impensable comprar soporte a una empresa tipo Suse o Red Hat.
https://engineering.fb.com/open-source/improving-the-linux-kernel-with-upstream-contributions/
https://engineering.fb.com/open-source/improving-the-linux-kernel-with-upstream-contributions/
#1:
Vendo Opel Corsa con 64 MB de EDO RAM 72ms
Comentarios
Es importante decir que esto solo lo mejora con muchos cgroups, para plataformas donde se usen cgroups de forma extensiva (como por ejemplo kubernetes) es la hostia, para los usuarios domésticos donde el uso de cgroups es marginal, no debería haber una mejora dramática.
Si uno mira en su workstation los contenidos de /sys/fs/cgroup o systemd-cgtop es evidente que no hay mucha mejora posible.
#4 Menos mal que lo explicas. Estaba pensando en las distros que meten todo un KDE en poco más de 300MB de RAM e imaginando cuanto más se podría reducir eso
#4 Quien use systemd (usado en casi todas las distros modernas) está empleando cgroups desde el arranque.
Pero vaya, de todas formas seguro que un usuario normal apenas va a notar nada.
#17 Si, claro, pero si ves /user.slice/user-.slice/ y el resto yo veo poco margen de mejora ahí...
Algo habrá, pero cuando un solo slice lo normal es que te consuma bastante más de la mitad de la RAM, poco margen de mejora queda para el resto...
#17 Pues que yo sepa, en mi Opensuse tumbleweed no aparece por ningún lado por defecto, y uso systemd, todo según el gestor de tareas.
La fuente original, gracias: https://thenewstack.io/a-new-linux-memory-controller-promises-to-save-lots-of-ram/
...
#2 Gracias por el aporte, no sé inglés
#12 Hoy en día no hace falta saberlo.. La verdad.. Si usas Chrome, el traductor automático realiza todo el trabajo.. & a poco que te des cuenta un alto porcentaje de las noticias de los blogs en español, proceden de otro lugar...
De hecho, es bastante raro encontrar artículos originales o no basados en otros en inglés; yo aún estoy buscando blogs en español, que no sigan esas prácticas..
#14 hombre hacer falta si que hace. Otra cosa es que te apañes con una traducción patatera.
#47 De patatera tienen poco, hoy en día son bastante acertadas; pero bueno....
Al menos, muylinux, se digna a reseñar la fuente.. Lo que otras ni siquiera hacen....
#51 ya, eso de reseñar la fuente debería de ser lo mínimo
#14 Claro, porque las webs inglesas no tiene fuentes...
#62 Sí. Algunas también serán contenidos robados o duplicados y no te digo yo que no dejan de hacer lo mismo.
Más, en el caso principal del creador de la noticia. Sí, tienen fuentes.
Las FUENTES REALES.
Que son las personas que conforman a equis empresa o el contacto directo con las empresas de Silicon Valley -a lo que los blogs en español, que yo sepa ninguno tiene acceso, ni tampoco trabaja por tenerlo- en su defecto los Blogs o Páginas Oficiales -lo que las páginas en español, suelen utilizar con bastante poca frecuencia; en el caso de MuyLinux, en concreto. Quiero recordar que sí, algunas veces les he visto citar la notas oficiales.. Que ya al menos se salvan.
Más. Así es como deberían de ser las noticias, extraídas de las compañías, empresas, marcas reales y del personal de las mismas; a base de mantener contacto con ellas.
¿Conoces a algún blog que mantenga el contacto con las agencias españolas de los diferentes proyectos de tecnología para que esto sea así? Si es así, por favor dígamelos uno a uno. Todos los que conozcas. Porque estoy seguro que ni xataka, ni elchapuzasinformatico, ni adslzone entre otros muchos.
En su gran mayoría, la fuente es otra página web de noticias y no solo la fuente; si no que el contenido esta basado en un 98% en la investigación y contenido generado en esa página, de hecho los anteiores citados suelen robar hasta las imágenes/fotografías. Lo que se convierte básicamente en pura basura.
En plagio de contenido, ideológico y de ideas. Vamos que ni tan siquiera están transmitiendo los que ellos piensan, si no lo que otros piensan & bueno, sí.
Cierto es, que entre lo que existe; muylinux no es el peor de los casos para nada.
De hecho debe de ser de entre lo casi más potable....
Igualmente. En este caso Muy Linux no deja de transmitir una noticia con una pequeña nota. Lo que yo considero como quieren compartir la NOTICIA ORIGINAL sin fusilarla ni plagiarla; más que el hecho de que quieran transmitir por completo la noticia ellos mismos; y considero que la noticia original transmite bastante más información que la nota de muy linux.
Por ello, el enlace original.
Vendo Opel Corsa con 64 MB de EDO RAM 72ms
#1 ¿"EDO RAM"? Hostia, qué tiempos aquellos. Esa memoria era asíncrona si no me falla la ídem.
Eres un viejuno.
#3 Esa era la de los Pentium y K5 justo anteriores a los MMX. Solian ser de 72 pines, no de 72ms
#5 Mi primer PC era un MMX y también montaba EDO, 16 pedazo de megas, que recuerdos...
#31 Mi primer PC fue un 486 DX2-66 de 1994, pero con RAM EDO me compré luego un Pentium Pro 200, que era un avión. Luego salió el MMX, y aun así los 512K de caché lo hacían más rápido.
Curioso, porque eso ocurrió en 1997, y lo jubilé a finales de 2000 por falta de potencia. Y sin embargo, mi portátil de 2008 duró 10 años y lo jubilé por una estación de trabajo muy grande. Pero funciona perfectamente.
Creo que la Ley de Moore va perdiendo sentido, o los desarrolladores de software comerrecursos van perdiendo fuelle.
#43 Curioso, mi MMX también lo compré en el 97 y lo jubilé en el 2000, y mi portátil es un VAIO del 2010 al que añadí un SSD y va perfectamente fluido para tareas cotidianas.
#45 Pues todavía no le he puesto un SSD a mi portátil de 2008. Y el caso es que tengo uno de 240Gb por ahí, ...
#43 ¿O empezaste a usar software libre?
#58 A veces las cosas las vemos de una forma un poco relativa. El portátil va de maravilla, pero imagino que como cada vez me costaba más arrancar aplicaciones gráficas, el portátil se quedaba más para aplicaciones administrativas. Y por eso ahora uso una estación de trabajo gráfica.
Pero da igual: el portátil va de maravilla y ya tiene 11 años. Todos los componentes originales, sin añadirle SSD. Eso nunca lo había visto.
#43 No es que la ley de Moore pierda sentido (aún se cumple), es que los ordenadores de los 80 y 90 eran tan rematadamente lentos que un cambio de generación de CPUs/memorias/etc. significaba una burrada más de rendimiento. Los saltos de un 386 a un 486 o los Pentium eran la noche y el día.
Ahora para notar una mejora parecida necesitas varias generaciones de CPUs porque para tareas de escritorio como navegar, oficineo, etc. te vale casi cualquier cosa. El único salto realmente apreciable para el usuario han sido los SSDs. Por eso mucha gente ni tiene torre, tiran de portátiles ligeros que van sobradísimos. Antes era impensable.
A partir de mediados de los 00's que salvo para jugar ya te sirven máquinas de hace bastantes años.
#3 Mi primer PC, un 286, iba con módulos SIMM de 30 contactos.
#19 eso es mucho más antiguo. EDO apareció más o menos con los primeros Pentium.
#20 He pasado hasta por los RIMM
#21 bueno, yo empecé con un Amstrad fabricado en 1984 y no sé ni qué RAM tenía.
Edito: tenía 64 KiB (creía recordar que eran 32), pero ni idea de si era síncrona.
https://en.wikipedia.org/wiki/Amstrad_CPC_464
#22 Me refería a que a partir del 286 he pasado por todos los tipos de memoria (hasta la RIMM de los primeros p4 que era una estafa)
#23 esos no los recordaba.
#23 he mirado un poco y parece que eran un tipo de memoria síncrona, pero no pone nada de que fueran malos en los enlaces que he visto. ¿Por qué lo eran? Por curiosidad.
#25 Eran bastante caros y era algún rollo en plan serie, no me acuerdo muy bien pero en la carrera los estuvimos comparando y no entendíamos la decisión de intel, y al final pues pasaron a DDR
#25 Porque venían a revolucionar el mercado, de la mano de Intel (a precio de oro) y coincidió con la aparición de la memoria DDR de mejor rendimiento y más barata por lo que se comió un mojón.
Pero al principio de los Pentium4 si querías uno tenía que ser con memoria RIMM.
Eran muy rápidas en frecuencia para la época (800mhz) pero de tan solo 16bits, las memorias DDR era memoria SDRAM normal pero doble flanco (2 operaciones por ciclo de reloj) por lo que memorias de 100mhz rendían como si fueran 200mhz y con 64bits de ancho de palabra en lugar de 16.
Y si ya las ponías en una placa con doble canal de memoria se follaba a la memoria RDRAMM de mala manera.
#39 suena a que tenían que liquidar existencias de RIMM antes de empezar a vender DDR. Un clásico.
#39 El dual Channel para mí fue de lo mejorcito que hicieron
#23 Amén hermano!
#22 Yo empecé con módulos de ferrita, menos fiables que los USB de oferta del chino.
#1 ¡EDO RAM!. Estamos a la última.
Salu2
Ingeniero de Facebook que trabaja en el kernel de linux. Facebook hace algo bueno por la humanidad, eso si que es algo inesperado.
#8 Inesperado para nada, Facebook contribuye mucho código a la comunidad. Ha hecho un huevo de mejoras en PHP, rocksdb y cassandra son bases de datos de facebook, cgroups tiene muchísimo trabajo de gente de facebook, btrfs y del subsistema de redes hacen bastante.
Puede ser una empresa éticamente cuestionable a muchos niveles, pero en cuanto a contribuciones open source, sin ser Red Hat, es una empresa impecable, y su blog técnico, aunque en general es flojo, tiene alguna que otra joya.
#9 Aportaciones a PHP si me lo esperaba, pero no al kernel de linux.
#10 Cuando tienes tantas máquinas que además suelen ir bien exprimidas, vas a necesitar gente capaz de arreglar bugs del kernel si o si, y con el tamaño de facebook (google, twitter, netflix, etc.) es impensable comprar soporte a una empresa tipo Suse o Red Hat.
https://engineering.fb.com/open-source/improving-the-linux-kernel-with-upstream-contributions/
#10 Jest es de ellos y es de las mejores librerías de testing para JavaScript
#9 Facebook también mantiene librerías de software libre ampliamente usadas como React o PyTorch
#15 Iba a comentar lo de Pytorch porque es una puta maravilla
#44 Échale un vistazo a TensorFlow que ha sacado nueva versión
/****
*
* Nueva function malloc(): Nunca devuelve NULL
*
** **/
int * malloc()
#6 ¿Devolver una dirección de memoria aleatoria de los 64 primeros Kb? Echa CV en facebook, que vas para allá.
#29 Uno, que aprendió a programar en ordenadores con bus de memoria de 8 bits .
#50 que envidia, yo lo primero que toque (no era mío) fue un 8086 o un 8088, un familiar tenía un IBM con el basic en rom cuando no arrancabas con el disco del s.o. molaba bastante que saliera el entorno para programar.
#57 Un 8086 también tiene un bus de memoria de 8 bits (aunque por dentro los registros son de 16 bits).
Por eso, aunque tenías 1024 Kbytes de memoria (640 Kbytes de RAM, el resto de ROM), solo podías acceder a 64 Kbytes de memoria a la vez y había que estar paginando esos 64 Kbytes para acceder a toda la memoria disponible. En Basic o C eso se traducía en no poder tener una cadena con más de 65535 caracteres.
No fue hasta el 80286 que se generalizaron los buses de memoria de 16 bits: la famosa "memoria extendida" que conseguía ejecutar Windows, QEMM, etc.
#61 En aquella época como si hubiese sido de 4 pq tenía 6 años y lo máximo que sabía hacer era print, poner etiquetas y hacer el goto, pero me habría gustado encontrarme algo así en la uni (hicimos asm pero lo típico, 4 prácticas y te olvidas de todo) y sin necesidad de hacer virguerías con la memoria, y ya luego el nivel más bajo de programación fue C con gcc y pentiums y alguna sparc por lo que problemas de memoria no tuvimos.
#61 Te estás confundiendo con el 8088. El 8086 es de 16 bits por dentro y por fuera. La limitación a segmentos de 64KB no tiene nada que ver con el tamaño del bus de datos externo. El 80286 podía direccionar hasta 16MB (gracias a un incremento del bus de direcciones y la introducción del modo protegido) pero seguía limitado a segmentos de 64KB. No fue hasta el 80386, con sus registros de 32bits, que nos quitamos ese problema.
CC #57
#72 Yo ya no me acuerdo ni como funcionan los registros.
#6 Eso me recuerda un chiste de hace un tiempo acerca de la generación de números aleatorios: "https://xkcd.com/221/"
#40 https://dilbert.com/strip/2001-10-25
dilbert >> xkcd
#41 Pues a mí me parece mucho más gracioso el de xkcd.
Pues si Linux ya ahorraba mucha RAM, con esto va a salir a devolver.
#13 Ya te digo. El otro día preparé un portátil de 256Mb con SlitaZ y sorprendente aún rula decentemente para tener casi 20 años. Para trastear y para que jueguen los críos me vale.
Pd: Echo de menos a@Ander_ que me ayudó mucho hace 5 años con ese mismo portátil.
#55 Y tu no pillas la ironia .
Imposible. Linux es perfecto desde su concepcion. Es imposible optimizarlo más.
#32 ¿Hablas de GNU/Linux o del Kernel? El Kernel es perfecto punto, palabra de Torvalds.
#32 Se ve que no tienes idea. Linux está constantemente mejorando y cada nueva versión que sale es más liviana y más rápida. Ya se que eso va en contra de todo lo que cree la mayoría de la gente, que por culpa de los desarrollos chapuceros de las empresas de software comercial, creen que cada versión nueva tiene que ser siempre más pesada y lenta pero bueno...
Ya lo digo yo, esto a hacer este sea el año de linux en el escritorio
#16 Sí, pero en el de quién?
Toda optimización es bien recibida y celebrada.
Hace meses se habló que Linux dejaba mucho que desear en situaciones donde se quedaba sin RAM, se bloqueaba durante minutos, otros SOs como Windows respondían mejor... me pregunto si esta mejora es una respuesta a ese problema, o están trabajando en otras soluciones.
#18 Te explico qué pasa cuando el sistema se queda sin RAM
Primero una aclaración: es posible restringir la cantidad de RAM que se da a los usuarios. De esta forma el sistema operativo en sí siempre va a funcionar sin problemas y sólo será el usuario en particular que consumió demasiado al que le fallarán las cosas.
Por otro lado, cuando no hay límite de ram para los usuarios, lo que ocurre es que un programa puede consumir lo que le de la gana. Lo que hará el sistema para liberar memoria es ir desalojando progamas que no estén en uso y los enviará al swap (al disco). Esto es un proceso lento pero no queda otra. Cuando el programa pide más y más memoria el swap termina por llenarse. En esa situación cualquier programa que solicite memoria recibirá un error y si no lo atrapa, el sistema lo matará liberando su espacio. El problema es que no necesariamente será el programa que provocó el problema en un principio. Puede ser otro programa diferente que tuvo la mala suerte de pedir memoria cuando no había más.
Si dejamos que las cosas sigan su curso, eventualmente el programa que se comía la RAM terminará por morir pero no sin que antes el sistema haya matado varios otros y mandado al swap la mayoría con lo que funcionará todo lentísimo y hasta tal vez se nos muera el administrador de ventanas o quien sabe cuántas cosas que usamos en modo gráfico.
¿Solución? Pues... se puede restringir la memoria que usa cada programa. El problema es que a veces sí queremos que el programa pueda consumir todo lo que quiera. O podemos restringir la memoria que usa cada usuario. El problema es que en equipos de escritorio tenemos un solo usuario y quiere poder aprovechar toda la capacidad de su ordenador.
#54 Lo que me describes es el comportamiento normal de cualquier sistema operativo en esa situación (windows usara un fichero de intercambio en lugar de una partición swap, pero es lo mismo).
Pero por lo que leí en phoronix, un desarrollador denunció que Linux reacciona muy ineficientemente en esas situaciones, el ratón se paraliza durante minutos y el sistema empieza a usar el HDD como loco incluso con el SWAP desactivado, lo cual indica que hay algún bug y mala optimizacion por ahí.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Does-Bad-Low-RAM
A raíz de la discusión, empezaron a tomar medidas para mejorar la gestión de memoria.
https://www.phoronix.com/scan.php?page=news_item&px=Low-Memory-Monitor
#63 Linux reacciona muy ineficientemente en esas situaciones, el ratón se paraliza durante minutos
Sí, eso es normal. Ocurre que windows fue un sistema diseñado para el entorno gráfico. Habrás notado que jamás falla el ratón. O más bien que si falla el ratón es seguro que el sistema está completamente colgado. En Linux no es así. El entorno gráfico es una aplicación más, y para colmo es de las que están trabajando constantemente solicitando y liberando memoria.
Eso hace que cuando el sistema se quede sin memoria sea muy probable que una aplicación tan exigente como el entorno gráfico sea de las primeras que fallen mientras que cosas como servicios de red por ejemplo sigan funcionando razonablemente bien.
el sistema empieza a usar el HDD como loco incluso con el SWAP desactivado
Hummm.... yo sospecharía que es algo como que alguna aplicación murió porque pidió memoria y no había, y el sistema está tratando de arrancarla de nuevo una y otra vez y por eso accede mucho al disco. Para colmo al estar ocupada la memoria no hay caché de disco y todas las lecturas tienen que hacerse de verdad. Tal vez incluso parte del acceso sean grabaciones en logs registrando las fallas.
De todas formas, no se recomienda trabajar sin swap incluso teniendo memoria de sobra. Linux utiliza el swap para desgragmentar la memoria.
En fin... por suerte hoy en día los ordenadores vienen preparados para windows 10 así que traen memoria más que de sobra para cualquier uso normal en linux.
Bueno, yo empece con un Commodore VIC-20(4k de ram) del colegio a los 11 años.
Luego mi primer pc en propiedad, un Sony HitBit MSX.
Mi primer PC de "verdad", un clonico 386, despues 486, pentium, etc..
Sobre Linux, se ha dicho que cada vez es mas "libiano", pues no se como lo consigue porque antes una distro "completa" te cabia en 24 diskettes 1.44M (slackware 1 para mas señas). Que va muy bien el linux es obvio, cuando lo usan los 100 primeros supercomputadores del mundo, la nasa, ibm google y hasta MS, malo no será, pero de ahi a decir que cada vez es mas ligero, pues va a ser que no.
Los recursos estan para consumirlos, para eso los has pagado. Si no los quieres usar damelos que ya me encargo de usarlo, bueno yo o algun script para mineria.
Lo que no es de recibo es consumirlos porque nadie sabe/quiere optimizarlo.
Hoy en dia se programa "independientemente de la maquina", que muchos entienden como "con recursos infinitos",
Ademas es mas "barato" invertir y renovar hardware que en formacion y pagar a buenos programadores.
Me gustaria saber como lo harian los programadores estandar de hoy en los 80. Es mas a mi que lo he vivido ya me costaria un cojon.
Supongo que esto puede ir genial en máquinas de pocas prestaciones tipo antiguas raspberrys y similares, o netbook de hace 10 años con 1GB RAM para todo el sistema operativo.
Solo si se usa ----->> SLAB
¿Pero no deciais los proplayers de
LInuxperodon GNU-Linux que memoria ram sin usar es memoria ram desperdiciada?#35 Si vas a trollear al menos que sea con un mínimo de conocimiento. El cacheo que hace Linux no liberando memoria disponible y dejandola como caché también lo hace windows desde hace muchos años.
#35 Claro. La memoria que no se use para aplicaciones se aprovecha como caché de disco. Cuanta menos RAM usen tus programas más rápido irá el acceso a disco.