1. 4

    Se progettassi io un sistema operativo, avrei tutte le syscalls sia in versione blocking che non-blocking.

    E magari un’unica interfaccia di I/O, e non interfacce separate per files e connessioni di rete. Ah, ci aveva già pensato Plan9 e qualcun altro…

    1. 1

      avrei tutte le syscalls sia in versione blocking che non-blocking

      Perché?
      (non è una domanda retorica)

      un’unica interfaccia di I/O, e non interfacce separate per files e connessioni di rete. Ah, ci aveva già pensato Plan9

      In realtà su Plan 9 tutte le syscalls sono bloccanti.

      1. 5

        L’intera filosofia Unix è basata su concetti “bloccanti”:

        • apri file; aspetta che risulti aperto (se il disco era in standby, la “open” potrebbe impiegare interi secondi prima di poter rispondere “aperto” o “non trovato”)
        • leggi dal file; stesso blocco
        • chiudi file (e non si sa quanto ci possa mettere la sync che la libreria potrebbe comandare)
        • stesso discorso, con più complicazioni (bind, listen, effetti collaterali del traffis-chaping, ecc.), per le connessioni di rete

        E allora che hanno fatto? Imitando vagamente la programmazione a eventi, si sono inventati prima le select/epoll per controllare in un sol colpo (cioè senza sprecare il 99.9999% del tempo a fare polling su ogni handle) se c’è qualche “novità” su qualche handle di file o socket.

        E quindi si sono inventati i future/promise/async/await/eccetera, per “mettere in lista” le operazioni da fare, e “bloccare” solo quando tutti gli ingredienti sono nel frullatore.

        Dunque - mia considerazione - se un kernel avesse una openb bloccante e una opennb non bloccante, lo sviluppatore potrebbe decidere caso per caso cosa usare. Leggere il file di configurazione sarà quasi sempre “bloccante”, riempirsi una cache in RAM potrebbe essere “non bloccante” o eseguibile da un altro thread.

        (La versione bloccante di una funzione potrebbe benissimo essere una macro che chiama prima la non bloccante e poi subito dopo blocca, ma temo che ciò costi un fracco di codice in più nell’eseguibile e di tempo di CPU inutilmente utilizzato).

        Avere sia la bloccante che la non bloccante nel kernel imporrebbe che i designer del kernel decidano (cioè comandino ineluttabilmente) come dev’essere l’engine che processa le promise/futures accumulatesi. Il che potrebbe avere risvolti piuttosto interessanti a livello di progettazione del sistema operativo (insisto a ripetere che noi, per tradizione ultracinquantennale, siamo fossilizzati su concetti come “filesystem” e “networking” fatti di imperativi “open/bind/listen-read/write-close”, ognuno dei quali in attesa del completamento del precedente, e che l’adozione in sempre più linguaggi di programmazione dei concetti di future/async/promise c’è stata perché era diventato materialmente impossibile tenere aperte troppe migliaia di handles anche su macchine moderne).

    1. 3

      Sebbene trovi il giuramento inutile al fine di garantire un comportamento morale da parte degli ingegneri, il problema di questo articolo è che sembra togliere agenza ai tecnici, infantilizzandoli e indebolendoli per schermarli dalle responsabilità. Fa l’esempio della bomba atomica dando la colpa ai politici e militari (e non ci piove), ma omette il fatto che se tecnici e scienziati (che comunque non erano tutti pienamente consapevoli di cosa si stava facendo) avessero detto no, i politici non avrebbero avuto alcuna possibilità di decidere. La decisione sarebbe rimasta ai tecnici.

      Poi vabe’, per lo stesso motivo per cui non dà garanzie se applicato ai tecnici, non dà garanzie se applicato ai manager.

      1. 1

        il giuramento inutile al fine di garantire un comportamento morale

        Un giuramento esprime un insieme di valori morali che sono già condivisi nella comunità che lo adotta.
        (per questo non siamo lontanamente pronti ad elaborarlo)

        L’obiettivo del giuramento è preservare tali valori: il giuramento di Ippocrate includeva un vincolo ad insegnare medicina solo a coloro che lo accettavano. E’ questo filtro all’ingresso ad averne mantenuto l’efficacia. Efficacia che è certamente solo statistica: ci sono medici che lo violano, ma sono (ancora) la minoranza.

      1. 2

        There are a few mitigation options here. (I’m using them, but I doubt other people are doing this. Each requires some serious programming. Unfortunately, the Tor Project has been less than open to implementing any kind of mitigation option.)

        Perché?

        1. 2

          Questa sarebbe una domanda interessante da fare al Tor Project.

        1. 1

          Il concetto di “loyal opposition” mi lascia molto perplesso.

          Al di là della vaga flessibilità (che giocherà sempre a vantaggio del management), mi appare come un contentino.

          Sì dai… placate le vostre coscienze facendoci perdere un po’ di tempo in riunione… basta che poi fate quello che diciamo noi…”

          1. 1

            Io però quel “loyal” lo leggo come loyal alla società. Che non è tanto meglio, è un modo per dire: “gli ingegneri dovrebbero dire no ai datori di lavoro quando esagerano, ma crestina bassa che sennò questi si accorgono di quanto potere hanno e rischiano di prenderci la mano”. Ovviamente non ha mai funzionato così e in uno scenario del genere, non basterebbe un elemento morale a convincere un’ipotetica Gilda Mondiale degli ingegneri a perseguire il bene comune.

            1. 1

              non basterebbe un elemento morale a convincere un’ipotetica Gilda Mondiale degli ingegneri a perseguire il bene comune

              E cosa servirebbe?

              1. 4

                una struttura sociale che vincolasse gli ingegneri (ma in generale chi detiene potere) ad agire per il bene comune. Come oggi si critica il sistema perché genera storture materializzate nei CEO, nei finanzieri e nei politici, lo stesso succederebbe se si rimpiazzasse l’attuale sistema con una tecnocrazia guidata da ingegneri.

                1. 1

                  una struttura sociale

                  Sì un’utopia non farebbe schifo in effetti! :-D
                  Il punto è: come ci si arriva?

                  La funzione evolutiva della moralità umana è approssimare una massimizzazione del bene collettivo, indipendentemente dal bene individuale. Gruppi sociali diversi per storia e dimensione adottano moralità differenti che funzionano più o meno bene a seconda del momento storico e che si contaminano reciprocamente.

                  vincolasse gli ingegneri

                  Pessima idea. I medici non sono “vincolati” a non danneggiare il paziente. Vengono educati.

                  una tecnocrazia guidata da ingegneri

                  Sarebbe una noia mortale in effetti. Gli ingegneri mancano di fantasia.
                  (e sì… statisticamente l’ultima affermazione è vera)

                  Una democrazia di hacker sarebbe tutt’altra cosa. :-P

                  1. 4

                    I medici non sono “vincolati” a non danneggiare il paziente.

                    Hanno comunque un reward system e una penalizzazione se sbagliano. Hanno comitati etici per la ricerca medica che possono bloccarli. Hanno un sistema che li controlla. Un medico stronzo, all’interno di ciò che è legale (quindi non iniezioni di cianuro di nascosto) ha una serie di sistemi che lo bloccano o lo escludono. Un ingegnere molto meno.

                    Una democrazia di hacker sarebbe tutt’altra cosa

                    Sarebbe la stessa cosa ma con software decentralizzato e criptato e DOOM che gira su qualunque pezzo di silicio.

          1. 3

            Questo articolo apre la porta al dissenso ma non inquadra davvero l’alternativa. Qui il dissenso sembra materializzarsi come un ingegnere, messo al centro di un complesso sistema di potere che, per etica personale, dice: “NO!” e tutto l’ambaradan si ferma. Ovviamente nel mondo reale non è così e quello che sta succedendo a Google, Microsoft o Github ha una prospettiva molto diversa. Gli ingegneri dicono NO! come una collettività, non come una somma di individui isolati e non come una categoria professionale che si attiene ad un codice deontologico come propone l’articolo.

            Tuttavia un codice deontologico, se riuscisse a diventare veramente pervasivo, sarebbe comunque un passo avanti perché perlomeno violerebbe l’illusione che la produzione software possa essere condotta in un vuoto etico da tecnici con la capacità critica di un bambino di 5 anni.

            1. 1

              Francamente non credo che l’informatica sia lontanamente pronta ad un codice deontologico.

              Sono d’accordo che ne avrebbe profondo bisogno, ma la consapevolezza (tecnica, politica ed etica) della nostra categoria è così fragile che qualunque tentativo di definirne uno (così come qualsiasi tentativo di creare un ordine professionale) sarebbe rapidamente sovvertito dai sistemi di potere esterni (corporate e non).

            1. 2

              L’articolo non è recente ma merita di essere riconsiderato.

              In pratica G-S non intende finanziare ricerche mediche che non siano un business sostenibile. Sottinteso: la salute è un bene di lusso, roba da ricchi.

              1. 1

                In effetti volevo mettere (2018) nel titolo, ma non bastavano i caratteri.

                Dal mio punto di vista la posizione di G-S è ancora più aberrante.

                Stanno dicendo che guarire i malati non è un investimento conveniente nel lungo periodo.
                Stanno parlando di esseri umani che soffrono… come merce.

              1. 1
                1. There’s nothing wrong with Perl.

                Ok, questa non me la aspettavo.

                E la cosa più strana… è che non mi scandalizza!

                Sto diventando vecchio.

                1. 1

                  Interessante excursus storico, ma più che di “credibilità” parlerei di coinvolgimento (o engagement se vogliamo usare l’inglese).

                  Anche l’analisi dei meccanismi mi sembra molto superficiale. Poteva essere attinente nel 2006.

                  1. 2

                    Ho conosciuto uno in uni che era fissatissimo con il MT di Amazon e ci passava le giornate. Ci sono molte piattaforme di “crowdworking”, la cosa davvero triste è che alcune persone sono costrette a farlo perché non hanno alternative lavorative.

                    Sono d’accordo con chi accosta sistemi di questo tipo a situazioni di prototipo o engagement con la user base e feedback generale, ovvio che se diventa quello che si percepisce leggendo l’articolo direi che non ci siamo per niente.

                    1. 2

                      fissatissimo con il MT di Amazon e ci passava le giornate

                      Suona tanto come una dipendenza…

                    1. 2

                      One conclusion is whatever libraries you publish will exist on websites forever. The underlying web platform consequently must support aged conventions indefinitely if it is to continue supporting the full breadth of the web.

                      Rendere l’esecuzione di JS opt-in (ovvero disabilitarlo di default permettendo all’utente di riabilitarlo sito per sito), renderebbe il problema più gestibile semplicemente perché la quantità di siti che usano JS si ridurrebbe enormemente.

                      In questo modo, lentamente, il web più aggiornato sarebbe quello “JS-free” e chi usasse JS per realizzare vere e proprie applicazioni sarebbe incentivato ad aggiornarle.

                      1. 1

                        Rimarrebbe però il problema di siti che non aggiornano (sarebbero probabilmente meno, ma non ci sarebbe nessun vero incentivo ad aggiornare le librerie).

                        Una soluzione più drastica sarebbe quella di ridurre il supporto alle vecchie feature nei browser (ma chi è che vorrebbe produrre un browser che visualizza solo il 50% del web, se non meno?) o di poter verificare la presenza di librerie più recenti e aggiungere una notifica all’opt-in, che avvisi l’utente che sta caricando roba vecchia. In questo modo ci sarebbe un incentivo ad aggiornare: molti utenti potrebbero decidere di non fare opt-in su siti non aggiornati. Ci vedo però due controindicazioni grosse:

                        1. Il caricamento della pagina rallenterebbe ulteriormente
                        2. Probabilmente (ma vale anche per l’opt-in generico) verrebbe percepito dall’utente medio allo stesso livello degli stramaledetti banner dei cookie: un fastidio inutile.

                        Temo che in questo caso, più che un problema di tecnologia, ci sia un problema di mentalità: chi sviluppa front-end (ma probabilmente vale anche per i back-end, solo che non lo vediamo così tanto) dovrebbe avere la sana abitudine di aggiornare spesso le proprie dipendenze.

                        1. 1

                          la sana abitudine di aggiornare spesso le proprie dipendenze.

                          Non è così semplice.

                          Si tratta di mettere a preventivo (e far pagare al cliente) un costo periodico pari al 5% dello sviluppo JS complessivo per ogni dipendenza diretta ed indiretta.

                          Prova a spiegare al tuo cliente che deve pagarti circa il 50% del costo di sviluppo ogni anno per aggiornare le tue 10 dipendenze quando i loro autori (cui non frega nulla ne di te ne del cliente, a meno che non sia un loro competitor) decidono di rilasciare una nuova versione.

                          Immagina la scena.

                          E poi pensa se, invece, fossi costretto a ridurre le dipendenze a 0 (perché una testata giornalistica NON è un applicazione).

                          1. 2

                            Prova a spiegare al tuo cliente che deve pagarti circa il 50% del costo di sviluppo ogni anno per aggiornare le tue 10 dipendenze quando i loro autori (cui non frega nulla ne di te ne del cliente, a meno che non sia un loro competitor) decidono di rilasciare una nuova versione.

                            Ormai tutti vogliono fare gli agili, no? Basta parlargli di “manutenzione agile”. Un articolo che ho postato settimana scorsa dà già qualche suggerimento in questa direzione. Aggiungici che la “manutenzione agile” sarebbe il sogno di ogni società di consulenza all’italiana, con ore e ore fatturabili per ogni cliente. Mi stupisco non sia già uno standard, onestamente.

                            perché una testata giornalistica NON è un applicazione

                            Però tutti vogliono essere un’applicazione e vedrai che troveranno il modo di esserlo lo stesso. Anche soltanto per avere le animazioni.

                            1. 1

                              Ormai tutti vogliono fare gli agili, no?

                              Dipende molto dal cliente.

                              Il manager che spende soldi altrui sarebbe felice di sottoscrivere un contratto di manutenzione del genere, se non altro per avere un capro espiatorio da sacrificare in caso di problemi.

                              L’imprenditore che spende soldi propri, potrebbe invece preferire chi gli vende un prodotto finito, stabile e sicuro.
                              Il problema, purtroppo, è che non può distinguere il ciarlatano dall’esperto.

                              Ora, questo è vero anche per la prima situazione, ma al manager non frega molto: sul numero di fornitori, l’importante è che la maggioranza sia adeguata fintanto che lui rimane in azienda.

                              1. 2

                                Sono considerazioni valide, ma una soluzione “lato developers” ha comunque più possibilità di una “lato browser”: da una parte ci sono grossi produttori di browser che hanno chiari interessi a mantenere attivo di default JS, perché i soldi li fanno con la pubblicità e la profilazione (sì, Google, sto guardando te); dall’altra ci sono gli utenti, che percepirebbero questo pulsante di opt-in (supponendo che arrivi “dall’alto”) come l’ennesima rottura dopo i cookie. Probabilmente vedremmo estensioni come le varie “I don’t care about cookies” proliferare per accettare in automatico o qualcuno cliccherà “OK” ogni volta senza leggere.

                                Di fatto saremmo punto e a capo (anche superando le resistenze dei browser). Una soluzione che faccia presa sulla cultura di chi i siti li crea (che potrebbe anche essere un bel “usate meno JS possibile, tanto pure le animazioni le potete fare con HTML+CSS”) avrebbe il vantaggio di bypassare sia le resistenze dei browser che quelle degli utenti.

                      1. 3

                        Notare le opzioni predefinite.

                        Bisognerebbe suggerire una shortcut: “Regala ai GAFAM”.

                        1. 2

                          ma è una mia impressione o negli ultimi 6 mesi sono usciti sempre più font per dev? non sono uno che si interessa del tema ma è solo una cosa di cui si parla di più o c’è stata effettivamente un’accelerazione?

                          1. 2

                            È tutto un tripudio di nuovi font, perfino i Francescani

                            1. 1

                              Frati open source

                            2. 1

                              Boh, a me non sembra ne siano usciti così tanti ma forse mi sono perso qualcosa.

                              Comunque, se c’è, l’accelerazione potrebbe essere nel fatto che i nuovi font mi sembrano tutti con le ligatures. Proprabilmente c’è un passaggio generazionale dei font.

                              1. 1

                                È una sensazione che ho avuto anch’io. Non riesco a capire se ne stiano effettivamente uscendo di più o se, semplicemente, il discorso abbia più presa e i nuovi font mi raggiungano prima di cadere nel dimenticatoio.

                                1. 1

                                  Certamente non è una novità.

                                  Se la memoria non mi inganna sono almeno 10 anni che la questione “ font per lo sviluppo software” esiste.

                                  Il tema è interessante da un punto di vista UI e cognitivo, ma viene spesso ridotto ad un singolo aspetto del problema.

                                  La leggibilità di un testo dipende dal testo stesso (ovvero dal linguaggio e dall’alfabeto in cui è espresso), dall’impaginazione e dai colori in cui è scritto etc…

                                  E naturalmente dalla cultura di chi legge.

                                  Fintanto che la programmazione non diventerà patrimonio condiviso, ottimizzare questi aspetti rimarrà secondario.

                                  1. 1

                                    Ecco, però tu che hai più esperienza di me e chobeat probabilmente riesci a rispondere al nostro dubbio: è vero che se ne parla di più rispetto a prima, o è solo un cambiamento nella geometria delle filter bubble a farcene arrivare di più?

                                    1. 1

                                      Beh, io non so quanto ne sentiate parlare tu e @chobeat.

                                      Nella mia bolla, l’andamento è abbastanza sinusoidale. Il periodo è di circa 2 o 3 anni.
                                      Ma potrebbe dipendere semplicemente dal tempo che io ho da dedicare alla materia.

                                      Personalmente non ho notato grandi variazioni (ne vere novità…) nell’ultimo anno.

                                      1. 1

                                        Nella mia bolla, l’andamento è abbastanza sinusoidale. Il periodo è di circa 2 o 3 anni.

                                        In effetti, io ho iniziato a sentir parlare di font per sviluppatori circa 2 anni fa. Ho però notato che nell’ultimo anno me ne sono passati davanti molti di più, con una marcata accelerazione negli ultimi 6 mesi circa. La mia sensazione è che il tema sia riuscito a entrare nella mia bolla, però ero curioso di sapere se ci fosse anche un fattore esterno.

                                        ne vere novità…

                                        Sì, sono comunque tutti uguali.

                              1. 2

                                Al caro Lennart vorrei erigere un monumento, perché systemd mi ha risolto un sacco di problemi. Lo dico da sistemista. L’unica osservazione che si può fare è: ma perché nessuno ci aveva pensato prima di lui?

                                La velocità del boot, benché benvenuta, non è la ragione principale per apprezzarlo. È Un tale capolavoro che è secondo per importanza solo al kernel. E ha ancora da crescere parecchio, visto che tutto ciò che permette il kernel può essere abilmente sfruttato per alleggerire il lavoro di chi scrive software. È esattamente ciò di cui il kernel Linux aveva bisogno - e non sto parlando con enfasi.

                                Il fatto è che certi concetti sono alquanto obsoleti. Per esempio: un’unica cartella /etc con le configurazioni è comoda, sì… se si pensa a un sistema con poche decine di processi e servizi. Ma poi, dev’essere scrivibile? Chi deve poter accedere? E se per scrivere ci vuole il permesso di root, significa che “qualcuno” può vedere (o modificare!) comodamente la configurazione di “qualcun altro”? E se poi il sistema dev’essere embedded (cioè col minor spazio possibile “scrivibile”, perché tutto ciò che è read-only si può mettere su EPROM/ROM o periferiche in cui solo la write è critica), dove vanno spostati i file di configurazione che devono restare scrivibili? E come si può fare per garantire che un tal processo non abbia accesso a tale o talaltra directory? O rendere tale alberatura solo in lettura “per gli altri” e anche scrivibile “per me”? O limitare tali e talaltre capabilities del kernel?

                                L’articolo è di pura politica. Ti è antipatica la Red Hat? Ti è antipatico Poettering? Allora sei il benvenuto. Altrimenti potresti accorgerti che a “cooperare strettamente col systemd” il tuo servizio ha tutto da guadagnare. Non devi più inventarti una soluzione di un pidfile per evitare di partire due volte, e una per ripartire quando vieni chiuso per qualche motivo. Non devi più preoccuparti di controllare con che user sei partito, di blindare la tua directory temporanea, di prevedere una directory dove riversare le tue poche decine di righe di log, di prendere contromisure per impedire che altri processi scrivano nelle directory che al più concedi solo di leggere… In altre parole, systemd scarica sull’amministratore di sistema (e in poche, concise, chiare righe di un file di testo) le “cose di sistema” di cui tipicamente i servizi si affannano a compiere alla partenza. Che in due righe di configurazione può stabilire che tale alberatura è scrivibile solo da te (con un gioco di mount private previsto dal kernel), riducendoti il tempo in cui ti è necessario avere i privilegi di root o addirittura rendendoli non più necessari per le inizializzazioni.

                                Che la RedHat persegua questi obiettivi, è a dir poco lodevole - tanto più che systemd è in LGPL. Ad essersi scottati sono quelli che pensavano di gestirsi systemd col solito sistema del mantenere un’unica versione e mandare per un paio d’anni (o più) solo le patch di sicurezza. Andrà a finire - con loro suprema ignominia - che lo stesso sorgente, se eseguito da un systemd è più sicuro che se eseguito in un Linux senza systemd, perché nel secondo caso le precauzioni sono solo quelle prese dal software, nel primo caso si aggiungono le limitazioni che il maintainer/packager aveva esplicitamente aggiunto.

                                L’unico ragionevole timore dovrebbe essere l’eventualità (piuttosto improbabile, visto che sarebbe “politicamente” controproducente per Red Hat) che una futura versione del systemd venga rilasciata non più sotto LGPL ma con qualcosa di restrittivo o di closed-source con supporto esclusivamente commerciale (può succedere, è già successo, per esempio nel caso di osxfuse).

                                1. 2

                                  Grazie @alf per la tua prospettiva sistemistica.

                                  Per quanto mi riguarda, IBM non gode della mia simpatia, ma guardo a systemd da una prospettiva diversa che è sia tecnologica (architetturale) che politica.

                                  Oltre alle osservazioni dell’autore (che condivido) credo che systemd persegua esigenze che lo rendono inevitabilmente troppo complesso. Attenzione, complesso, non significa necessariamente difficile da usare: Per esempio Google (il motore di ricerca) è facile da usare, ma estremamente complesso (difficile dire se “troppo”, in questo caso). Nel caso di systemd, la maggioranza della complessità è interna, nascosta dall’amministratore che lo usa (da cui credo derivi il tuo apprezzamento), ma rimane un problema architetturale e politico.

                                  Architetturale perché la sicurezza di un sistema è inversamente proporzionale alla sua complessità.
                                  Per esempio, se non erro, tutti i problemi che descrivi sono risolvibili con bind.

                                  Politica per diverse ragioni:

                                  • portabilità: qualunque software dipenda da systemd, dipende da Linux e diventa meno portabile
                                  • ridotta varietà: la ridotta portabilità del software aumenta i costi per la realizzazione sistemi alternativi (e migliori) di Linux (per non parlare della sciagurata scelta di Debian di farlo diventare il sistema di default)

                                  Purtroppo, come sottolinea l’autore, systemd si è imposto attraverso tattiche commerciali che non tengono conto di questi fattori architetturali (e che anzi li considerano un potenziale vantaggio per i competitor). Tattiche di lobbying e lock-in che peraltro funzionano in ogni settore in cui non ci sia una visione architetturale, di insieme, sufficientemente diffusa.

                                  Di conseguenza, considero systemd un sintomo di un problema più grave.

                                1. 2

                                  Writing for People who have better things to do with their lives.

                                  Thinking for People who have better things to do with their lives.

                                  Living for People who have better things to do with their lives.

                                  1. 1

                                    Però standard e protocolli sono due cose diverse.

                                    Ci sono standard che non hanno nulla a che fare con protocolli e protocolli che non sono standard.

                                    1. 2

                                      Non vedo quale sia il problema… non e’ che debba essere un contenuto che include entrambi i tag…

                                      Protocolli si riferira’ in genere a protocolli condivisi, non credo ci siano molti articoli sul protocollo interno di alcuna applicazione che non sia pubblica… Con questa premessa, un protocollo pubblico in qualche modo definisce una sorta di standard, almeno per i sistemi che si vogliono allacciare a quel protocollo… Questo per dire come mai ho associato le due cose…

                                      Mi sembra uno spreco avere due tag diversi, visto che ai miei occhi c’e’ una discreta correlazione

                                      1. 1

                                        “formati”? troppo generico?

                                        1. 1

                                          Temo di sì.
                                          Ci finirebbero articoli da CSV, a TCP, da ELF a POSIX (ma cosa in POSIX?)

                                          C’è una certa continuità implementativa fra protocolli di comunicazione e formati (in fondo, si tratta sempre di stabilire come interpretare una sequenza di byte), ma i protocolli di comunicazione includono il tempo (timeout, ordine dei messaggi etc).

                                          Il concetto di standard, invece, è totalmente ortogonale ed implica una organizzazione delegata alla creazione ed al successivo mantenimento dello standard. Implica procedure, relazioni politiche e di potere.

                                          Dire che qualunque formato è uno standard per chi vi vuole aderire, svuota completamente il significato del termine.

                                          Se così fosse, UNIX sarebbe stato uno standard sin dall’inizio! :-D

                                      1. 1

                                        Uhm… direi che qualcuno ne parla… ;-)

                                          1. 1

                                            Loro mi pare siano gli autori dello studio linkato. Volevo postare loro direttamente anche ieri, ma non sono riuscito a raggiungere un menù in inglese e dopo un po’ mi sono arreso al fatto di non saper parlare norvegese…

                                          1. 1

                                            HTTP over QUIC over UDP over IP. Stanno frammentando lo stack così tanto che stanno arrivando all’ISO/OSI. Il che non è assolutamente un male.

                                            1. 1

                                              HTTP: HyperText Transfer Protocol.

                                              Non è un nome dato a caso. E fintanto che rimarrà il canale su cui passano anche ipertesti, sarà un pessimo protocollo RPC.

                                              HTTP/3 serve solo a Google e a colossi della sua portata.
                                              D’altronde è sempre questione di marketing e Google in questo è molto brava.

                                            1. 3

                                              Questa storia mi ha sempre affascinato. Chissà cosa sarebbe stata l’Italia e forse l’Europa con Olivetti e Mario Tchou vivi e pensanti per tutti gli anni ’60 e ’70.

                                              1. 2

                                                Chissà cosa sarebbe stata l’Italia…

                                                Ciò che potrebbe diventare anche oggi.

                                                Nella vita, l’unico modo certo di fallire è rinunciare.

                                                1. 1

                                                  Ciò che potrebbe diventare anche oggi.

                                                  In un mondo globalizzato, globalista e dannatamente più veloce? Con il capitalismo della sorveglianza? Con la politica morta e definitivamente rimpiazzata dal marketing?

                                                  Si parla di altri tempi, altri mondi e altre persone. Quello che potrebbe diventare oggi è qualcosa di sicuramente diverso.

                                                  1. 3

                                                    In un mondo globalizzato, globalista e dannatamente più veloce? Con il capitalismo della sorveglianza? Con la politica morta e definitivamente rimpiazzata dal marketing?

                                                    No: in un mondo che non è ciò che appare. ;-)

                                                    Hai mai considerato l’ipotesi che questa rassegnata sottomissione potrebbe non essere farina del tuo sacco?

                                                    Quello che potrebbe diventare oggi è qualcosa di sicuramente diverso.

                                                    Beh… naturalmente non intendevo che avremmo ripreso tutti a viaggiare su due cavalli.

                                                    Intendevo semplicemente che ciò che vediamo intorno a noi sono i primi, confusi, vagiti dell’informatica.
                                                    Tutto può ancora cambiare.

                                                    A meno che… ;-)

                                                    1. 2

                                                      Non è assolutamente rassegnata sottomissione la mia, non sto dicendo che non ci sia via di scampo. Sto dicendo che l’informatica in quanto tale non basta più, se mai è bastata, a migliorare la vita delle persone. Se Adriano Olivetti nascesse oggi, il suo esperimento di imprenditoria non capitalista sarebbe stroncato sul nascere dalla concorrenza spietata del mondo globalizzato, e questo è un problema di politica e di società, non di tecnologia.

                                                      1. 2

                                                        Perché, negli anni 60 tale progetto non fu stroncato?

                                                        l’informatica in quanto tale non basta più

                                                        Assumi che l’informatica abbia già mostrato il proprio pontenziale.
                                                        Io invece sostengo che siamo ai geroglifici.

                                                        è un problema di politica e di società, non di tecnologia.

                                                        L’innovazione tecnologica favorisce o mortifica le evoluzioni socio-politiche modificandone drasticamente le rispettive probabilità. Non è un caso che la ricerca tecnologica sia stata spesso strettamente legata al potere e alla guerra.

                                                        Dalla scrittura, alla vela, al mulino, alle fogne, alle strade, alla stampa, alla ghigliottina, alla crittografia etc… ogni innovazione tecnologica ha abilitato e favorito cambiamenti storici, solitamente incrementando la complessità politica-sociale delle comunità in cui operavano.

                                                        I “social network” (centralizzati o meno) sono solo un nuovo passo in questa direzione.
                                                        Servono per aumentare ulteriormente la complessità organizzativa dell’umanità, coordinando le azioni individuali a nostra insaputa. Come in passato, questo significa necessariamente ridurre la libertà individuale. Si punta a controllare l’input degli esseri umani per controllarne l’output (in comportamento).

                                                        Dunque se è un problema politico allora è necessaria una innovazione tecnologia per superarlo.
                                                        (NOTA: superarlo, non necessariamente risolverlo)

                                                        Per fortuna l’innovazione tecnologica non è ancora completamente prevedibile.
                                                        Per cui, se la tua non è rassegnata sottomissione, ti consiglio di iniziare a pensare alla tecnologia per ciò che è: la più efficace forza politica ad agire nella storia. Gli altri già lo fanno. ;-)

                                              1. 1

                                                Di fronte all’opacità e alla segretezza che accompagna questa rivoluzione, che ci vuole ignari come le cavie degli esperimenti degli etologi, il primo passo è la consapevolezza e l’acquisizione di uno spirito critico.

                                                Non mi piace scrivere ovvietà, ma il primo passo è necessariamente comprendere come questi sistemi funzionano.
                                                Da un punto di vista tecnico e cognitivo.

                                                Senza tale comprensione profonda, anche lo spirito critico rimarrà comunque manipolabile ed orientabile a piacimento di chi controlla input ed output di ciascun “utente”.

                                                L’ignoranza è debolezza e fragilità. Solo dove c’è ignoranza diffusa, la conoscenza diventa potere.


                                                @chobeat sarebbe interessante aggiungere a Gambero una riga con l’elenco degli host contattati da una certa pagina web. Così che prima di cliccare uno sappia chi andrà ad informare.