Re: pregunta sobre el nucli Linux
Hola, Potser no ha quedat clar com ho he explicat, intento fer-ho millor. Al que m'estava referint és que el oom-killer està protegint el sistema contra la denegació de servei que provocaria que no hi hagi memòria disponible per un procés (d'usuari). En el cas d'esgotar tota la memòria i solicitar-ne més el oom-killer s'invocaria alliberant memòria a base de matar un algún procés (segons unes regles predefinides). És a dir, contesta la pregunta que ha formulat l'Alex: (3) Per què un sistema operatiu multiusuari no ve de sortida més protegit per que el procés d'un usuari no es mengi tota la ram causan una denegació de servei a la resta ? Sobre l'enunciat de la pregunta hauriem d'aclarir també que el fet que un procés consumeixi tota la memòria del sistema no es intrínsecament dolent, per tant prohibir-ho per tots els casos no té sentit. Un usuari podria tenir una màquina que executa un sol procés que utilitza exactament tota la memoria però sense passar-se. Creieu que s'ha de denegar aquest comportament unilateralment?? Interpreto que quan et refereixes al "problema del company" vols dir que el Firefox (o qualsevol altre procés d'usuari de la máquina) tingui la possibilitat d'utilitzar tota la RAM del sistema. Això seria una cosa diferent a la denegació de servei per quedar-te sense RAM (i swap en cas d'haver-hi) i per gestionar-ho hi ha altres eines com ulimit, cgroups, ... En la majoria de distribucions (incloses Debian i Ubuntu) els límits per defecte són molt laxos però, no és responsabilitat de l'usuari (administrador) de la máquina configurar aquesta com desitgi?? Si estàs pensant que el oom-killer hauria d'haver matat el Firefox, segons el que ens expliquen probablement hauria d'haver passat, però també és possible que no s'hagués exhaurit tota la memòria sinó que s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha arribat a cridar el oom-killer. En aquest escenari el Firefox intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo que ha decidit l'usuari de la màquina. T'encaixa ara?? Contestant a les teves preguntes sobre el codi del OOM: El significat que has suposat de les abreviacions és correcte. En quan al trosset de codi [2], l'objectiu de la funció on està escrit això és donar una puntuació pel procés sobre el que li han preguntat. Aquesta puntuació és una funció (en el sentit matemàtic) que utiliza diferents paràmetres sobre l'espai de memòria del procés (rss, swap, taula de pàgines,...). Per poder consultar aquestes dades necessita el punter a l'esctructura mm_struct i per trobar aquest punter crida a la funció "find_lock_task_mm()". Salutacions, Jordi -- -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El sáb, 2 oct 2021 a las 20:14, pedeb () escribió: > > Hola Jordi, > > sembla que això de oom_killer és una cosa que té múltiples > configuracions i que s'ha d'ajustar, però que té uns ajustos genèrics i > no veig gaire raonable per evitar el problema que comenta el company > [0], o estic equivocat. > > també he trobat [1] (això ho trobo molt interessant Alex) > > i independentment d'això, ja que has apuntat el codi font, si em pots > ajudar a entendre: > > què vol dir literalment la variable adj: adjustment? > > què vol dir literalment la mm: memory management?, ien aquest context [2] ? > > Gràcies! > Pedro > > [0] > https://www.percona.com/blog/2019/08/02/out-of-memory-killer-or-savior/ > https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-oom-killer.html >que ve de > https://juantrucupei.wordpress.com/2017/04/03/desactivar-oom-killer-out-of-memory-killer/ > > [1] > https://dev.to/msugakov/taking-firefox-memory-usage-under-control-on-linux-4b02 > > [2] > p = find_lock_task_mm(p); > if (!p) > return LONG_MIN; > > On 10/2/21 3:02 PM, Jordi Miguel wrote: > > Hola, > > > > Sobre el tema del límit d'usuaris per les aplicacions de Google Drive > > (Docs, Sheets, Slides), Google diu el següent: > > > > Share & collaborate on a file with more than 100 people > > Up to 100 people with view, edit, or comment permissions can work on a > > Google Docs, Sheets, or Slides file at the same time. When more than > > 100 people are accessing a file, only the owner and some users with > > editing permissions can edit the file. > > > > Podeu veure la informació completa aquí[1] amb les solucions que > > proposen per compartir amb més de 100 persones. Potser seria > > interessant que ens comentessis com vas compartir aquesta presentació: > > quins permisos tenies tu sobre la presentació? els alumnes tenien el > > mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes > > només tenia permisos com a lector ?? Pots reproduir el problema si > > comparteixes la presentació de la manera que es proposa a la > > documentació de Google ?? > > > > Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino > > que tindràs extensions i/o temes carregats. El primer pas seria >
Re: Bug a la instal·lació de postgresql?
Missatge de Alex Muntada del dia dv., 1 d’oct. 2021 a les 23:37: > Hola, Julio > > > el problema amb Kerberos, és que si no fas un kdestroy o > > l'elimines manualment de /tmp dura no se quantes hores i per > > tant amb l'ordre que hem esmentat pots fer ... > > No entenc quina relació té l'expiració de sessions de kerberos > amb el fet de no permetre que l'usuari root executi el su que > vulgui. Ara ja sabem que també hi ha runuser i, mirant la seva > pàgina de man, he vist que també hi ha setpriv, que ni tan sols > utilitza pam. > La idea és: - els usuaris del grup A fan servir els seus ordinadors amb un compte ordinari ( contra un ldap+kerberos) i amb el compte root local. - els usuaris del grup B no han de fer servir el seu compte als ordinadors del grup A, i ja estan avisats, però sempre hi ha algun despistat. Quan un d'aquests despistats del grup B, es logueja i s'oblida de fer kdestroy, el tiquet de kerberos roman durant unes hores a l'ordinador i en aquest moment, qualsevol usuari amb el compte local de root pot fer un `su -l usuari_despistat_del_grup_B` No sé si m'explico :) Julio -- __ - El 2003 el català era la llengua habitual del 46 % dels catalans. Al 2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà. - El 3 de novembre representa el moment de l'any en el que les dones deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a eliminar aquesta data. - L’administració pública cada any es gasta milions d’euros en llicències de programari privatiu. Utilitzant programari lliure estalviem costos i incentivem l’economia local. *La neutralitat davant les desigualtats acaba accentuant-les.*
Re: Debian 11 estable en poques hores
On Sat, 2 Oct 2021 at 20:40, Eduard Selma wrote: > El 2/10/21 a les 17:20, Narcis Garcia ha escrit: > > El 2/10/21 a les 11:33, Ernest Adrogué ha escrit: > >> 2021-09-14, 20:52 (+0200); Joan Montané escriu: > >>> Què vull dir amb això? > >>> Debian és molt més que el terminal. > >>> Canviar les abreviatures dels mesos a «ls» afecta a tot el sistema. > >> > >> A quin altre lloc s'utilitzen els mesos de l'any en format abreviat? > >> Algun programa d'interfície gràfica en concret? Jo no n'he trobat cap. > >> Que jo sàpiga, aquest format només té sentit en programes de terminal de > >> text, on l'espai és limitat. I en un context on hi ha una limitació > >> d'espai, no és desitjable malgastar aquest espai amb preposicions i > >> puntuació innecessària. Tres caràcters per identificar el mes de l'any > >> és suficient i adequat, i evita els previsibles problemes de falta > >> d'alineació. És el que fan tots els altres idiomes. Algun altre idioma > >> utilitza abreviatures de mes de llargada variable? > > > > > > + 1 altre a favor de les 3 lletres (GEN, FEB, MAR, ABR, MAI, JUN, JUL, > AGO, SET, OCT, NOV i DES). Com als datadors de goma. Tan difícil és? > He consultat una publicació que és força útil https://llengua.gencat.cat/web/.content/documents/publicacions/btpl/arxius/28-btpl-abreviacions.pdf i he descobert que, a més de les abreviacions de mes, n'indiquen símbols de dues lletres: GN, FB, MÇ, AB, MG, JN, JL, AG, ST, OC, NV, DS i de llargada fixa! Potser es podrien usar aquestos? > > Salut i codi lliure, > > Eduard Selma. > > -- -- Salutacions...Josep --
Re: Debian 11 estable en poques hores
El 2/10/21 a les 17:20, Narcis Garcia ha escrit: El 2/10/21 a les 11:33, Ernest Adrogué ha escrit: 2021-09-14, 20:52 (+0200); Joan Montané escriu: Què vull dir amb això? Debian és molt més que el terminal. Canviar les abreviatures dels mesos a «ls» afecta a tot el sistema. A quin altre lloc s'utilitzen els mesos de l'any en format abreviat? Algun programa d'interfície gràfica en concret? Jo no n'he trobat cap. Que jo sàpiga, aquest format només té sentit en programes de terminal de text, on l'espai és limitat. I en un context on hi ha una limitació d'espai, no és desitjable malgastar aquest espai amb preposicions i puntuació innecessària. Tres caràcters per identificar el mes de l'any és suficient i adequat, i evita els previsibles problemes de falta d'alineació. És el que fan tots els altres idiomes. Algun altre idioma utilitza abreviatures de mes de llargada variable? + 1 altre a favor de les 3 lletres (GEN, FEB, MAR, ABR, MAI, JUN, JUL, AGO, SET, OCT, NOV i DES). Com als datadors de goma. Tan difícil és? Salut i codi lliure, Eduard Selma.
Re: Debian 11 estable en poques hores
El 2/10/21 a les 11:44, Joan ha escrit: El Thu, 19 Aug 2021 22:55:06 +0200 Eduard Selma va escriure: El 18/8/21 a les 18:12, Narcís Garcia ha escrit: El 17/8/21 a les 14:11, Eduard Selma ha escrit: - L'instal·lador Calamares (omnipresent) naturalment, no permet fer entrades de particions "a mida" (com /data, /back, etc) tal com feia l'instal·lador antic Debian; només les estàndard (/boot, /var, /home, etc.) Cal fer blkid i entrar-ho manualment un cop instal·lat. cap problema, però. Em sembla que amb l'arrencada de DebianInstaller (sense escriptori gràfic ni Calamares) segueix podent-se fer de tot amb les particions, LVM, RAID, LUKS... - Segurament, i celebro que sigui així, perquè sempre havia fet la instal·lació en mode text, ràpid, flexible i clar. Però resulta que, sense haver afegit nou maquinari, l'instal·lador es queixava de no tenir els controladors de firmware privatius (rt2561.bin i rt8168e-3.fw) i es negava a continuar. Inserint un segon USB (la instal·lació també la feia des de USB, crec que no usava DVD des de Stretch) amb els controladors privatius, no el trobava. Per tant, *vaig baixar un Debian-install_live amb firmware no lliure, que es va* *instal·lar a la primera.* Hi ha una versió d'instal·lador de debian amb els controladors privatius... És molt més còmoda que no pas haver d'usar un USB, etc. - Sí, aquesta versió és la que vaig usar. I és lal que porta l'instal·lador Calamares, a diferència del Debian normal. Salut i codi lliure, Eduard Selma.
Re: pregunta sobre el nucli Linux
Hola Jordi, sembla que això de oom_killer és una cosa que té múltiples configuracions i que s'ha d'ajustar, però que té uns ajustos genèrics i no veig gaire raonable per evitar el problema que comenta el company [0], o estic equivocat. també he trobat [1] (això ho trobo molt interessant Alex) i independentment d'això, ja que has apuntat el codi font, si em pots ajudar a entendre: què vol dir literalment la variable adj: adjustment? què vol dir literalment la mm: memory management?, ien aquest context [2] ? Gràcies! Pedro [0] https://www.percona.com/blog/2019/08/02/out-of-memory-killer-or-savior/ https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-oom-killer.html que ve de https://juantrucupei.wordpress.com/2017/04/03/desactivar-oom-killer-out-of-memory-killer/ [1] https://dev.to/msugakov/taking-firefox-memory-usage-under-control-on-linux-4b02 [2] p = find_lock_task_mm(p); if (!p) return LONG_MIN; On 10/2/21 3:02 PM, Jordi Miguel wrote: Hola, Sobre el tema del límit d'usuaris per les aplicacions de Google Drive (Docs, Sheets, Slides), Google diu el següent: Share & collaborate on a file with more than 100 people Up to 100 people with view, edit, or comment permissions can work on a Google Docs, Sheets, or Slides file at the same time. When more than 100 people are accessing a file, only the owner and some users with editing permissions can edit the file. Podeu veure la informació completa aquí[1] amb les solucions que proposen per compartir amb més de 100 persones. Potser seria interessant que ens comentessis com vas compartir aquesta presentació: quins permisos tenies tu sobre la presentació? els alumnes tenien el mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes només tenia permisos com a lector ?? Pots reproduir el problema si comparteixes la presentació de la manera que es proposa a la documentació de Google ?? Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino que tindràs extensions i/o temes carregats. El primer pas seria intentar reproduir el mateix problema utilitzant el safe mode (e.g. # firefox --safe-mode ) ?? Si en safe mode el Firefox es comporta correctament hauries d'anar activant/desactivant extensions fins que trobis quina provoca que el consum es dispari. En quant el tema de control de memòria per part del kernel ja has vist en la teva cerca per Internet que tens diverses opcions disponibles (ulimit, cgroups, ...). La funció de protecció que busques opino que la compleix el OOM-killer (out-of-memory killer). Podeu veure com funciona mirant el codi font [2]. Quan aquest procés s'activa registra el que ha fet al dmesg. Si realment es va consumir tota la memòria pots revisar quin o quins processos va matar el OOM-killer mirant els logs. [1] https://support.google.com/drive/answer/2494822?hl=en [2] https://github.com/torvalds/linux/blob/master/mm/oom_kill.c#L195 Salutacions, Jordi -- El sáb, 2 oct 2021 a las 13:28, Àlex () escribió: Em crida molt l'atenció que Google Slides faci petar el navegador quan es comparteix una presentació amb 100 persones. No és tant quan 100 persones obren el document, com quan un d'ells fa clic al botó d'iniciar reproducció. Quan moltes persones tenen el document obert el sistema no tenía més que 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per què? No ho sé. Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0 No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS. Fa uns dies que veig que els llocs de Google funcionen millor amb Chromium que amb Firefox. Potser només passa amb Firefox. Però de les tres preguntes que sorgeixen ... (1) Per què passa això a Google Slides ? (2) Per què els navegadors no controlen quan una pestanya es menja tota la RAM del sistema per avisar l'usuari si la vol bloquejar ? (3) Per què un sistema operatiu multiusuari no ve de sortida més protegit per que el procés d'un usuari no es mengi tota la ram causan una denegació de servei a la resta ? ... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1)
Re: pregunta sobre el nucli Linux
El 2/10/21 a les 13:28, Àlex ha escrit: > Fa uns dies que veig que els llocs de Google funcionen millor amb > Chromium que amb Firefox. Potser només passa amb Firefox. Naturalment quan es tracta d'aquest tipus de corporació. També passa que els llocs de Microsoft funcionen millor amb navegadors de Microsoft que amb d'altres. -- __ I'm using this express-made address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
Re: Debian 11 estable en poques hores
El 2/10/21 a les 11:33, Ernest Adrogué ha escrit: > 2021-09-14, 20:52 (+0200); Joan Montané escriu: >> Què vull dir amb això? >> Debian és molt més que el terminal. >> Canviar les abreviatures dels mesos a «ls» afecta a tot el sistema. > > A quin altre lloc s'utilitzen els mesos de l'any en format abreviat? > Algun programa d'interfície gràfica en concret? Jo no n'he trobat cap. > Que jo sàpiga, aquest format només té sentit en programes de terminal de > text, on l'espai és limitat. I en un context on hi ha una limitació > d'espai, no és desitjable malgastar aquest espai amb preposicions i > puntuació innecessària. Tres caràcters per identificar el mes de l'any > és suficient i adequat, i evita els previsibles problemes de falta > d'alineació. És el que fan tots els altres idiomes. Algun altre idioma > utilitza abreviatures de mes de llargada variable? +1 >> L'opció triada és una solució de compromís que no és ideal, però és >> millor (quan s'apliqui) que la situació dels darrers 4 anys. > > No és veritat que això sigui una solució de compromís. Compromís vol > dir que les parts que estan en desacord renuncien a alguna de les seves > pretensions. Mentre que, aquí, una part no ha renunciat a cap de les > seves pretensions, i en canvi ha aplicat tot de canvis al local > unilateralment, i l'altra part ha estat obligada a acceptar aquests > canvis sense que se l'hagi tingut en compte. > > Salutacions. > -- __ I'm using this express-made address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
Re: pregunta sobre el nucli Linux
Bones, No coneixo massa tema però sé que els contenidors i tecnologies com docker i kubernetes fan servir cgroups per controlar els recursos que es reserven per cada contenidor: https://www.man7.org/linux/man-pages/man7/cgroups.7.html signature.asc Description: PGP signature
Re: Debian 11 estable en poques hores
Hola, Sóc l'Aleix. No sé si havia escrit abans a la llista, tot i que porto força temps llegint-la, així que, saludo breument. El ds., 2 d’oct. 2021, 11:33, Ernest Adrogué va escriure: > > > L'opció triada és una solució de compromís que no és ideal, però és > > millor (quan s'apliqui) que la situació dels darrers 4 anys. > > No és veritat que això sigui una solució de compromís. Compromís vol > dir que les parts que estan en desacord renuncien a alguna de les seves > pretensions. Mentre que, aquí, una part no ha renunciat a cap de les > seves pretensions, i en canvi ha aplicat tot de canvis al local > unilateralment, i l'altra part ha estat obligada a acceptar aquests > canvis sense que se l'hagi tingut en compte. > Fixa't en els parèntesis: "quan s'apliqui". Diria que la solució de compromís encara no s'ha aplicat, per tant entenc que estàs valorant una situació que no es correspon a la que deia en Joan. D'altra banda "de compromís" al meu entendre no significa el que tu exposes, sinó una opció que no és bona, perquè compromet, posa en risc, alguna cosa. No hauria de ser definitiva perquè no és una bona solució. *4 **2* [LC] *de compromís** loc. adj. *Que pot comprometre o ésser compromès si no és tractat o resolt com cal. Per tant, entenc que sí, serà una solució de compromís (quan s'apliqui, clar).
Re: pregunta sobre el nucli Linux
Hola, Sobre el tema del límit d'usuaris per les aplicacions de Google Drive (Docs, Sheets, Slides), Google diu el següent: Share & collaborate on a file with more than 100 people Up to 100 people with view, edit, or comment permissions can work on a Google Docs, Sheets, or Slides file at the same time. When more than 100 people are accessing a file, only the owner and some users with editing permissions can edit the file. Podeu veure la informació completa aquí[1] amb les solucions que proposen per compartir amb més de 100 persones. Potser seria interessant que ens comentessis com vas compartir aquesta presentació: quins permisos tenies tu sobre la presentació? els alumnes tenien el mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes només tenia permisos com a lector ?? Pots reproduir el problema si comparteixes la presentació de la manera que es proposa a la documentació de Google ?? Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino que tindràs extensions i/o temes carregats. El primer pas seria intentar reproduir el mateix problema utilitzant el safe mode (e.g. # firefox --safe-mode ) ?? Si en safe mode el Firefox es comporta correctament hauries d'anar activant/desactivant extensions fins que trobis quina provoca que el consum es dispari. En quant el tema de control de memòria per part del kernel ja has vist en la teva cerca per Internet que tens diverses opcions disponibles (ulimit, cgroups, ...). La funció de protecció que busques opino que la compleix el OOM-killer (out-of-memory killer). Podeu veure com funciona mirant el codi font [2]. Quan aquest procés s'activa registra el que ha fet al dmesg. Si realment es va consumir tota la memòria pots revisar quin o quins processos va matar el OOM-killer mirant els logs. [1] https://support.google.com/drive/answer/2494822?hl=en [2] https://github.com/torvalds/linux/blob/master/mm/oom_kill.c#L195 Salutacions, Jordi -- El sáb, 2 oct 2021 a las 13:28, Àlex () escribió: > > > > Em crida molt l'atenció que Google Slides faci petar el navegador quan > > es comparteix una presentació amb 100 persones. > > > No és tant quan 100 persones obren el document, com quan un d'ells fa > clic al botó d'iniciar reproducció. > > Quan moltes persones tenen el document obert el sistema no tenía més que > 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al > botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per > què? No ho sé. > > Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0 > > No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS. > > Fa uns dies que veig que els llocs de Google funcionen millor amb > Chromium que amb Firefox. Potser només passa amb Firefox. > > Però de les tres preguntes que sorgeixen ... > > (1) Per què passa això a Google Slides ? > > (2) Per què els navegadors no controlen quan una pestanya es menja tota > la RAM del sistema per avisar l'usuari si la vol bloquejar ? > > (3) Per què un sistema operatiu multiusuari no ve de sortida més > protegit per que el procés d'un usuari no es mengi tota la ram causan > una denegació de servei a la resta ? > > ... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1) >
Re: pregunta sobre el nucli Linux
Em crida molt l'atenció que Google Slides faci petar el navegador quan es comparteix una presentació amb 100 persones. No és tant quan 100 persones obren el document, com quan un d'ells fa clic al botó d'iniciar reproducció. Quan moltes persones tenen el document obert el sistema no tenía més que 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per què? No ho sé. Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0 No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS. Fa uns dies que veig que els llocs de Google funcionen millor amb Chromium que amb Firefox. Potser només passa amb Firefox. Però de les tres preguntes que sorgeixen ... (1) Per què passa això a Google Slides ? (2) Per què els navegadors no controlen quan una pestanya es menja tota la RAM del sistema per avisar l'usuari si la vol bloquejar ? (3) Per què un sistema operatiu multiusuari no ve de sortida més protegit per que el procés d'un usuari no es mengi tota la ram causan una denegació de servei a la resta ? ... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1)
Re: pregunta sobre el nucli Linux
El 2/10/21 a les 12:07, Àlex ha escrit: [...] L'atac ha estat amb Google Slides i sembla fàcil de reproduir. Algú em va passar una presentació de Google Slides i, enlloc de passar-ho a pdf, vaig compartir l'enllaç de la presentació amb 25 alumnes. Fins aquí res anormal. Els 25 alumnes van obrir la presentació al seu ordinador. Un alumne per fer la gracia va posar la URL en una pàgina que obria moltes URLs automàticament alhora, així que realment aquella presentació estava oberta o compartida per 100 persones o pestanyes de navegadors. Fins aquí tot funcionava bé. Però en el moment que algú feia clic al botó d'iniciar presentació, Firefox en menys d'un segon reclamava tota la memòria del sistema (16Gb ram + 4 gb swap), i el sistema deixava de respondre. Em crida molt l'atenció que Google Slides faci petar el navegador quan es comparteix una presentació amb 100 persones. No conec l'eina, però venint de Google que en general presumeix de milions d'usuaris, un límit tan baix realment crida l'atenció. Entenc que aquí el problema ve del fet que abans que el nucli comenci a fer "neteja" quan s'exhaureix la memòria, és que precisament l'ha d'exhaurir, i això inclou la swap. El primer que fa és passar a disc la memòria amb menys ús, i mentre ho fa t'alentirà desesperadament l'ordinador. Una possible mitigació que crec que et podria ser útil en el teu escenari seria desactivar la swap. Pots fer-ho en viu, amb "swapoff -a", sense necessitat de cap reinici, i la pots rehabilitar de nou amb "swapon -a", assumint que la tens configurada a /etc/fstab (si tens una configuració personalitzada de swap, passa com a paràmetre el(s) dispositiu(s) de bloc). No t'evita realment l'atac DOS, però sí que penso que et permetria recuperar més ràpidament el control, doncs Firefox acabaria o bé petant per si mateix al no poder aconseguir més memòria o el nucli el mataria per alliberar-ne.
OT: Missatges descojunturats a Protonmail
Hola Robert, Veig que uses protonmail. Et puc preguntar si tens problemes de desconfiguració del text en els missatges que et responen o reenvien amb text citat? Tinc una amiga a la que li passa amb els meus missatges, i imagino que hi ha d'haver alguna opció de configuració perquè entengui bé els missatges de text. I, més en general, amb la merda de missatges de mail en format html, més els sistemes de mostrar-los de fills de cada Gmail o Outllok, etc (tot el contrari de la simple i pura estandarització), sembla mentida que els que usem el format text, que mira que més senzill no pot ser, tinguem problemes :-) -- Joan Cervan i Andreu http://personal.calbasi.net "El meu paper no és transformar el món ni l'home sinó, potser, el de ser útil, des del meu lloc, als pocs valors sense els quals un món no val la pena viure'l" A. Camus i pels que teniu fe: "Déu no és la Veritat, la Veritat és Déu" Gandhi "Donar exemple no és la principal manera de influir sobre els altres; es la única manera" Albert Einstein “Lluitarem contra el fort mentre siguem febles i contra nosaltres mateixos quan siguem forts” Lluís Maria Xirinacs El Wed, 18 Aug 2021 16:53:18 + robert marsellés va escriure: > Hola, > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, August 18th, 2021 at 18:12, Narcis Garcia > wrote: > > > El 17/8/21 a les 14:11, Eduard Selma ha escrit: > > > > > - L'instal·lador Calamares (omnipresent) naturalment, no permet > > > fer > > > > > > entrades de particions "a mida" (com /data, /back, etc) tal > > > com feia > > > > > > l'instal·lador antic Debian; només les estàndard (/boot, > > > /var, /home, > > > > > > etc.) Cal fer blkid i entrar-ho manualment un cop instal·lat. > > > cap > > > > > > problema, però. > > > > Em sembla que amb l'arrencada de DebianInstaller (sense escriptori > > > > gràfic ni Calamares) segueix podent-se fer de tot amb les > > particions, > > > > LVM, RAID, LUKS... > > > > Pel que diu la pàgina web a la secció "Want to give it a try? [1], > "Calamares" està únicament a la versió "live": "The live image > includes the Calamares independent installer as well as the standard > Debian Installer." Entenc que es deu poder triar quin instal·lador es > vol o s'utilitza una còpia de Bullseye "normal" (no-live) que tindrà > únicament l'instal·lador estàndar "Debian Installer". A les "release > notes" [2], es diu que l'instal·lador oficial és el "Debian > Installer" que està als CDs, DVDs, ... [2], no diu rés de la versió > "live". > > Per altra banda, al mateix document es recomana passar a Bullseye a > partir d'un sistema el més "net" (entenc estàndard) possible de > paquets. És a dir, s'elimina tot allò que no és estàndard > (guardant-ne la configuració) i, un cop finalitzat el procés, després > es torna a instal·lar el que vulgui [3]. > > Salut i peles, > > robert > > > [1] https://www.debian.org/News/2021/20210814 > [2] > https://www.debian.org/releases/bullseye/amd64/release-notes/ch-installing.es.html > [3] > https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.es.html#system-status > -- Joan Cervan i Andreu http://personal.calbasi.net "El meu paper no és transformar el món ni l'home sinó, potser, el de ser útil, des del meu lloc, als pocs valors sense els quals un món no val la pena viure'l" A. Camus i pels que teniu fe: "Déu no és la Veritat, la Veritat és Déu" Gandhi "Donar exemple no és la principal manera de influir sobre els altres; es la única manera" Albert Einstein “Lluitarem contra el fort mentre siguem febles i contra nosaltres mateixos quan siguem forts” Lluís Maria Xirinacs
Re: pregunta sobre el nucli Linux
El 1/10/21 a les 23:16, pedeb ha escrit: dona'ns detalls de l'arquitectura: - amb quina eina has fet la presentació (alguna cosa a sobre de firefox, oi? quina) - com visualitzen els alumnes la teva presentació: esteu en una mateixa aula (xarxa local) i ho veuen per un projector o en remot (i els alumnes amb els portàtils) qualsevol descripció adicional que afegeixis millor, en seguretat sempre s'ha de tenir en compte el major detall possible Bones L'atac ha estat curiós i NO ha estat des d'una pàgina que els alumnes controlaven, i us ho explicaré a continuació. Però a mi no m'interesa l'atac sino el fet que qualsevol aplicació sense permisos pugui tirar al terra tot un sistema tan sols reclamant més RAM que la que el sistema té. Es pot tractar una aplicació maliciosa de poques línies, però també pot ser una aplicació normal com un navegador que visita una web que li demana tota la RAM. Si des de fa anys els sistemes operatius per defecte venen protegits contra bombes fork , crec que per defecte també haurien de venir protegits contra aquest altre tipus de problemes, especialment amb lo "irresponsiu" que es torna l'escriptori de Linux quan esgotem la RAM. I si els navegadors per defecte venen protegits contra codi javascript que es torna irresponsiu, també haurien de venir protegits contra codi javascript que fa que la memòria usada pel procés estigui esgotant la memòria del sistema. L'atac ha estat amb Google Slides i sembla fàcil de reproduir. Algú em va passar una presentació de Google Slides i, enlloc de passar-ho a pdf, vaig compartir l'enllaç de la presentació amb 25 alumnes. Fins aquí res anormal. Els 25 alumnes van obrir la presentació al seu ordinador. Un alumne per fer la gracia va posar la URL en una pàgina que obria moltes URLs automàticament alhora, així que realment aquella presentació estava oberta o compartida per 100 persones o pestanyes de navegadors. Fins aquí tot funcionava bé. Però en el moment que algú feia clic al botó d'iniciar presentació, Firefox en menys d'un segon reclamava tota la memòria del sistema (16Gb ram + 4 gb swap), i el sistema deixava de respondre. Suposo que qualsevol atacant pot crear codi maliciós que faci quelcom semblant, i deixar-ho en pàgines d'internet o anuncis inserits en pàgines de tercers. Salutacions Àlex
Re: Debian 11 estable en poques hores
El Thu, 19 Aug 2021 22:55:06 +0200 Eduard Selma va escriure: > El 18/8/21 a les 18:12, Narcís Garcia ha escrit: > > El 17/8/21 a les 14:11, Eduard Selma ha escrit: > >> - L'instal·lador Calamares (omnipresent) naturalment, no permet fer > >> entrades de particions "a mida" (com /data, /back, etc) tal com > >> feia l'instal·lador antic Debian; només les estàndard (/boot, > >> /var, /home, etc.) Cal fer blkid i entrar-ho manualment un cop > >> instal·lat. cap problema, però. > > > > Em sembla que amb l'arrencada de DebianInstaller (sense escriptori > > gràfic ni Calamares) segueix podent-se fer de tot amb les > > particions, LVM, RAID, LUKS... > > - Segurament, i celebro que sigui així, perquè sempre havia fet la > instal·lació en mode text, ràpid, flexible i clar. Però resulta que, > sense haver afegit nou maquinari, l'instal·lador es queixava de no > tenir els controladors de firmware privatius (rt2561.bin i > rt8168e-3.fw) i es negava a continuar. Inserint un segon USB (la > instal·lació també la feia des de USB, crec que no usava DVD des de > Stretch) amb els controladors privatius, no el trobava. Per tant, > vaig baixar un debian-install_live amb firmware no lliure, que es va > instal·lar a la primera. Hi ha una versió d'instal·lador de debian amb els controladors privatius... És molt més còmoda que no pas haver d'usar un USB, etc. > > No he pogut contestar fins avui perquè alguns correus de la llista > els havia retingut el filtre de spam de Tinet. espero que el remitent > ara estigui a la llista blanc. > > Gràcies per les respostes. Salut i codi lliure, > > > Eduard Selma. > -- Joan Cervan i Andreu http://personal.calbasi.net "El meu paper no és transformar el món ni l'home sinó, potser, el de ser útil, des del meu lloc, als pocs valors sense els quals un món no val la pena viure'l" A. Camus i pels que teniu fe: "Déu no és la Veritat, la Veritat és Déu" Gandhi "Donar exemple no és la principal manera de influir sobre els altres; es la única manera" Albert Einstein “Lluitarem contra el fort mentre siguem febles i contra nosaltres mateixos quan siguem forts” Lluís Maria Xirinacs
Re: Debian 11 estable en poques hores
2021-09-14, 20:52 (+0200); Joan Montané escriu: > Què vull dir amb això? > Debian és molt més que el terminal. > Canviar les abreviatures dels mesos a «ls» afecta a tot el sistema. A quin altre lloc s'utilitzen els mesos de l'any en format abreviat? Algun programa d'interfície gràfica en concret? Jo no n'he trobat cap. Que jo sàpiga, aquest format només té sentit en programes de terminal de text, on l'espai és limitat. I en un context on hi ha una limitació d'espai, no és desitjable malgastar aquest espai amb preposicions i puntuació innecessària. Tres caràcters per identificar el mes de l'any és suficient i adequat, i evita els previsibles problemes de falta d'alineació. És el que fan tots els altres idiomes. Algun altre idioma utilitza abreviatures de mes de llargada variable? > L'opció triada és una solució de compromís que no és ideal, però és > millor (quan s'apliqui) que la situació dels darrers 4 anys. No és veritat que això sigui una solució de compromís. Compromís vol dir que les parts que estan en desacord renuncien a alguna de les seves pretensions. Mentre que, aquí, una part no ha renunciat a cap de les seves pretensions, i en canvi ha aplicat tot de canvis al local unilateralment, i l'altra part ha estat obligada a acceptar aquests canvis sense que se l'hagi tingut en compte. Salutacions.
