Bag13

Tutto il mondo open source di Google in un sito Web

Mountain View apre un nuovo grande portale per ricercatori e appassionati. Raccoglierà tutti i progetti open source della compagnia per favorire il progresso tecnologico condiviso

Roma - Google ha annunciato un nuovo sito Web che racchiuderà tutti i progetti open source della compagnia, un unico grande luogo virtuale a disposizione dei ricercatori e di chiunque fosse interessato a dargli un'occhiata.

Will Norris, ingegnere software per Google Open Source Programs Office, in un post sul blog ufficiale di Mountain View scrive che l'open source è una componente tecnica e organizzativa fondamentale sin dagli albori di Google, a partire dai server che usano il kernel Linux fino ad arrivare ad una cultura interna portata all'esser capaci di patchare qualunque codice, anche se realizzato da altri team.
Negli anni Google ha rilasciato milioni di linee di codice open source, avviando programmi come Google Summer of Code e Google Code-in nonché sponsorizzando progetti e community tramite organizzazioni come Software Freedom Conservancy o la Apache Software Foundation.

Adesso, a distanza di 18 anni dalla sua fondazione, Google ha dato vita a questo nuovo sito allo scopo di raccogliere tutte le iniziative, le informazioni utilizzate, le release e di dare pieno supporto all'open source.
Come si evince dal sito stesso, Google ritiene che l'open source sia un bene per tutti, in quanto incoraggia le collaborazioni e lo sviluppo tecnologico.
Google vive di software open source da sempre: senza Linux non ci sarebbe stata Google. La compagnia usa e crea codici open source in maniera abitudinaria fin dalla sua nascita.
Parlando soltanto del 2017, Mountain View ha reso open Chrome per iOS, Upspin file-sharing, E2EMail (forse il progetto più interessante, incentrato sulla crittazione end-to-end delle mail) e l'encoder JPEG Guetzli; l'apertura del nuovo sito dedicato all'open source di Google servirà per semplificare la vita agli addetti ai lavori, che potranno trovare tutto in un unico portale. Il portale non sarà però un sito di codici sorgente, ma un mezzo di collegamento ad altri siti come GitHub contenenti i progetti di Google.

Norris prosegue spiegando che non sono a conoscenza di quali progetti avranno riscontro di pubblico, quindi tendono ad aiutare i team a rilasciare codice il prima possibile. Come risultato sono stati avviati migliaia di progetti sotto licenza open, dai più grandi TensorFlow, Go e Kubernetes a progetti minori quali Light My Piano, Neuroglancer e Periph.io. Alcuni progetti sperimentali vengono rilasciati solo per divertimento.
Avendo progetti sparsi fra circa 100 organizzazioni GitHub e su Git auotgestiti da Google, era diventato davvero complicato tenere traccia di tutto.

Il sito garantisce la possibilità di dare un'occhiata al "dietro le quinte" per vedere come Google crei e programmi l'open source, visto che Mountain View sta rilasciando anche tutta la documentazione correlata su come lavora internamente, forte di tanti anni di esperienza, che possa servire da guida how to per i neofiti, o come un interessante approfondimento su un metodo diverso per chi già fa parte di questo mondo.

Gabriele La Torre
Notizie collegate
  • TecnologiaTensorFlow, l'IA di Google è open sourceMountain View rilascia il proprio sistema di machine learning sotto licenza FOSS: sarà utilizzabile sia per la ricerca che per il business e la sua evoluzione finirà per avvantaggiare la stessa Google
  • Diritto & InternetGoogle, l'open source e tutto quantoChris DiBona, open source programs manager di Google, racconta a Punto Informatico perché l'open source è costitutivo della rete e perché Apache è la pietra filosofale del software. E perché non tutto può essere sempre open
