Alfonso Maruccia

Node Package Manager, disastro che compromette Linux

L'ultima versione del package manager di JavaScript include un bug estremamente pericoloso, un problema che può portare alla compromissione di un'intera installazione Linux. Un caso che alimenta polemiche in salsa FOSS

Roma - È stata una settimana davvero pericolosa per gli utenti di Node Package Manager (npm), tool per l'automazione della gestione dei pacchetti JavaScript usato - tra gli altri - nell'ambito del progetto Node.js: gli sviluppatori hanno rilasciato una nuova versione del software, ma gli utenti hanno in seguito scoperto che la release includeva un bug dagli effetti a dir poco disastrosi.

Quando viene lanciato come root tramite il comando sudo, infatti, npm 5.7.0 causa un cambiamento a cascata nei permessi del file system di un'installazione Linux cambiando proprietario a directory di importanza cruciale come /etc, /usr e /boot.

Il risultato finale del bug è la compromissione del sistema operativo con crash, applicazioni non più funzionanti o addirittura l'impossibilità di avviare il PC. E il problema non riguarda solo gli OS Linux, visto che sono in seguito emersi casi di utenti che hanno sperimentato il problema anche su macOS e FreeBSD.
Il bug è stato risolto piuttosto in fretta e gli sviluppatori hanno distribuito una nuova versione di npm (5.7.1), e a quanto pare la versione precedente non era pronta per una distribuzione ufficiale ma avrebbe dovuto essere considerata come una release ancora provvisoria.

In ogni caso non è la prima volta che un baco nel codice di npm produce effetti disastrosi sull'ecosistema FOSS, e ora le (prevedibili) polemiche si concentrano sulla fragilità della gestione di un progetto così importante per JavaScript e Node.js - un progetto che al momento può contare solo sugli sforzi di due programmatori a tempo pieno.

