Fw: RMS removed from the GCC Steering Committee (was: Remove RMS...)
Ciao a tutti, Notizia freschissima quasi in diretta SMTP: Stallman è stato appena rimosso dalla Steering Committee di GCC a valle di una richiesta di Nathan Sidwell (di Facebook) che potete leggere qui: https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html Ho provato a far notare che migliaia di sviluppatori come me scelgono di usare e contribuire a GCC proprio perché si fidano della consistenza fornita da RMS ma senza successo (qui e successivi: https://gcc.gnu.org/pipermail/gcc/2021-March/235183.html ) Tuttavia la nuova Steering Committee "Stallman-free" mi ha rivelato un inatteso ed enorme problema di apertura alla diversità, che non avevo mai notato prima (e che ho segnalato alla comunità di GCC): https://gcc.gnu.org/pipermail/gcc/2021-March/235246.html Se vi interessa, ve lo allego per comodità. Chissà se accoglieranno la mia richiesta con la stessa solerzia di con cui hanno accolto quella di Nathan? :-D Giacomo Begin forwarded message: Date: Thu, 1 Apr 2021 01:11:33 +0200 From: Giacomo Tesio <giacomo@tesio.it> To: gcc@gcc.gnu.org Subject: RMS removed from the GCC Steering Committee (was: Remove RMS...) Hi David, thanks for sharing! On Wed, 31 Mar 2021 14:27:29 -0400 David Edelsohn via Gcc wrote:
In 2012 RMS was added to the GCC Steering Committee web page based on his role in the GNU Project [...] we are removing him from the page.
I have to admit that I had never carefully observed the list of members of the GCC steering committee. As I explained before in this thread, the presence of Stallman gave me enough reassurance that GCC would have honoured the values of Free Software. As I said, enough to chose to port GCC to Jehanne instead of another C compiler, in the hope to contribute back the port upstream, to GNU. But now that I'm comparing the old web page [1] and the new one [2], I realized something entirely new to me. 10 out of 13 members of the GCC steering committee work either for American corporations (8), their subsidiaries (1) or an American University (1) recently covered by the press in India [3]. Also, 4 of these work for the same corporation (IBM / Red Hat). The other 3 are from German GmbH (2) or from a Nederlands public agency. To me, and to billions of people, this shows a huge cultural bias. Even ignoring the huge, unfair and invisible influence that such American companies could have on the project development, even ignoring that so many members are subject to the same Law (a Law that includes the US Cloud Act, FISA, PPD 128, E.O. 12333, etc) decades after the Thompson's lecture on trust in compilers development [4], the sole fact that a single culture and economy can influence so heavily GCC development through its leaders decisions should be fixed. GCC is an international project. I didn't saw this before because I trusted RMS to defend Free Software values at any cost, but now I do not even need to recall my previous adventures with Google and Software Freedom Conservancy to see a huge risk not only to contribute to GCC development, but to rely on GCC. Just like the Galactic President in The Hitchhiker's Guide, our trust in RMS was distracting all of us from the very real and very dangerous geopolitical-diversity issue in GCC leadership. I'm afraid that if you wanted to attract more developers by cutting GCC's ties with Stallman, you just proved that he was not even enough. The GCC Steering Committee doesn't look more inclusive, without RMS. On the contrary, it reveals itself as very "exclusive" to the world. Please, fix it. Giacomo [1] http://web.archive.org/web/20210330171044/https://gcc.gnu.org/steering.html [2] http://web.archive.org/web/20210331192841/https://gcc.gnu.org/steering.html [3] https://timesofindia.indiatimes.com/world/us/twitter-faceoff-rutgers-univers... [4] https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
On 01/04/21 01:37, Giacomo Tesio wrote: (...) Bravo! Ottima iniziativa! I quote this one:
10 out of 13 members of the GCC steering committee work either for American corporations (8), their subsidiaries (1) or an American University (1) recently covered by the press in India [3]. Also, 4 of these work for the same corporation (IBM / Red Hat).
The other 3 are from German GmbH (2) or from a Nederlands public agency.
To me, and to billions of people, this shows a huge cultural bias.
Ottima cosa! Ci terrei a restare informato On Thu, 2021-04-01 at 01:37 +0200, Giacomo Tesio wrote:
Ciao a tutti, Notizia freschissima quasi in diretta SMTP: Stallman è stato appenarimosso dalla Steering Committee di GCC a valle di una richiesta diNathan Sidwell (di Facebook) che potete leggere qui: https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html
Ho provato a far notare che migliaia di sviluppatori come me scelgonodi usare e contribuire a GCC proprio perché si fidano della consistenzafornita da RMS ma senza successo (qui e successivi: https://gcc.gnu.org/pipermail/gcc/2021-March/235183.html ) Tuttavia la nuova Steering Committee "Stallman-free" mi ha rivelatoun inatteso ed enorme problema di apertura alla diversità, che non avevomai notato prima (e che ho segnalato alla comunità di GCC): https://gcc.gnu.org/pipermail/gcc/2021-March/235246.html
Se vi interessa, ve lo allego per comodità. Chissà se accoglieranno la mia richiesta con la stessa solerzia dicon cui hanno accolto quella di Nathan? :-D
Giacomo Begin forwarded message: Date: Thu, 1 Apr 2021 01:11:33 +0200From: Giacomo Tesio <giacomo@tesio.it>To: gcc@gcc.gnu.org Subject: RMS removed from the GCC Steering Committee (was: RemoveRMS...)
Hi David, thanks for sharing! On Wed, 31 Mar 2021 14:27:29 -0400 David Edelsohn via Gcc wrote:
In 2012 RMS was added to the GCC Steering Committee web pagebased on his role in the GNU Project [...]we are removing him from the page.
I have to admit that I had never carefully observed the list of membersof the GCC steering committee. As I explained before in this thread,the presence of Stallman gave me enough reassurance that GCC would havehonoured the values of Free Software. As I said, enough to chose to port GCC to Jehanne instead of anotherC compiler, in the hope to contribute back the port upstream, to GNU.
But now that I'm comparing the old web page [1] and the new one [2],I realized something entirely new to me.
10 out of 13 members of the GCC steering committee work either forAmerican corporations (8), their subsidiaries (1) or an American University (1) recently covered by the press in India [3].Also, 4 of these work for the same corporation (IBM / Red Hat). The other 3 are from German GmbH (2) or from a Nederlands public agency.
To me, and to billions of people, this shows a huge cultural bias. Even ignoring the huge, unfair and invisible influence that suchAmerican companies could have on the project development, even ignoringthat so many members are subject to the same Law (a Law that includesthe US Cloud Act, FISA, PPD 128, E.O. 12333, etc) decades after the Thompson's lecture on trust in compilers development [4], the sole factthat a single culture and economy can influence so heavily GCCdevelopment through its leaders decisions should be fixed. GCC is an international project. I didn't saw this before because I trusted RMS to defend Free Softwarevalues at any cost, but now I do not even need to recall my previousadventures with Google and Software Freedom Conservancy to see a hugerisk not only to contribute to GCC development, but to rely on GCC. Just like the Galactic President in The Hitchhiker's Guide, our trustin RMS was distracting all of us from the very real and very dangerousgeopolitical- diversity issue in GCC leadership.
I'm afraid that if you wanted to attract more developers by cuttingGCC's ties with Stallman, you just proved that he was not even enough.
The GCC Steering Committee doesn't look more inclusive, without RMS.On the contrary, it reveals itself as very "exclusive" to the world.
Please, fix it.
Giacomo [1]http://web.archive.org/web/20210330171044/https://gcc.gnu.org/steering.html
[2]http://web.archive.org/web/20210331192841/https://gcc.gnu.org/steering.html
[3] https://timesofindia.indiatimes.com/world/us/twitter-faceoff-rutgers-univers...
[4]https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf _______________________________________________nexa mailing listnexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Ciao Marco e ciao a tutti On Thu, 01 Apr 2021 13:29:21 +0200 Marco A. Calamari wrote:
Ci terrei a restare informato
Qui trovi un'ulteriore analisi un po' più dettagliata di quanto è avvenuto nella GCC Steering Committee ed una richiesta esplicita di correggere il problema con la stessa solerzia con cui è stato cancellato RMS https://gcc.gnu.org/pipermail/gcc/2021-April/235285.html Tuttavia, sebbene quanto sta avvenendo in GCC abbia profonde ripercussioni tecniche e geopolitiche[1], e sia assolutamente rilevante per i temi trattati in questa lista, ti inviterei a seguire il dibattito sulla mailing list GCC, portando, magari, il tuo prezioso contributo. A presto! Giacomo [1] per chi non lo sapesse, GCC è una suite di compilatori con i quali viene compilata la quasi totalità del software libero e del software open source in tutto il mondo, spesso indipendentemente dalla piattaforma e dal sistema operativo in cui verrà eseguito
Caro Giacomo, On Thu, Apr 01, 2021 at 01:37:25AM +0200, Giacomo Tesio wrote:
Tuttavia la nuova Steering Committee "Stallman-free" mi ha rivelato un inatteso ed enorme problema di apertura alla diversità, che non avevo mai notato prima (e che ho segnalato alla comunità di GCC):
forse ti sorprenderà, ma sono assolutamente d'accordo con te! La FSF ha da sempre un problema di US-centrismo nella sua governance. Come conseguenza di questo fatto si sono create negli anni altre organizzazione FSF* in giro per il mondo, ma ho sempre pensato che non fosse una soluzione sufficiente, perché molte di queste organizzazioni hanno nel tempo deviato un po' dai fondamenti ideologici della FSF, risultando spesso meno radicali (cosa che considero negativa). Serve una unica "FSF international", che abbia come missione quella di occuparsi delle libertà degli utenti di software in tutto il mondo. Penso che la soluzione di questo problema debba passare per una maggiore diversità geografica/culturale nella gestione della FSF come la conosciamo oggi. In più occasioni negli anni ed assieme ad altri ho segnalato questo problema all'organizzazione e, per dare alla FSF ciò che è della FSF, qualcosa si è mosso. In tempi recenti la FSF ha avuto 2 membri del board Brasiliani e Francesi, rispettivamente (ma non è più il caso oggi). Chiaramente non è abbastanza, ma la speranza è che un'organizzazione con maggiore diversità geografica alla radice incoraggi questo (ed altri) tipo di diversità a cascata su tutti i suoi progetti associati. (Arrivare fino a GCC è un problema più complicato, perché passa dalla relazione tra la FSF ed il progetto GNU, che resta da chiarire, ma questa non è certo una scusante!) A presto -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Caro Stefano, On Thu, 1 Apr 2021 14:10:37 +0200 Stefano Zacchiroli wrote:
On Thu, Apr 01, 2021 at 01:37:25AM +0200, Giacomo Tesio wrote:
Tuttavia la nuova Steering Committee "Stallman-free" mi ha rivelato un inatteso ed enorme problema di apertura alla diversità, che non avevo mai notato prima (e che ho segnalato alla comunità di GCC):
forse ti sorprenderà, ma sono assolutamente d'accordo con te!
non so francamente se possa sorprenderti, ma non mi sorprende affatto! :-D Come ti ho già scritto in privato e come spero di riuscire a trovare il tempo al più presto di elaborare in una riflessione condivisa e pubblica, io NON credo che tu sia "al servizio" dei GAFAM. Penso invece che tu (come moltissimi altri) sia una vittima inconsapevole di una profondissima influenza politica-culturale che passa ANCHE dai finanziamenti che queste aziende statunitensi investono in progetti e conferenze per legittimarsi, per sedare le coscienze critiche, per porre uomini affini ai loro interessi in posizioni strategiche etc... Ti prego però di avere un po' di pazienza: come dicevamo off-list il tema è articolato e complesso e sebbene sia fortemente correlato a quanto sta accadendo in questi giorni, non lo mischierei con il caso specifico del reiterato linciaggio pubblico di RMS.
La FSF ha da sempre un problema di US-centrismo nella sua governance. [...] (Arrivare fino a GCC è un problema più complicato, perché passa dalla relazione tra la FSF ed il progetto GNU, che resta da chiarire, ma questa non è certo una scusante!)
Attenzione però, buona o cattiva, US-centrica o meno, la FSF è una organizzazione non governativa senza scopo di lucro ma con uno scopo chiaro e ben definito! Il progetto GNU, internazionale e saldamente guidato da RMS in qualità di GNUisance[1], a Stallman riconosce una funzione fondamentale di tutela degli interessi collettivi nello sviluppo del software libero. Certamente RMS non è né immortale né infallibile. Ma come ho cercato di spiegare agli altri sviluppatori di GCC, per me come per migliaia di altri, la sua presenza forniva una garanzia strategica tale da compensare il rischio posto da quel US-centrismo, in attesa che queste questioni venissero affrontate. Ora che è stato cancellato, appare evidente che la GNU Compiler Collection non offre più (se ha mai offerto) questa garanzia. E non è un caso che nei giorni scorsi alcuni fra i membri più influenti del progetto discutessero di uscire dal progetto GNU (pur volendo mantenere il controllo sul brand GCC, si direbbe). Ad esempio qui Andrew Haley, di RedHat/IBM: https://gcc.gnu.org/pipermail/gcc/2021-March/235167.html Di fatto, l'unico collegamento con la Free Software Foundation (che detiene il copyright di GCC) nonché con l'unica organizzazione senza scopo di lucro CREDIBILE a difesa del Software Libero (la SFC, per esempio, non lo è [2]), è stato cancellato dalla Steering Committee. E da chi? Da rappresentanti di poche multinazionali statunitensi. Su richiesta di un programmatore di Facebook. Direi dunque che, se sei d'accordo con me, è importante far sentire subito la tua voce affinché questo ENORME problema di rilevanza PLANETARIA venga risolto al più presto! Se era urgente rimuovere RMS perché "dannoso" per una minoranza statunitense, figurati quanto è urgente rimuovere questa straordinaria predominanza statunitense dannosa per tutto il resto dell'umanità! Fortunatamente si può risolvere tutto con la stessa facilità con cui è stato "risolto" il "problema Stallman": cancellando un altro po' di nomi. E questa volta per problemi evidenti, oggettivi ed inconfutabili. A presto! Giacomo [1] https://www.gnu.org/gnu/gnu-structure.html [2] https://gcc.gnu.org/pipermail/gcc/2021-March/235224.html
Direi dunque che, se sei d'accordo con me, è importante far sentire subito la tua voce affinché questo ENORME problema di rilevanza PLANETARIA venga risolto al più presto!
Se era urgente rimuovere RMS perché "dannoso" per una minoranza statunitense, figurati quanto è urgente rimuovere questa straordinaria predominanza statunitense dannosa per tutto il resto dell'umanità!
Gli americani potrebbero obiettare che sono loro i maggiori "produttori" di software libero. Non so se ci sono statistiche aggiornate, ma prendendo per buoni questi dati [1] una ipotetica rappresentanza, mettiamo di dieci componenti, dovrebbe essere composta da cinque statunitensi, un ungherese, un tedesco, un britannico, un cinese ed un francese. Antonio [1] https://hoffa.medium.com/github-top-countries-201608-13f642493773
Ciao Antonio, On Thu, 1 Apr 2021 16:55:53 +0200 Antonio Iacono wrote:
Gli americani potrebbero obiettare che sono loro i maggiori "produttori" di software libero.
Non so se gli conviene: il resto del mondo potrebbe svegliarsi e chiedergli "e come mai siete voi i maggiori produttori di software libero? Avrà MICA qualcosa a che fare con l'enorme potere militare ed economico che detenete? Ne è una causa, un effetto... o entrambi in un feedback loop che accresce sistematicamente la vostra egemonia?"
cinque statunitensi, un ungherese, un tedesco, un britannico, un cinese ed un francese
Sembra l'inizio di una barzelletta. :-D Giacomo
Ciao Giacomo, Giacomo Tesio <giacomo@tesio.it> writes: [...]
Even ignoring the huge, unfair and invisible influence that such American companies could have on the project development, even ignoring that so many members are subject to the same Law (a Law that includes the US Cloud Act, FISA, PPD 128, E.O. 12333, etc) decades after the Thompson's lecture on trust in compilers development [4],
Non era solo sui compilatori ma fa niente, è un dettaglio qui. Hai sentore che ci possa essere la possibilità che in questo scenario sia possibile nascondere adeguatamente bene qualche backdoor in GCC? Attenzione che non sto dicendo "che ci sia qualcuno che vuole farlo", quello lo do per scontato, è perfino ovvio. Intendo dire: considerato che la soluzione al problema del Trusting Trust è disponibile [5], credi che *a regime* sarà possibile far passare inosservata una qualche backdoor inserita nel sorgente del codice dei compilatori? ...sempre che lo si voglia davvero di arrivare a regime. Nel frattempo, mi domando se qualcuno abbastanza convincente non sia già riuscito a far inserire qualche backdoor nel software libero che uso, preso principalmente da Debian. Se qualcuno stesse alzando il sopracciglio pensando che io sia troppo paranoico vi dico solo che una cosa del tutto analoga (la cui vera causa probabilmente non si saprà mai) è già successa col disastro di Solar Winds Orion. C'è qualcuno addetto alla nostra cybersicurezza nazionale che se ne sta occupando o va tutto bene così, "solo" perché noi stiamo dalla parte di quelli che sono più bravi a inserire backdoors? [...] Saluti, Giovanni.
[4] https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
[5] Countering Trusting Trust through Diverse Double-Compiling (DDC) https://dwheeler.com/trusting-trust/, in particolare https://dwheeler.com/trusting-trust/#real-world -- Giovanni Biscuolo
Ciao Giovanni, On April 5, 2021 11:00:19 AM UTC, Giovanni Biscuolo wrote:
Giacomo Tesio <giacomo@tesio.it> writes:
Even ignoring the huge, unfair and invisible influence that such American companies could have on the project development, even ignoring that so many members are subject to the same Law (a Law that includes the US Cloud Act, FISA, PPD 128, E.O. 12333, etc) decades after the Thompson's lecture on trust in compilers development [4],
Hai sentore che ci possa essere la possibilità che in questo scenario sia possibile nascondere adeguatamente bene qualche backdoor in GCC?
È complicato. :-( Non tanto in GCC, quanto nel software compilato con esso. E non tanto una bella backdoor fatta e finita, quanto vulnerabilità exploitabili in un determinato contesto. E non sarebbe necessario inserire attivamente questo tipo di vulnerabilità, ma avervi accesso privilegiato, prima che vengano scoperti e sfruttati da altri come zero-day. Nel dibattito che abbiamo avuto sulla mailing list GCC facevo l'esempio dei vecchi CVE-2000-1219, CVE-2008-1367 e CVE-2015-5276 [1]. Ma il tipo di influenza che Google&friends hanno su GCC tramite i loro impiegati è molto più sottile e complessa:
And you are confusing my employer with my free software work.
No.
Simply, I work in the field since two decades myself.
Thus, I'm not naive enough to ignore the thousands way your employer can get huge advantages by having you in the GCC's Steering Committee.
As a small example among many many others, you are using a @google.com mail address while serving in the Steering Committee. https://gcc.gnu.org/pipermail/gcc/2021-April/235312.html
Tutte le comunicazioni private della Steering Committee sono accessibili a Google, IBM e Red Hat... Cosa può andare storto? E dire che ho speso buona parte del mio tempo libero degli ultimi 3 anni per portare GCC su Jehanne... e ora GCC che prende in considerazione di cambiare nome e tagliare i ponti con il progetto GNU. Inizio a pensare che bisogna ripartire letteralmente da zero. Il software deve essere leggibile da tutti. Se un software è così complesso che chi lo usa non lo può comprendere in un tempo ragionevole (una settimana? un mese? certo non di più) allora va riscritto.
C'è qualcuno addetto alla nostra cybersicurezza nazionale che se ne sta occupando o va tutto bene così, "solo" perché noi stiamo dalla parte di quelli che sono più bravi a inserire backdoors?
Ma figurati! :-D Non saprebbero nemmeno da dove partire. Non nascondono nemmeno la testa sotto la sabbia. Manca proprio la capacità di concepire il problema. E non solo in Italia! Giacomo [1] trovi i link su https://gcc.gnu.org/pipermail/gcc/2021-April/235303.html
Ciao Giacomo, Giacomo Tesio <giacomo@tesio.it> writes: [...]
Hai sentore che ci possa essere la possibilità che in questo scenario sia possibile nascondere adeguatamente bene qualche backdoor in GCC?
È complicato. :-(
Lo so: *complicato*, non solo complesso :-O
Non tanto in GCC, quanto nel software compilato con esso.
Sì sì, intendevo quello
E non tanto una bella backdoor fatta e finita, quanto vulnerabilità exploitabili in un determinato contesto.
OK chiaro: su questo avrei delle cose da dire in merito alla qualità dei linguaggi di programmazione ma sono questioni da tecnici e non voglio iniziare un flame pesante in questa lista.
E non sarebbe necessario inserire attivamente questo tipo di vulnerabilità, ma avervi accesso privilegiato, prima che vengano scoperti e sfruttati da altri come zero-day.
Considerato che il presupporto è che i binari del GCC non siano attivamente alterati senza che il relativo codice sorgente venga pubblicato (questione ancora non del tutto risolta, comunque), direi che siccome il codice sorgente di tutto il software libero *copyleft* _distribuito_ (GCC ad esempio) è disponibile allora io non vedo come chiunque possa trarre il vantaggio strategico di essere in grado di individuare gli zero-day prima degli altri; casomai chiunque potrebbe scoprirli e NON aprire un report CVE per sfruttare la cosa a proprio vantaggio, ma questo vale davvero per chiunque; sbaglio? Comunque, siccome la questione della garanzia che i binari usati come binary-seeds di intere distribuzioni non siano attivamente alterati NON è del tutto risolta, io (mica solo io) spenderei un po' di attenzione anche in quella direzione. [...]
Ma il tipo di influenza che Google&friends hanno su GCC tramite i loro impiegati è molto più sottile e complessa:
[...]
Tutte le comunicazioni private della Steering Committee sono accessibili a Google, IBM e Red Hat...
Cosa può andare storto?
Infatti io obbligherei lo steering committee a rendere pubbliche tutte le comunicazioni che riguardino le persone quando le comunicazioni sono effettuare nelle loro funzioni all'interno dello steering committee :-D Poi ognuno è libero di avere i propri segreti. [...]
Inizio a pensare che bisogna ripartire letteralmente da zero.
Io ne sono convinto da tre anni ma le risorse sono praticamente tutte impiegate per continuare a rappezzare cose ormai logore; che poi, per carità, non si può buttare via tutto da un giorno all'altro, però nemmeno continuare in sæcula sæculorum a scrivere cose che *per forza* contengono buffer-overflow e disgrazie del genere... ops, stava per partirmi il flame :-(
Il software deve essere leggibile da tutti.
O perlomeno ci dovrebbero essere un numero sufficiente di persone messe nelle condizioni di poterlo analizzare per svolgere quel lavoro di continua verifica collaborativa che *dovrebbe* essere uno dei veri vantaggi *cooperativi* (NON competitivi) del software libero e open source; invece quelli che lo fanno sono (percentualmente) pochissimi... e non solo perché non sono capaci di comprenderlo ed eventualmente criticarlo per la sua inutile complicazione ma soprattutto perché quel "mestiere" costa tanto e - AFAIU IANAL IMHO - NON "fa reddito". "The maintainers" [1] meriterebbero di essere considerati meglio, in particolare una volta che si fanno i conti con "The Innovation Delusion". [1] https://themaintainers.org/about-us [...]
C'è qualcuno addetto alla nostra cybersicurezza nazionale che se ne sta occupando o va tutto bene così, "solo" perché noi stiamo dalla parte di quelli che sono più bravi a inserire backdoors?
Ma figurati! :-D
Ero retorico :-D [...]
E non solo in Italia!
Ma certo, *tutti* credono di essere più bravi di altri a inserire backdoors. Ciao, Giovanni. [...]
[1] trovi i link su https://gcc.gnu.org/pipermail/gcc/2021-April/235303.html
-- Giovanni Biscuolo
Ciao Giovanni, On April 6, 2021 8:32:20 AM UTC, Giovanni Biscuolo <giovanni@biscuolo.net> wrote:
Considerato che il presupporto è che i binari del GCC non siano attivamente alterati senza che il relativo codice sorgente venga pubblicato (questione ancora non del tutto risolta, comunque), direi che siccome il codice sorgente di tutto il software libero *copyleft* _distribuito_ (GCC ad esempio) è disponibile allora io non vedo come chiunque possa trarre il vantaggio strategico di essere in grado di individuare gli zero-day prima degli altri; casomai chiunque potrebbe scoprirli e NON aprire un report CVE per sfruttare la cosa a proprio vantaggio, ma questo vale davvero per chiunque; sbaglio?
Vale per chiunque, ma chi guida il progetto ha notevoli vantaggi nell'individuarli, nel lasciarli introdurre (da terze parti in buona fede) etc... o nel rallentare la loro individuazione pubblica. Al di là degli aspetti di sicurezza, se leggi attentamente il thread, vedrai che l'influenza decisionale e strategica della Steering Committee non viene mai sminuita dai suoi membri, solo dai supporter. E parliamo di una Steering Committee che ha prontamente cacciato Stallman (e GNU e la FSF con lui) su richiesta di un dipendente di Facebook. Insomma hanno rimosso la pagliuzza, ma si tengono ben stretti alla loro trave.
Tutte le comunicazioni private della Steering Committee sono accessibili a Google, IBM e Red Hat...
Cosa può andare storto?
Infatti io obbligherei lo steering committee a rendere pubbliche tutte le comunicazioni che riguardino le persone quando le comunicazioni sono effettuare nelle loro funzioni all'interno dello steering committee
Non funzionerebbe. Ci sono 4 dipendenti RedHat/IBM nella SC di GCC. Potrebbero accordarsi al caffè. Anche se non potessero farlo, non oserebbero far prendere a GCC una strada in contrasto con gli interessi della propria azienda, fosse anche solo in termini di timing.
Il software deve essere leggibile da tutti.
O perlomeno ci dovrebbero essere un numero sufficiente di persone...
No, non basta. È stato uno degli errori fondamentali di Stallman: aver confuso (in modo molto americano, per la verità) privilegi con libertà. Il software libero può essere tale SOLO se davvero TUTTI lo possono quanto meno leggere. Solo quando questo obiettivo sarà raggiunto, potrà vincere sul software proprietario o sui SaaS come Windows, GMail o Facebook che abusano la credulità e l'ignoranza degli utenti. Giacomo
Ciao, grazie di aver chiarito cosa non va secondo te nella situazione dello steering committee di GCC Giacomo Tesio <giacomo@tesio.it> writes: [...]
È stato uno degli errori fondamentali di Stallman: aver confuso (in modo molto americano, per la verità) privilegi con libertà.
«La libertà non è star sopra un albero, non è neanche il volo di un moscone...» :-D Non capisco esattamente cosa avrebbe confuso RMS ma non fa niente, sono semplicemente allibito nel constatare che lui tutto solo soletto è il colpevole del fallimento del software libero, dell'informatica, di GNU, di FSF e chissà cos'altro, *precisamente* perché è coplevole di non aver capito un sacco di cose che invece altri hanno capito benissimo e lui invece no, è scostante e offensivo, un fanatico che non ascolta, uno che ripete sempre le stesse cose, che non ha capito come fare le licenze, non ha capito come fare sinergie... tra l'altro ha pure la sfiga di essere statunitense. Forse sarebbe meglio che si ritirasse davvero a vita privata, per la serenità sua e di tutti. Un giorno gli chiederò cosa ne pensa. [...] Ciao, Giovanni. P.S.: Giovanni fan-boy di RMS, imbarazzante :-D P.P.S.: RMS esprime altrove le proprie posizioni politiche, in GNU invece hanno trovato questo punto di equilibrio: https://www.gnu.org/prep/maintain/maintain.html#Other-Politics P.P.P.S.: siamo così sucettibili che in GNU hanno pure dovuto chiarire la loro posizione in merito allo humor https://www.gnu.org/prep/maintain/maintain.html#Humor (che sapete meglio di me essere *molto* dipendente dalla cultura di appartenenza) -- Giovanni Biscuolo
Giovanni... ma, ma... ma! :-D On Tue, 06 Apr 2021 15:19:06 +0200 Giovanni Biscuolo wrote:
grazie di aver chiarito cosa non va secondo te nella situazione dello steering committee di GCC
Figurati. Come ho provato a spiegare nella mailing list, RMS nella Steering Committee aveva una funzione di garanzia, ai miei occhi, capace di bilanciare l'influenza di aziende come RedHat/IBM, Google etc... E questo non in quanto RMS, ma in quanto Chief GNUissance nonché Presidente della FSF (da cui ad ogni pié sospinto, gli sviluppatori RedHat in GCC propongono di slegarsi definitivamente https://gcc.gnu.org/pipermail/gcc/2021-March/235167.html ) Evidentemente ero un ingenuo.
Giacomo Tesio <giacomo@tesio.it> writes:
È stato uno degli errori fondamentali di Stallman: aver confuso (in modo molto americano, per la verità) privilegi con libertà.
«La libertà non è star sopra un albero, non è neanche il volo di un moscone...» :-D
Non capisco esattamente cosa avrebbe confuso RMS ma non fa niente, sono semplicemente allibito nel constatare che lui tutto solo soletto è il colpevole del fallimento del software libero [...]
Forse non siamo d'accordo. Ma forse non sono stato chiaro. Rileggi le mie parole in proposito:
I cannot think of a single man that did MORE work than Stallman to make GCC successful. [...] https://gcc.gnu.org/pipermail/gcc/2021-April/235312.html
P.P.P.S.: siamo così sucettibili...
Beh... un pochino... direi di sì dai... :-D Tuttavia ti faccio notare che, se GCC fosse un compilatore studiabile approfonditamente in un mese, la presenza di Stallman (o di Google) nella Steering Committee sarebbe molto meno importante (o pericolosa). Siamo d'accordo che una libertà che solo pochi(ssimi) possono effettivamente esercitare è indistinguibile da un privilegio? IMHO, questo è stato uno degli errori fondamentali di Stallman. (con "fondamentali" inteso come "durante la costruzione delle fondamenta" del software libero) Non gliene faccio una colpa: era difficile prevedere negli anni 80 che la libertà fornita dal software libero può essere apprezzata veramente solo da chi effettivamente è capace di esercitarla, modificando gli automatismi che lo circondano. Così come è comprensibile che, da statunitense cresciuto nel pieno della guerra fredda, abbia incentrato l'ideologia del progetto GNU sul valore della libertà invece che su quello della curiosità hacker, di cui la libertà è solo uno dei pilastri valoriali fondamentali. Stallman non è colpevole di ciò di cui è stato accusato. Ed è preziossimo per il movimento del software libero. Detto ciò, è anche importante analizzare gli errori del passato che ci hanno portato nella situazione attuale, prestando il fianco all'Open Source, alla corruzione di Google in ogni dove etc... Ma di queste questioni politiche, discuterò molto più volentieri quando il linciaggio mediatico di RMS e della FSF saranno terminati. E (avendo il tempo... che ci vuole tempo ;-) anche con Stallman. Però ti prego, non associarmi con chi attacca RMS sul piano personale. Non credo di meritarlo. ;-) Giacomo
Ciao, Giacomo Tesio <giacomo@tesio.it> writes: [...]
Non capisco esattamente cosa avrebbe confuso RMS ma non fa niente, sono semplicemente allibito nel constatare che lui tutto solo soletto è il colpevole del fallimento del software libero [...]
Forse non siamo d'accordo. Ma forse non sono stato chiaro.
[...]
Però ti prego, non associarmi con chi attacca RMS sul piano personale. Non credo di meritarlo. ;-)
Non era minimamente mia intenzione, anche perché su questo sia io che tu ci siamo espressi pubblicamente quindi pensavo fosse già abbastanza chiaro. É nel merito delle critiche strategiche o di politica della promozione e sviluppo del software libero che rivolgi a RMS che non siamo del tutto d'accordo... ma appunto, non c'è spazio, modo e ambiente per discuterne con calma. [...] Ciao, Giovanni -- Giovanni Biscuolo
participants (6)
-
Antonio Iacono -
D. Davide Lamanna -
Giacomo Tesio -
Giovanni Biscuolo -
Marco A. Calamari -
Stefano Zacchiroli