16 Commenti alla Notizia Tutto il mondo open source di Google in un sito Web
Ordina
  • Dipingere Google come un benefattore è un grottesca rivisitazione romanzata della realtà.
    non+autenticato
  • Un tempo il codice open era sparso su vari "servizi" (Savannah, Berlios, SourceForge, c'erano poi Freshmeat, vari "repo binari" terzi da RPMFind a RPMPBone a Debian Marillat ecc), 'somma c'era varietà. In seguito la varietà è pure aumentata in meglio (Launchpad, Google code ecc). I dCVS migliorano ancora: c'è il "servizio" che fa da frontend e ognuno ha il proprio repo in locale, con storia completa magari. Fossil e qualche altro permettono addirittura di avere un "sito/wiki" embedded nel repo. Oggi sembra ci sia solo GitHub.

    Alla fine i mega-repo odierni servono più ai loro gestori per avere metriche e idee, magari da rivendersi più o meno sottobanco, che ai singoli sviluppatori e alla community. Se lo mettiamo insieme alla moda delle CI, agli snap ed altri tentativi di *cancellare* la figura dei packagers riducendo le distro a "os di base" su cui installare il resto praticamente il trend è cancellare le community arrivando ad avere singoli piccoli gruppi di sviluppatori facilmente isolabili/assumibili senza più un vero tessuto comunitario che guida (e impedisce "dittature") lo sviluppo di un ecosistema. Pensateci.
    non+autenticato
  • - Scritto da: xte
    > Un tempo il codice open era sparso su vari
    > "servizi" (Savannah, Berlios, SourceForge,
    > c'erano poi Freshmeat, vari "repo binari" terzi
    > da RPMFind a RPMPBone a Debian Marillat ecc),
    > 'somma c'era varietà. In seguito la varietà è
    > pure aumentata in meglio (Launchpad, Google code
    > ecc). I dCVS migliorano ancora: c'è il "servizio"
    > che fa da frontend e ognuno ha il proprio repo in
    > locale, con storia completa magari. Fossil e
    > qualche altro permettono addirittura di avere un
    > "sito/wiki" embedded nel repo. Oggi sembra ci
    > sia solo
    > GitHub.
    >
    > Alla fine i mega-repo odierni servono più ai loro
    > gestori per avere metriche e idee, magari da
    > rivendersi più o meno sottobanco, che ai singoli
    > sviluppatori e alla community. Se lo mettiamo
    > insieme alla moda delle CI, agli snap ed altri
    > tentativi di *cancellare* la figura dei packagers
    > riducendo le distro a "os di base" su cui
    > installare il resto praticamente il trend è
    > cancellare le community arrivando ad avere
    > singoli piccoli gruppi di sviluppatori facilmente
    > isolabili/assumibili senza più un vero tessuto
    > comunitario che guida (e impedisce "dittature")
    > lo sviluppo di un ecosistema.
    > Pensateci.

    E da parecchio che ci ho pensato, e il primo passo lo feci promettendomi di non avere niente più a che fare con tutto quanto riguarda redhat e 'succursale fedora'.

    Ed ecco il perché la mia preferita Innamorato più o meno da sempre, e la Slackware, con inserimenti debian ove sia ritenuta migliore(alcuni ambiti tipo server) almeno finché Patrick riesce a mantenersi lontano da tali immonde schifezze tipo systemD, e simili.

    E tu coglionazzo di turno: non venirmi a dire ma usi pulseAudio oppure
    Avahi, che sono codice redhat. Dove posso evito tali merdaglie, ma sappiamo tutti dove stiamo andando a parare, ed è per questo che sono d'accordissimo con xte.
    non+autenticato
  • - Scritto da: Il Fuddaro
    > E da parecchio che ci ho pensato, e il primo
    > passo lo feci promettendomi di non avere niente
    > più a che fare con tutto quanto riguarda redhat
    > e 'succursale
    > fedora'.

    fedora è peggio di RHEL. Con fedora si lavora per la multinazionale (red hat) facendo da beta-tester aggratis.

    >
    > Ed ecco il perché la mia preferita Innamorato più o
    > meno da sempre, e la Slackware, con inserimenti
    > debian ove sia ritenuta migliore(alcuni ambiti
    > tipo server) almeno finché Patrick riesce a
    > mantenersi lontano da tali immonde schifezze tipo
    > systemD, e
    > simili.

    Slackware è poco libera. E' sotto la benevolente dittatura di Patrick. Solo che fortunatamente non essendo un babbeo non ci ha calato sopra systemd.

    >
    > E tu coglionazzo di turno: non venirmi a dire ma
    > usi pulseAudio
    > oppure
    > Avahi, che sono codice redhat. Dove posso evito
    > tali merdaglie, ma sappiamo tutti dove stiamo
    > andando a parare, ed è per questo che sono
    > d'accordissimo con
    > xte.

    Red hat e google si sono infiltrati ovunque, come una piovra cercano di avvolgere tutto ciò che è loro possibile. Corrompono tutto ciò che toccano. Avahi non è indispensabile e si puo' rimuovere facilmente (anche se si usa systemd). Togliere systemd è "facile" sono nelle distro che non lo prevedono. Google ha distrutto Mozilla (bravi i programmatori open source che si sono venduti per poco alle donazioni sponsorizzate!). Tra un po' dovrai fare anche a meno di firefox se non vuoi installare pulse audio (è diventato una hard dependency... e red hat ringrazia google!). Si spera sempre in un solido fork di firefox (oltre a palemoon) vedremo chi si lancia nell'avventura. Forse sarà il nostro parolaio tutto pro-opensource "Panda rossa" Ficoso
    http://www.omgubuntu.co.uk/2017/03/firefox-52-no-s...
    Per ora nessun mantainer ha avuto l'idea di fare un patch mantenendo ALSA e senza richiedere pulseaudio.
    Prima che arrivi l'anno del linux-desktop che spazza via tutti i Windows10, i sistemi gnu/linux puliti si saranno già estinti se si continua così. Tra un systemd/linux (redhat/linux) o un google/linux o un windows10, c'è poca differenza.
    non+autenticato
  • Personalmente a RH (da cui cerco di tenermi il più possibile lontano, mi pare dai tempi della 9c) do alcuni meriti: ha avuto e spinto buone idee, anche se molto spesso mal implementate.

    Per dire il lavoro che fecero con GNome2 (sia pur con assurde insistenze tipo tenere la spatial view su Nautilus (una nuova finestra per ogni dir aperta) o la barra in basso per ricordare Windows, ai tempi non lo fece nessun altro, in vari redhat-config* pur buggati eran molto ben visti e nessun altro faceva qualcosa di simile, Kickstart pur limitato è tutt'ora assai più digeribile di Preseed, Anaconda ai tempi era molto gradito, RHN d'antan non era male come supporto, gluster, spacewalk, ... molti errori, molto brutto codice ma che ha contribuito non poco alla diffusione di GNU/Linux nelle aziende. Poi certo, una simile conduzione, sempre più aziendalistica e sempre più chiusa via via che altri player (Debian prima, Ubuntu poi) prendevano campo l'ha resa invisa a tutti, per non parlare del livello di bug e problemi che non da oggi ha rispetto, appunto, ai suoi maggiori concorrenti.

    In sintesi, IMVHO, lo sviluppo delle distro GNU/Linux è passato da un po' di distro in "concorrenza" (RH, SuSe (pre-Novell, ovviamente), Ubuntu, Mandrake (pre-Mandriva/Mageia/...), Debian, Slackware, Gentoo ecc) a di fatto due player e mezzo (Ubuntu, con la "base" Debian, e RH). Slack non è più da tempo popolare, troppo lavoro manuale per tenerla aggiornata coi requisiti server e desktop attuali, Arch ha trovato una terza via tra Debian e Gentoo ma è adatta solo a chi ha tempo, passione e voglia di imparare, non è gestibile come carico di lavoro su un server o su dei desktop aziendali, le altre distro son solo copie delle principali con qualche modifica cosmetica o di nicchia. Non c'è più anche qui un vero sviluppo "comunitario". Per questo systemd è un problema, per questo GNome è un problema, RH è un problema ecc.

    E il trend peggiora sempre: solo un aneddoto di qualche anno fa, conferenza a tema DevOps di un certo livello, parla un lead-developers di una media azienda di servizi cloud: "si dovrebbe certo farsi le proprie immagini e controllare tutto... Ma non c'è mai tempo e si finisce per digitare "docker image ..." su google, tirar giù il primo link e buttarlo in produzione". Son rimasto talmente scioccato che il mio intervento subito dopo sembrò di uno scolaretto idiota. E purtroppo non quel che disse non è un caso isolato. Non c'è più la concorrenza Kickstart/AutoYast/FAI/*, si parla solo di MAAS, ovvero si parla solo di evitare deploy bare-metal in casa poiché son troppo scomodi, troppo lavoro, si parla di servizi esternalizzati il più possibile perché c'è troppo lavoro ecc ecc ecc ed il risultato è che stiam buttando un'altra decade di sviluppo tecnologico nel cesso.
    non+autenticato
  • $ wc -w tuopost
    $ 468

    468 parole in lameranese per dire che la stragrande maggioranza degli "sviluppatori" non capiscono un ca**o.

    Bellissima la testimonianza, cito:

    "si finisce per digitare "docker image ..." su google, tirar giù il primo link e buttarlo in produzione"."

    Mah.
    non+autenticato
  • La sintesi non è mai stata il mio forte, cmq "sintetizzando" non ho detto che gli sviluppatori sono imbecilli, dico che l'evoluzione aziendalistica/manageriale o aspirante tale, la polarizzazione della community dove gli sviluppatori diventan pochi, non c'è più il flusso di collaborazione, patch, scambio di idee di qualche decennio fa ecc mi preoccupa e fa male.

    Se 20 anni fa RH avesse spinto Systemd Suse avrebbe tirato fuori dal cappello qualcos'altro, idem Debian, idem Gentoo ecc e RH avrebbe perso come oggi Canonical ha perso spingendo Upstart. Se 20 anni fa (i devs Gnome) avesse fatto quel che ha fatto con Gnome3, Gnome sarebbe sparito e Unity non sarebbe rimasto il solo contendente "di larga diffusione" ecc
    c'era una certa scelta, varie community di sviluppo, oggi non c'è più.

    Gli sviluppatori fan il loro lavoro ma gli Sviluppatori®™ sono sempre stati assai pochi, il grosso del der^Hbugging della spinta evolutiva, un tempo era fatto da un fiume di patch passate via mail, in parte news tra utenti, packagers, studenti, professori e quant'altro, c'era una community. Oggi questo c'è molto meno e più si avanza meno ci sarà. La CI, le immagini precotte (che sian partizioni di SO, virtualizzazione completa o altro) ecc servon a ridurre il sistemista a "monitoratore/clicchettatore", i package tipo snap (o tipo DesktopBSD o tipo Windows) servono a marginalizzare i packagers, prima linea di patching, di fornitura di idee, di review del codice da sempre ecc.

    Quanto alla testimonianza: quel lead-developer 20 anni fa sarebbe stato licenziato in tronco ancor prima di finir la conferenza, oggi penso sia tranquillamente al suo posto e magari sia passato a ruoli manageriali. È un esempio per chiarire quanto in basso siam caduti.
    non+autenticato
  • Ragionamenti contorti a rispetto di argomenti distanti fra loro, senza riferimenti di conferma a supporto delle tesi.

    Praticamente non si capisce un c***o. Sei prolisso perchè nemmeno tu sai cosa vuoi dire.
    non+autenticato
  • Bé io sono prolisso e probabilmente in un post non eviscero molto bene un argomento che se lo vuoi veramente "analizzare" richiede un articolo di una decina di pagine... Ma non vedo questa distanza e mancanza di collegamento tra gli argomenti.

    Due articoli per darti un'idea:
    - http://kmkeen.com/maintainers-matter/
    - http://www.jedi.be/blog/2011/12/07/devops-from-a-s.../
    Il primo spiega, in ben più parole e molto meglio del mio commento precedente ciò che fan i packagers. Il secondo, se leggi tra le righe fa vedere come le aziende che tipicamente sviluppavano e lavoravano con modelli closed abbian scoperto l'opensource e l'abbian importato tenendolo nel giardinetto di casa. La parte "automazione" dei vari componenti oggi chiamati "DevOps" esiste da decenni, la parte CI è una novità che di fatto vuol togliere di mezzo la figura del sysadmin sostituendola con "test automatici" e "procedure" sviluppate più da sviluppatori che non sysadmin (pensa a come si è sempre automatizzato via script vs l'incredibile rigidezza e limitatezza del tanto lodato Ansible). Questo intero sistema non è pensato per una community di soggetti distinti sparsi per il mondo ma per una singola azienda. Nell'opensource il "testing" non è fatto via TDD e build frequenti stile CI, è fatto dagli n usecase che ogni packagers, utente, admin, implementa usando il codice sviluppato da altri, dialogando, proponendo patch, segnalando bug agli sviluppatori, i build frequenti sono sparsi su migliaia di macchina i migliaia di scenari diversi. Su scala questo non è un problema, anzi è il vantaggio dell'opensource. Per un'azienda, pur gigante, invece è un incubo. Altro incubo per un'azienda che sviluppa in casa: come fai a supportare n distro con n peculiarità, package system ecc? Risposta: non puoi. Anche qui nel mondo open non è un problema, abbiamo un po' di standard e gli sviluppatori quelli seguono, è compito di packagers, admin ecc integrare l'applicazione nella loro distro, non degli sviluppatori e questo lavoro dei packagers scopre falle, problemi, propone nuove idee ecc. Ancora, gli snap o cmq il concetto di binari linkati staticamente con tutto quel che serve (icone, confs, ...) in un solo pacchetto. È il sogno di ogni azienda: non ci preoccupiamo di packagin, differenza tra le distro ecc. facciamo ogni applicazione come una sorta di "sistema minimale" che gira su una "distro standard".

    Lo vedi così il collegamento?

    Sulla diversità in ultimo: pensa a quando Gentoo scelse OpenRC come init system; ci furono lamentele, urla al disastro o problemi? No. Quando Pardus scelse Mudur come init vi furono urla o altro? No. Quando comparve sulla scena Initng? Idem. Quando GoboLinux propose BootScripts? Idem. Perché allora Systemd ha fatto tanto baccano? Per i log binari? Per la fastidiosa scelta di mostrare output dentro un pager per default? No, semplicemente perché anni fa se una distro sceglieva un init system, per invasivo che fosse non toccava altri, anzi era una buona occasione per imparare qualcosa di nuovo. Oggi alternative "moderne" sviluppate a systemd non ce ne sono. Oggi DE moderni che possano mandar a quel paese Gnome (anche per il suo legame con systemd) non ce ne sono (Kde è oramai un massacro, Unity è Ubuntu-centrica e la 8 non è affatto pronta, E si è perso per strada, ...). Questo lo vedi no?

    L'opensource non è mai stato un ecosistema fatto di "soggetti distinti", sviluppatori, packagers, admin, utenti ecc è sempre stato un bazaar. Quel che oggi stà diventando è una cattedrale e come ESR (e la storia) ben insegna questo non è affatto un bene.

    Son stato più chiaro?
    non+autenticato
  • Chiaro...
    chi non capisce:
    1) non ha gli strumenti per intendere Annoiato
    2) oppure NON vuole capire; e lì c'è tutto un altro discorso da fare PerplessoTriste
    non+autenticato
  • Non ho inteso dire questo nei tuoi confronti: ho solo cercato di chiarire quanto scritto visto che non è un argomento troppo sintetizzabile.

    In senso generale comunque si, molta gente, la maggior parte degli utenti domestici/marginali "dei PC", smart* ecc non ha gli strumenti per capire e molti manco voglion capire, si limitano a seguire il greggie sbavando per l'ultimo gingillo stiloso che andrà nei rifiuti in un anno o due. Oggi molti "sviluppatori" di sw open sono gente nata su Windows che non ha mai visto i "vecchi unix", manco quelli attuali, e non ha idea di come sia una certa parte di IT. Per loro dire che negli anni '80 c'eran già, a titolo sperimentale, le videoconferenze, la grafica 3D ecc è come parlar di fantascienza. Dire che molte cose che oggi agoniamo esistono da decenni, solo non son mai uscite dalla nicchia è fantasia. Dire che alla fine le varie chat moderne son versioni peggiorate delle mail o delle vecchie chat, che twitter è una reimplementazione di RSS/Atom, che l'web interattivo x.y si chiamano news/nntp ecc è fantascenza, dire che c'è stato un tempo in cui c'eran gli standard, non i drivers è follia... Non lo sanno, non l'han mai visto, non l'han mai toccato. È difficile riescano a pensare in questi termini, sono vincolati al loro piccolo mondo PC credendo che l'Intel sia la fabbrica di CPU più avanzata del mondo.
    non+autenticato
  • - Scritto da: maglietta nera
    > Chiaro...
    > chi non capisce:
    > 1) non ha gli strumenti per intendere Annoiato
    > 2) oppure NON vuole capire; e lì c'è tutto un
    > altro discorso da fare Perplesso
    >Triste

    3) chi non capisce si perde in un mare di cazzate Occhiolino.
    non+autenticato