Re: Per risparmiare energia elettrica
On Mon, Feb 21, 2022 at 09:13:56PM +0100, Alessandro Rubini wrote: > Gli anglofoni lo chiamano "greenwashing". Io lo chiamo stronzata > galattica. [...] Quoto al 100% e aggiungo: "toccate" un header in un programma in C/C++ e poi avete la CPU che usa tutta l'energia a disposizione (e potete immaginare il consumo) per ricompilare inutilmente tutto (e andate a bervi un caffé nel frattempo). Durante lo sviluppo, questa operazione quante volte viene ripetuta? Poi usate il freepascal che (come il turbopascal ... notare la parte "turbo") ricompila tutto in 1/100 del tempo ricompilando solo ciò che serve ... Per un esempio recentemente qualcuno ha pensato di solamente riordinare le dipendenze del kernel di linux ottenendo un miglioramento nei tempi di compilazione a due zeri: https://www.phoronix.com/scan.php?page=news_item=Linux-Fast-Kernel-Headers Quindi il Pascal (forse quello GNU si però) non merita quella posizione ma sicuramente, come già detto dal buon Alex, nessuno dei linguaggi interpretati e soprattutto non il Perl. > > https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf > > lo candidiamo per ignobel? +1 -- Saluton, Marco Ciampa
Re: Per risparmiare energia elettrica
Il 22 febbraio 2022 21:13:31 CET, Davide Prina ha scritto: >magari il problema è che gli attuali DE tendono a caricare in automatico tante >cose che l'utente non usa e se tu vuoi toglierle non puoi... dovrebbero essere >più modulari e configurabili, permettendo all'utente di dire, questo a me non >serve e non voglio che sia caricato o che sia sostituito da qualcosa d'altro >di più semplice. Il problema degli ambienti attuali è che gli utenti si sono abituati alle comodità Parlo per me stesso, oramai uso GNOME 3 da qualche anno... mi son trovato a riutilizzare IceWm, Window Maker e Mate. e li ho trovati farraginosi. Con GNOME che per la verità ha copiato i tiling WM, pigi meta, t e invio per il terminale. Meta, F I invio per Firefox. Con Icewm son "nascosti" nel terzo o nel quarto sottomenù. Per non parlare di File (ex Nautilus)… la funzione di ricerca da dipendenza Vero, son tutte cose costose in termini di risorse ma sveltiscono molto -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
Re: Gli sviluppatori di Linux sono i più veloci a riparare i bug
>>> Gli sviluppatori di Linux sono i piu` veloci a riparare i bug >> >> Ma ne generano di piu`: >> >> https://madaidans-insecurities.github.io/linux.html > > ma... Non ci credo nemmeno io. Su questi argomenti chiunque puo` dire qualunque cosa. Anche se ben argomentate, sono sempre posizioni di parte.
Re: strano comportamento di swapoff
On 22/02/22 09:46, Leonardo Boselli wrote: è possibile taggare un processo in modo che mai usi lo swap ? sì, usando cgrups/namespace quando avevo fatto un po' di prove per vedere come funzionavano i cgrups e i namespace mi sembra che avevo fatto qualcosa di simile con una prova. cercando ho trovato questo articolo che penso indichi come fare: https://www.ibm.com/docs/en/spectrum-lsf/10.1.0?topic=limits-memory-swap-limit-enforcement-based-linux-cgroups Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki $ Perché microsoft continua a compiere azioni illegali?: http://linguistico.sf.net/wiki/doku.php?id=traduzioni:ms_illegal GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Gli sviluppatori di Linux sono i più veloci a riparare i bug
On 21/02/22 21:21, Alessandro Rubini wrote: Gli sviluppatori di Linux sono i piu` veloci a riparare i bug Ma ne generano di piu`: https://madaidans-insecurities.github.io/linux.html ma... < 1. Sandboxing secondo me è migliore l'uso di namespace e cgroups. L'uso di funzionalità sandboxing può generare un set di problematiche proprio relative alla sicurezza, senza contare che può farti installare prodotti preparati da perfetti sconosciuti. Inoltre puoi creare un utente diverso per l'esecuzione di un determinato set di "strumenti". < 2. Exploit Mitigations non mi sembra così vero quanto detto. Ad esempio per Rust: Rust è "nato" da poco e anche in Linux ne è stata proposta l'adozione... ma anche per altre componenti di un ambiente GNU/Linux. L'adozione già al 100%, come sembra far credere l'articolo, secondo me non c'è ancora da nessuna parte, altrimenti Rust non sarebbe così ancora poco usato. ... < a compromised non-root user account with access to sudo is equal to full root compromise dipende se usi sudo (io non l'ho installato sui miei sistemi) e come l'hai configurato... ... < Xorg’s lack of GUI isolation wayland ... mi sembra che l'articolo sia un po' troppo di parte e faccia sembrare che tutto ciò che non è GNU/Linux sia l'eccellenza e GNU/Linux è la mediocrità E` un mondo in cui si puo` dire tutto e il contrario di tutto, e avere seguito comunque: questo è vero. c'e` ancora chi crede che non siamo andati sulla luna e chi crede che gli aerei stiano su per l'effetto venturi. il problema è che nel passato è stata usata spesso la tecnica di intrusione o di creazione di prove finte per far credere una cosa falsa come vera e giustificare determinate azioni. Ora sorgono come funghi teorie completamente illogiche e senza fondamenti (magari sono create ad hoc proprio per far credere una cosa falsa come vera per...), ma se si guarda lato storia si vede che anche in passato tali teorie esistevano e avevano sostenitori acerrimi... che probabilmente in molti casi avevano poco seguito per la difficoltà di promuovere le proprie idee. Ciao Davide -- Esci dall'illegalità: utilizza LibreOffice/OpenOffice: http://linguistico.sf.net/wiki/doku.php?id=usaooo Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Per risparmiare energia elettrica
On 21/02/22 21:13, Alessandro Rubini wrote: Gli anglofoni lo chiamano "greenwashing". Io lo chiamo stronzata galattica. usare programmi in linguaggio C/Rust (o programmare con questi) e`piu` efficiente, dal punto di vista del consumo energetico, Se e` piu` veloce a dare la stessa soluzione, e` piu` efficiente dal punto di vista energetico. E quindi? se devo essere sincero non ho letto in dettaglio tutto, però vengono presi in considerazione anche altri parametri, come quanta RAM è usata, ... tutte cose che causano un aumento di uso energetico. A risolvere un problema in C ci metto 100 volte il tempo che ci metto in python. Se eseguo il programma meno di qualche milione di volte non mi conviene comunque (nemmeno energeticamente, lasciando stare tutto il resto). però non è sempre così vero, dipende da cosa devi fare. Per alcune cose puoi metterci più o meno lo stesso tempo su qualsiasi linguaggio di programmazione. Inoltre la velocità di programmazione dipende anche dall'abilità del programmatore con quel linguaggio rispetto ad un altro. L'articolo iniziale parlava del cloud. L'articolo dice che il cloud attualmente usa l'1% dell'energia elettrica mondiale. E faceva poi dei discorsi ulteriori per dire che questa percentuale potrebbe essere abbassata conducendo ad un certo risparmio. In un altro articolo, che ora non ho cercato, che ho letto poco tempo fa era indicato che, qualcosa come il 70-80% di tutte le applicazioni web sono realizzate in PHP (nello studio indica un consumo medio di 27.64), passare da PHP ad altro linguaggio potrebbe far risparmiare una quantità di energia non indifferente. E se viene eseguito milioni di volte vuol dire che qualcuno trovera` allocazioni sbagliate e stack overflow, consumando *molta* piu` energia elettrica di quanta ne ho risparmiata. con Rust questo tuo discorso in teoria non è valido. Avevo letto che System76 stava rifacendo parte dell'interfaccia di Gnome3 in Rust Se i grafici smettessero di aggiungere orpelli inutili, invece di riscrivere le cose, il consumo globale migliorerebbe. O forse no, visto che il numero di utenti e` trascurabile. magari il problema è che gli attuali DE tendono a caricare in automatico tante cose che l'utente non usa e se tu vuoi toglierle non puoi... dovrebbero essere più modulari e configurabili, permettendo all'utente di dire, questo a me non serve e non voglio che sia caricato o che sia sostituito da qualcosa d'altro di più semplice. Il problema energetico sono i videogiochi, le criptovalute, le tonnellate di video e foto inutili che conserviamo per sempre, alexa e i suoi fratelli, la digitalizzazione imposta di tutta la carta (non per forza in questo ordine). Sparare numeri a caso su problemi inesistenti non e` molto sensato. questo è vero, soprattutto per l'uso sempre più indiscriminato delle cosiddette criptovalute. Io sono arrivato a pensare che dovrebbe essere vietate tutte queste cosiddette criptovalute, che valute non sono. Perché fanno consumare una quantità di energia spropositata (anche se ora si stanno un po' adeguando per abbassare i consumi, ma l'energia è anche quella usata per costruire gli scatolotti usati per i calcoli e che durano pochi mesi/anni e poi sono da buttare) e inoltre introducono problematiche come inflazione, raggiri, ... Non sono altro che degli schema Ponzi all'ennesima potenza. Io uso assembly sed e awk. Non li vedo nell'articolo: ora mi frusto per espiare. infatti con l'assembly si dovrebbe arrivare ad ottenere la maggior efficienza; avevo notato anch'io l'assenza. https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf lo candidiamo per ignobel? io l'ho trovato interessante, anche perché, con tutte le limitazioni del caso, può essere un tassello che ti permette di fare una valutazione, anche dal punto di vista energetico, se hai due alternative che per te sono analoghe. Soprattutto se utilizzi un dispositivo con batteria e vuoi cercare di far durare la batteria il più a lungo possibile senza ricaricare. Poi gli ignobel non sono sempre così affidabili. Non mi ricordo il caso specifico, ma mi ricordo che era stato assegnato un ignobel ad uno studioso per qualcosa e poi da quello studio lo scienziato era arrivato ad una scoperta fondamentale nel suo campo. Magari da questo studio può essere che chi produce l'interprete per Python cerchi di stare più attendo dal punto di vista energetico e tenda a produrre nuove versioni con minor impatto energetico. Ciao Davide -- Fate una prova di guida ... e tenetevi la macchina!: http://linguistico.sf.net/wiki/doku.php?id=usaooo2 Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: [OT] Intel investe 1 miliardo di dollari in RISC-V
On Tue, Feb 22, 2022 at 09:44:40AM +0100, Diego Zuccato wrote: > Non mi dispiacerebbe basare la prima release pubblica di > OpenAlarm su un Risc-V piuttosto che su un ESP8266... https://www.adafruit.com/product/5337 Ma ci sono già un sacco di altre schede basate su Risc-V: https://create.arduino.cc/projecthub/onelife/arduino-on-4-9-risc-v-board-29d902 https://www.seeedstudio.com/Sipeed-MAIX-I-module-WiFi-version-1st-RISC-V-64-AI-Module-K210-inside-p-3206.html https://www.sifive.com/boards/hifive1-rev-b -- Saluton, Marco Ciampa
Re: strano comportamento di swapoff
Ciao,prova a diminuire il valore di swappiness.Puoi variarlo al volo modificando /proc/sys/vm/swappiness Di default è 60, prova a metterlo a 20Per renderlo persistente (al riavvio):In /etc/sysctl.d/local.conf aggiungivm.swappiness=20 Hai visto quali sono i processi che vanno in swap ?Puoi utilizzare smem (il pacchetto debian si chiama sempre smem) -- Per favore non inviatemi allegati in formato MS Office. Utilizza alternativamente documenti in formato OpenDocument. GPG Fingerprint: 0x56029AD2F77B4C5ED3DB2394BB87A38F146F0DD1 Il martedì 22 febbraio 2022, 09:47:13 CET, Leonardo Boselli ha scritto: ho un portatile con 8G di ram e ha 9G di swap, questo perché ci sono alcui programmi che in certi momenti potrebbero avere bisogno di più memoria. All'inizio tutto bene ba dopo un certo numero di ore di funzionamento circa metà dei proicessi è finito in swap anche se ci sarebbe memoria libera e le prestazioni caano disastrosamante. do il comando swapoff -a e lo swap si svuota. non ho mai dato swapon ma tuttavia dopo qualche ora lo swap ricomincia a essere usato, dapprima poco, ma dopo 24 ore è tornato al punto iniziale. come faccio a dire che proprio non lo usi ? è possibile taggare un processo in modo che mai usi lo swap ? -- Leonardo Boselli Firenze, Toscana, Europa http://i.trail.it
Re: strano comportamento di swapoff
Il 22/02/2022 09:55, Alessandro Rubini ha scritto: E` possibile taggare un processo in modo che mai usi lo swap ? Deve essere lui a lockare le pagine. Se non tutte, almeno alcune. Lo fanno, p.e., i processi che gestiscono materiale crittografico, soprattutto per le chiavi, che così non si rischia che finiscano sul disco in chiaro. No. Le pagine di memoria non sono direttamente collegate ai processi. Cosa molto utile: usando il merge-pages in Proxmox ho potuto farci "entrare" quasi il doppio delle VM con la sola accortezza di raggrupparle per sistemi omogenei sui diversi host :) -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: strano comportamento di swapoff
> come faccio a dire che proprio non lo usi ? /proc/sys/vm/swappiness > E` possibile taggare un processo in modo che mai usi lo swap ? No. Le pagine di memoria non sono direttamente collegate ai processi.
strano comportamento di swapoff
ho un portatile con 8G di ram e ha 9G di swap, questo perché ci sono alcui programmi che in certi momenti potrebbero avere bisogno di più memoria. All'inizio tutto bene ba dopo un certo numero di ore di funzionamento circa metà dei proicessi è finito in swap anche se ci sarebbe memoria libera e le prestazioni caano disastrosamante. do il comando swapoff -a e lo swap si svuota. non ho mai dato swapon ma tuttavia dopo qualche ora lo swap ricomincia a essere usato, dapprima poco, ma dopo 24 ore è tornato al punto iniziale. come faccio a dire che proprio non lo usi ? è possibile taggare un processo in modo che mai usi lo swap ? -- Leonardo Boselli Firenze, Toscana, Europa http://i.trail.it
Re: [OT] Intel investe 1 miliardo di dollari in RISC-V
Il 22/02/2022 09:26, Paolo Redælli ha scritto: Anche a me piace molto, se non fosse che per un "piccolo" particolare: come ARM, prevede che ogni implementatore inserisca le sue estensioni proprietarie. Ovviamente questo ha pro e contro. Questa non l'avevo ancora sentita. Dove l'hai trovata? Parlandone con un amico che stava iniziando a sviluppare sw embedded e aveva avuto problemi nel porting del codice da un modello a un altro. Vero, RiscV ha molte estensioni e quindi moltissime varianti, ma tutte standardizzate. Con gli standard di migliaia di pagine, purtroppo, troppo spesso l'interoperabilità va a farsi benedire :( Come utente, però, il contro è molto grosso: due processori Risc-V possono non essere compatbili a livello di sw. E come sviluppatore rischio di dover trattare ogni processore come se fosse di una famiglia diversa. Direi piuttosto come modelli diversi, allo stesso modo in cui vengono trattati i processori x64 Spero che la situazione si assesti su questi termini. Sarebbero già più gestibili. Non mi dispiacerebbe basare la prima release pubblica di OpenAlarm su un Risc-V piuttosto che su un ESP8266... -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: [OT] Intel investe 1 miliardo di dollari in RISC-V
Il 22/02/22 08:46, Diego Zuccato ha scritto: Il 22/02/2022 08:34, Alessandro Rubini ha scritto: riscV (pronuncia "risk faiv") e` un progetto nella linea del "modo di pensare" RISC, ma completamente nuovo. Molto molto molto bello. Anche a me piace molto, se non fosse che per un "piccolo" particolare: come ARM, prevede che ogni implementatore inserisca le sue estensioni proprietarie. Ovviamente questo ha pro e contro. Questa non l'avevo ancora sentita. Dove l'hai trovata? Vero, RiscV ha molte estensioni e quindi moltissime varianti, ma tutte standardizzate. Come utente, però, il contro è molto grosso: due processori Risc-V possono non essere compatbili a livello di sw. E come sviluppatore rischio di dover trattare ogni processore come se fosse di una famiglia diversa. Direi piuttosto come modelli diversi, allo stesso modo in cui vengono trattati i processori x64