Alfonso Maruccia
Notizie collegate
46 Commenti alla Notizia Node Package Manager, disastro che compromette Linux
Ordina
  • "Quando viene lanciato come root tramite il comando sudo, infatti, npm 5.7.0 causa un cambiamento a cascata nei permessi del file system"

    ...

    "casi di utenti che hanno sperimentato il problema anche su macOS e FreeBSD."

    La domanda sorge spontanea: cosa casso c' entra "linux" piazzato lì nel titolo?
    non+autenticato
  • Non ho letto chi è l'autore...
    non+autenticato
  • Ah ecco.
    Ho letto ora.
    non+autenticato
  • - Scritto da: ...

    > La domanda sorge spontanea: cosa casso c' entra
    > "linux" piazzato lì nel titolo?

    Si, vero. Ma è anche vero che tipicamente viene usato linux per queste cose.
    FDG
    11049
  • - Scritto da: FDG
    > - Scritto da: ...
    >
    > > La domanda sorge spontanea: cosa casso c'
    > entra
    > > "linux" piazzato lì nel titolo?
    >
    > Si, vero. Ma è anche vero che tipicamente viene
    > usato linux per queste
    > cose.

    A sentire i vari maxsix, bertuccia e macachi vari qui sul blog, gli sviluppatori sono tutti passati al sistema fuffoso della mela putrescente. E colpisce anche loro.
    non+autenticato
  • - Scritto da: iShit
    > - Scritto da: FDG
    > > - Scritto da: ...
    > >
    > > > La domanda sorge spontanea: cosa casso c'
    > > entra
    > > > "linux" piazzato lì nel titolo?
    > >
    > > Si, vero. Ma è anche vero che tipicamente viene
    > > usato linux per queste
    > > cose.
    >
    > A sentire i vari maxsix, bertuccia e macachi vari
    > qui sul blog, gli sviluppatori sono tutti passati
    > al sistema fuffoso della mela putrescente. E
    > colpisce anche
    > loro.

    Non ne abbiamo bisogno.
    maxsix
    11029
  • :|TristeAccidenti, che baco! Pare n'anaconda! TristeDeluso
    non+autenticato
  • Al di la del bug di npm, ma perché lo si dovrebbe eseguire come root invece che con un utente apposito?
    FDG
    11049
  • Ma perché si parla di una versione sperimentale come se l'avessero messa su tutte le macchine del mondo?

    Ragazzi, non leggete solo qui sopra.
    non+autenticato
  • - Scritto da: Chicken

    > Ma perché si parla di una versione sperimentale
    > come se l'avessero messa su tutte le macchine del
    > mondo?
    >
    > Ragazzi, non leggete solo qui sopra.

    E' indifferente. Comunque, bug o non bug, non installerei node come root.
    FDG
    11049
  • Ahhh scusa avevo capito male.
    Scusami ancora!

    In effetti è così ma, nota bene, proprio perché si stava parlando di test è saltata fuori la cosa.
    non+autenticato
  • - Scritto da: FDG
    > Al di la del bug di npm, ma perché lo si dovrebbe
    > eseguire come root invece che con un utente
    > apposito?

    Su debian e derivate (non saprei su altri lidi....) se installato da repository ufficiale npm vuole essere eseguito con privilegi elevati ogni volta che si da un npm install -g per aggiungere un pacchetto globale, e di pacchetti da installare così ce ne sono un bel po'....
    non+autenticato
  • - Scritto da: Ooopsala

    > Su debian e derivate (non saprei su altri
    > lidi....) se installato da repository ufficiale
    > npm vuole essere eseguito con privilegi elevati
    > ogni volta che si da un npm install -g per
    > aggiungere un pacchetto globale, e di pacchetti
    > da installare così ce ne sono un bel po'....

    Io lo scarico da npmjs e lo installo con l'utente di lavoro. Poi, nel caso nostro node serve solo per sviluppare. Poi usiamo webpack per assemblare il pacchetto di cui facciamo il deploy.
    FDG
    11049
  • - Scritto da: FDG
    > Al di la del bug di npm, ma perché lo si dovrebbe
    > eseguire come root invece che con un utente
    > apposito?

    Perché è un gestore di pacchetti, apt come lo lanci?
    non+autenticato
  • Beh però non ha tutti i torti, anche se alcuni pacchetti necessitano per forza di root.
    non+autenticato
  • Sono due sviluppatori a tempo pieno, quindi pagati da qualcuno, non "semplici" volontari che di giorno scrivono sul forum e di notte buttano codice su sourceforge per divertimento. Abbiamo quindi che due, si spera professionisti, programmatori hanno fatto software con bug, ok, può succedere, ed una fantomatica comunità che si accorge non per aver visto il codice (che non legge nessuno come heartbleed e altri insegnano) ma perché si accorgono tutti i permessi cambiati, i due correggono.
    Cosa insegna questo?
    A) i bug li hanno tutti (e questo si sapeva)
    B) i progetti che si vogliono mantenere hanno bisogno si sviluppatori pagati (ed i problemi ovviamente ci sono lo stesso), il mito che l'opn-source ti dia il codice e che poi puoi forkare a tuo piacimento è una balla colossale, vera solo nella teoria
    C) il codice open non se lo legge nessuno, altro mito ormai crollato
    D) rimarrebbe il mito che con l'open ti correggi il codice da solo, cosa vera ma fino ad un certo punto perché oltre ad avere le risorse in casa, bisogna poi vedere se la tua patch non vada in contrasto con la patch e/o il versioning del progetto originale

    Detto questo, tra open e closed io preferisco se posso scegliere ed a parità di prodotto l'open perché mi offre una porta aperta in più, tuttavia i conti con la realtà dimostrano per l'ennesima volta che conta maggiormente un progetto ben strutturato e supportato piuttosto il lavoro amatoriale o a tempo perso per quanto sia gratuito.
    non+autenticato
  • Gli sviluppatori e creatori di node sono ex ing. della SUN, ovvero la più tecnologica delle ultime Unix company superstiti (ad oggi restano ancora IBM ed HP)...

    Il punto semmai è che le tecnologie sbagliate, come per me è node, concettualmente, possono far scappare cosa sballate. Non centra il FOSS, l'OpenSource o lo sviluppo proprietario.
    non+autenticato
  • - Scritto da: xte
    > Gli sviluppatori e creatori di node sono ex ing.
    > della SUN, ovvero la più tecnologica delle ultime
    > Unix company superstiti (ad oggi restano ancora
    > IBM ed
    > HP)...
    >
    > Il punto semmai è che le tecnologie sbagliate,
    > come per me è node, concettualmente, possono far
    > scappare cosa sballate. Non centra il FOSS,
    > l'OpenSource o lo sviluppo
    > proprietario.

    In cosa lo trovi concettualmente sbaglliato?
    Pura curiosità
    non+autenticato
  • > In cosa lo trovi concettualmente sbaglliato?
    > Pura curiosità

    Si, anch'io sono curioso
  • Avevo risposto stamattina ma a quanto sembra il messaggio è sparito...
    Riprovo, mandando gentili auguri ai moderatori (a base di cioccolatini con lassativi al posto del liquore).

    Per quanto i "motori" (che io preferisco chiamare interpreti) js abbian fatto passi da gigante, grazie alla spinta dell'web, per me js è un linguaggio che non deve esistere, giusto buono per piccole animazioni limitate, quelle per cui è nato. Il suo design lo rende pressoché indebuggabile e con mille problemi. In più V8&c pur al netto di performance estreme sono dei mostri che nessuno al di fuori e forse pochi al di dentro del progetto stesso sanno realmente come funziona il tutto, i più o ne conoscono piccole parti o prendono proprio "la scatola chiusa" per opensource che sia.

    Da ex-SUN, ovvero gente con competenze serie e che ha visto in casa come andarono progetti come java il cui scopo, incompreso persino da parte del management SUN era il motto stesso della SUN e più in dettaglio ambiva a diventare una "piattaforma" standard su cui sviluppare un sistema, desktop "di rete" incluso, moderno che non era né possibile con il proliferare di soluzioni diverse, incompatibili e spesso parziali. 'Somma l'idea era di implementare un Plan9 mai concretizzatosi. Ecco, dopo aver vissuto questo mi sarei aspettato qualcosa di più importante, come per esempio riportare in auge il LISP nel settore "web", o magari presentare un framework basato su haskell, go o altri linguaggi con una forte ragion d'essere, un forte potenziale e ad oggi bisognosi di popolarità.

    Tanto per non riscriverlo il commento l'ho messo anche su paste2. org/Ajyb77b2
    non+autenticato
  • > Per quanto i "motori" (che io preferisco chiamare
    > interpreti) js abbian fatto passi da gigante,
    > grazie alla spinta dell'web, per me js è un
    > linguaggio che non deve esistere, giusto buono
    > per piccole animazioni limitate, quelle per cui è
    > nato. Il suo design lo rende pressoché
    > indebuggabile e con mille problemi.

    Non amo JS, ma bisogna ammettere che negli ultimi anni ha fatto dei passi da gigante (da ES6 in poi). Adesso ti ritrovi stack di sviluppo efficienti e robusti, con tutto quello che serve. Diciamo che per quel che riguarda il frontend (compreso molto mobile con reactNative), con il paradigma delle "webapp" è tutto solo javascript

    In più V8&c
    > pur al netto di performance estreme sono dei
    > mostri che nessuno al di fuori e forse pochi al
    > di dentro del progetto stesso sanno realmente
    > come funziona il tutto, i più o ne conoscono
    > piccole parti o prendono proprio "la scatola
    > chiusa" per opensource che
    > sia.

    Perché, tutti gli sviluppatori java conoscono la JVM a memoria? O PHP? (penso solo a ZEND conoscano cosa fa realmente) o .NET (peggio del peggio)? O scala?



    >
    > Da ex-SUN, ovvero gente con competenze serie e
    > che ha visto in casa come andarono progetti come
    > java il cui scopo, incompreso persino da parte
    > del management SUN era il motto stesso della SUN
    > e più in dettaglio ambiva a diventare una
    > "piattaforma" standard su cui sviluppare un
    > sistema, desktop "di rete" incluso, moderno che
    > non era né possibile con il proliferare di
    > soluzioni diverse, incompatibili e spesso
    > parziali. 'Somma l'idea era di implementare un
    > Plan9 mai concretizzatosi. Ecco, dopo aver
    > vissuto questo mi sarei aspettato qualcosa di più
    > importante, come per esempio riportare in auge il
    > LISP nel settore "web", o magari presentare un
    > framework basato su haskell, go o altri linguaggi
    > con una forte ragion d'essere, un forte
    > potenziale e ad oggi bisognosi di
    > popolarità.

    Sono d'accordo e spero che qualche linguaggio moderno (go, haskell sono buoni esempi) diventino popolari ma vedo un appiattimento verso java (con springboot) per le api/backend e app javascript (angular4, react/redux) per il FE. Spero che kotlin, vista la compatibilità con springboot venga adottato sempre di più
  • > Diciamo che per quel che riguarda il frontend
    > (compreso molto mobile con reactNative), con
    > il paradigma delle "webapp" è tutto solo javascript
    Oh, è anche peggio: pensa alle QtQuick, alle GTk recenti, alla moda di Electron ecc. Il problema è che non portano a nulla di buono. Per cantarcele chiare non avere uno "standard" desktop comune che garantisca una certa portabilità e uniformità tra piattaforme diverse è un problema, grosso, che in parte ha contribuito al passaggio dal desktop all'web. Però tutte queste soluzioni non risolvono affatto il problema, aumentano solo la quantità di porcate non interoperanti che abbiamo e anzi aiutano il paradigma web-app che avrebbe bisogno di esser stroncato come hack osceno messo in piedi pro-tempore in attesa di sviluppare una soluzione desktop coerente, moderna, come si deve.

    > Perché, tutti gli sviluppatori java conoscono la JVM a memoria?
    Certo che no, ma immagino ad es. che gli sviluppatori di Scala (non i suoi utilizzatori) l'abbiano studiata con una certa attenzione... E per mostruosa che sia l'OpenJDK è abbastanza "nota" e "letta" mentre roba come webkit, le engine js ecc al contrario sono normalmente prese così come sono "a scatola chiusa" perché sia la loro complessità sia la loro mancanza di documentazione decente sia la loro evoluzione sono tali che studiarli è più complicato di riscriverli da zero...

    > spero che qualche linguaggio moderno (go, haskell
    > sono buoni esempi) diventino popolari ma vedo un
    > appiattimento verso java
    In se Java, se il suo intento fosse stato, o anche venisse compreso oggi, non sarebbe neanche da buttare come piattaforma (ovviamente depurando tutta la spazzatura che c'è stata fatta sopra e gli abomini tipo il nexus), solo manca questo dettaglio.

    La SUN alla fine arrivò alla JVM in-kernel su OpenSolaris, ma li si fermò col passaggio ad Oracle, oggi nessuno continua in questa direzione "il Java OS" che avrebbe rilanciato l'idea alla base di Java... Go ha recuperato in parte quest'idea con "go get" e gli import reverse-fqdn-style, ovvero l'idea di creare un "ecosistema" se non FOSS per lo meno opensource distribuito via internet, qualcosa che possa "superare" o "integrare" il pkg-management classico, che alla lunga possa essere il "megaframework" su cui poter tutti lavorare. Ma siamo anni luce distanti non solo da qualcosa del genere ma solo dalla comprensione di questo e di ciò che implica. Se solo oggi dici "hey, avete presente Plan9? Le LispM? NixOS? Bé provate a metter tutto nel frullatore: avere un OS source-based, configurato con uno o pochi files di testo, replicabile ovunque, con un'architettura distribuita dove si può "scaricare" o "delegare" cosa pesanti a server remoti ecc. Pensate che figata pazzesca sarebbe!" ti guardano come un matto, non sanno manco che PLan9 questo voleva realizzare, che le LispM effettivamente erano ferro che masticava nativamente lisp, non sanno manco che NixOS rende possibile l'Infrastructure as Code come nessuno. Semplicemente nella società manageriale non c'è posto per progetti ed idee di questa portata...
    non+autenticato
  • - Scritto da: xte
    > > Diciamo che per quel che riguarda il frontend
    > > (compreso molto mobile con reactNative), con
    > > il paradigma delle "webapp" è tutto solo
    > javascript
    >
    > Oh, è anche peggio: pensa alle QtQuick, alle GTk
    > recenti, alla moda di Electron ecc. Il problema è
    > che non portano a nulla di buono. Per cantarcele
    > chiare non avere uno "standard" desktop comune
    > che garantisca una certa portabilità e uniformità
    > tra piattaforme diverse è un problema, grosso,
    > che in parte ha contribuito al passaggio dal
    > desktop all'web. Però tutte queste soluzioni non
    > risolvono affatto il problema, aumentano solo la
    > quantità di porcate non interoperanti che abbiamo
    > e anzi aiutano il paradigma web-app che avrebbe
    > bisogno di esser stroncato come hack osceno messo
    > in piedi pro-tempore in attesa di sviluppare una
    > soluzione desktop coerente, moderna, come si
    > deve.

    Beh le "webapp" per il web ci stanno o meglio, sono il web, per il desktop o il mobile è un altro discorso, di sicuro la responsabilità, soprattutto nel mobile, sono da attribuire alla povertà di possibilità che danno le API d'interfaccia native

    > > Perché, tutti gli sviluppatori java
    > conoscono la JVM a memoria?
    >
    > Certo che no, ma immagino ad es. che gli
    > sviluppatori di Scala (non i suoi utilizzatori)
    > l'abbiano studiata con una certa attenzione... E
    > per mostruosa che sia l'OpenJDK è abbastanza
    > "nota" e "letta" mentre roba come webkit, le
    > engine js ecc al contrario sono normalmente prese
    > così come sono "a scatola chiusa" perché sia la
    > loro complessità sia la loro mancanza di
    > documentazione decente sia la loro evoluzione
    > sono tali che studiarli è più complicato di
    > riscriverli da
    > zero...

    Mahhhhh tutto questo "letto" da parte degli sviluppatori java non l'ho mai visto e sinceramente la documentazione e il CoC di NodeJs sono abbastanza completi, poi sta alla gente andare a leggerseli.


    > > spero che qualche linguaggio moderno (go,
    > haskell
    > > sono buoni esempi) diventino popolari ma
    > vedo un
    >
    > > appiattimento verso java
    > In se Java, se il suo intento fosse stato, o
    > anche venisse compreso oggi, non sarebbe neanche
    > da buttare come piattaforma (ovviamente depurando
    > tutta la spazzatura che c'è stata fatta sopra e
    > gli abomini tipo il nexus), solo manca questo
    > dettaglio.

    Quello che volevo dire è che, in ambito web (quello in cui lavoro) c'è una certa "rassegnazione" ad usare java (springboot possibilmente) nel backend, in quanto per numero di sviluppatori, pattern e librerie consolidate (quelle di netflix sopra tutte) non ha rivali.
    Ormai si va per il consolidato (che funziona bene per quanto mi riguarda) tarpando un po le ali a linguaggi nuovi

    > La SUN alla fine arrivò alla JVM in-kernel su
    > OpenSolaris, ma li si fermò col passaggio ad
    > Oracle, oggi nessuno continua in questa direzione
    > "il Java OS" che avrebbe rilanciato l'idea alla
    > base di Java... Go ha recuperato in parte
    > quest'idea con "go get" e gli import
    > reverse-fqdn-style, ovvero l'idea di creare un
    > "ecosistema" se non FOSS per lo meno opensource
    > distribuito via internet, qualcosa che possa
    > "superare" o "integrare" il pkg-management
    > classico, che alla lunga possa essere il
    > "megaframework" su cui poter tutti lavorare. Ma
    > siamo anni luce distanti non solo da qualcosa del
    > genere ma solo dalla comprensione di questo e di
    > ciò che implica. Se solo oggi dici "hey, avete
    > presente Plan9? Le LispM? NixOS? Bé provate a
    > metter tutto nel frullatore: avere un OS
    > source-based, configurato con uno o pochi files
    > di testo, replicabile ovunque, con
    > un'architettura distribuita dove si può
    > "scaricare" o "delegare" cosa pesanti a server
    > remoti ecc. Pensate che figata pazzesca sarebbe!"
    > ti guardano come un matto, non sanno manco che
    > PLan9 questo voleva realizzare, che le LispM
    > effettivamente erano ferro che masticava
    > nativamente lisp, non sanno manco che NixOS rende
    > possibile l'Infrastructure as Code come nessuno.
    > Semplicemente nella società manageriale non c'è
    > posto per progetti ed idee di questa
    > portata...

    Quello che intendevo, ormai anche nel web (dove una volta si sperimentava di più) si fa fatica vedere qualcosa di nuov, si va sempre sul consolidato. Anni fa convinsi con molta fatica il management di un ecommerce ad usare clojure per tutta la parte delle transazioni finanziarie/bancarie, nonostante l'iniziale diffidenza mi hanno ringraziato per molto tempo per la drastica diminuzione di problemi/bug
  • > Beh le "webapp" per il web ci stanno o
    > meglio, sono il web, per il desktop o
    > il mobile è un altro discorso
    E questo è, IMO, un gran problema. L'web è nato per essere un sistema (iper)testuale non troppo dissimile dal concorrente gopher. Il suo scopo era soddisfare un tipo di comunicazione che mancava ai tempi: monodirezionale senza vincoli. C'erano le mail per le comunicazioni tra singoli, le mailing-list per gruppi di utenti semi-privati, i gruppi per gruppi di utenti "pubblici" ma mancava una via per cui chiunque potesse acquisire informazioni "mirate" su qualcosa, l'web era la risposta. Aver trasformato questo concetto in applicazione è semplicemente un'assurdità, che ha alcune spiegazioni, ma è pursempre assurdo. Aver di conseguenza trasformato i browser in "ambienti operativi" è un'altra assurdità.

    Il risultato di tutto ciò è la perdita del controllo di tutto ciò che è informatizzato finendo in mano a 4 gatti.

    Il desktop doveva svilupparsi in senso di rete, alcuni lo avevano capito e ci avevan lavorato con maggiore o minore successo. Il networking UNIX era limitato, andava superato, Plan9 era un'eccellente risposta, la SUN molto dopo ci provò molto più terra terra, da allora nessuno ha più fatto nulla in tal senso e la nostra "infrastruttura IT" è cresciuta sempre più come una torre di babele ingestibile...

    > di sicuro la responsabilità, soprattutto
    > nel mobile, sono da attribuire alla
    > povertà di possibilità che danno le API
    > d'interfaccia native
    Nel mobile è logico: visto il trend nessuno vuole un mobile "indipendente" come un desktop, anzi si vuol ridurre il desktop classico al mobile attuale, moderni terminali stupidi con "mainframe" "cloud" e l'utente che è solo un consumatore finale pagante e produttore di dati da monetizzare.

    > Mahhhhh tutto questo "letto" da parte degli sviluppatori java
    No, certo, intendevo che chi ha scritto clojure o scala ha studiato la jvm, chi ha scritto node non so quanto abbia studiato v8 che come documentazione ne ha grossomodo zero... Non parlo di chi programma in scala, clojure ed altri linguaggi sulla jvm, ma di chi li ha scritti, idem non parlo degli utenti di node ma di chi l'ha sviluppato

    > Ormai si va per il consolidato
    E come potrebbe esser diverso? Oggi devi consegnare applicazioni per l'altro ieri, con PM che non han mai programmato e sono veri e propri amministrativi puri e code monkeys al posto di Programmatori che son pagati "a cottimo" o quasi...

    Sviluppare oggi una webapp in chessò sbcl, go, haskell ecc avrebbe ottime potenzialità ed in molti ti ringrazierebbero, ma non sarebbe pronta domattina e questo è per la stragrande maggioranza delle aziende show stopper...
    non+autenticato
  • Grande! Finalmente qualcuno che vede in là.
    I browsers non erano (e neanche sono) concepiti per gli scopi che gli si vogliono imporre.

    Niente sicurezza.
    Niente programmabilità a livello decente : (Javascript debolmente tipizzato)
    niente supporto reale alle UI (non si può pensare di ragionare sempre a colpi di tag html concepiti per il testo)
    niente supporto multimediale o plugin (li hanno messi dentro a calci negli anni)
    flusso mono direzionale
    non+autenticato
  • Partiamo!
    > Cosa insegna questo?
    > A) i bug li hanno tutti (e questo si sapeva)

    Super d'accordo.

    > B) i progetti che si vogliono mantenere hanno
    > bisogno si sviluppatori pagati (ed i problemi
    > ovviamente ci sono lo stesso), il mito che
    > l'opn-source ti dia il codice e che poi puoi
    > forkare a tuo piacimento è una balla colossale,
    > vera solo nella
    > teoria

    Cazzata, ci sono centinaia di progetti che avanzano grazie alla community e che, al limite, vendono "venduti" con il supporto.

    > C) il codice open non se lo legge nessuno, altro
    > mito ormai
    > crollato

    Cazzata, non lo leggi tu e quello seduto vicino a te, ma in certi ambienti il codice lo leggi eccome!

    > D) rimarrebbe il mito che con l'open ti correggi
    > il codice da solo, cosa vera ma fino ad un certo
    > punto perché oltre ad avere le risorse in casa,
    > bisogna poi vedere se la tua patch non vada in
    > contrasto con la patch e/o il versioning del
    > progetto
    > originale

    Con l'open leggo il codice, dico cosa mi manca / cosa c'è che non va, mando un POC, ne discuto ed ottengo quello che mi serve.

    Successo due mesi fa con un client per database che ora, grazie a questo modo di lavorare, ha funzionalità in più per tutti.

    >
    > Detto questo, tra open e closed io preferisco se
    > posso scegliere ed a parità di prodotto l'open
    > perché mi offre una porta aperta in più, tuttavia
    > i conti con la realtà dimostrano per l'ennesima
    > volta che conta maggiormente un progetto ben
    > strutturato e supportato piuttosto il lavoro
    > amatoriale o a tempo perso per quanto sia
    > gratuito.

    Certo, ma strutturato != closed, strutturato != pagato, ma strutturato == competenza.

    Poi rimane il tuo punto A. E rimane il punto che leggi la notizia su PI. Leggila in giro, magari in inglese dalle fonti, e vedi come è andata la faccenda (suggerisco hackernews) .Occhiolino
    non+autenticato
  • eccone un altro super mega intelligente!
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 6 discussioni)