[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux_var] snappy, i pacchetti creati da sviluppatori di terze parti e la simpatia di Canonical
Il giorno 17 giu 2016, alle ore 17:31, Elena ``of Valhalla'' <valhalla-l@trueelena.org> ha scritto:
> Un po' di giorni fa mi han segnalato questo articolo col quale sono enormemente d'accordo: non importa quanto siano di moda gli app store (o i pacchetti specifici per linguaggio), fare a meno del maintainer tradizionale delle distribuzioni è un rischio e uno svantaggio.
> http://kmkeen.com/maintainers-matter/
Ho atteso un po’ a rispondere su questo argomento perché ho voluto avere il tempo di leggere con comodo l’articolo :-)
Sono altrettanto d’accordo sull’importanza dei maintainer e sulle loro “funzioni” descritte nell’articolo. Bella lettura, la consiglio.
Ma a parte questo mi sembra che l’articolo punti sul confronto tra “un mondo con maintainers” e “un mondo stile App Store”, che è un confronto stupido da fare.
In primis sono gli utenti che scelgono…. in questo caso specifico si cita Ubuntu Snappy come “elemento abilitante” al modello senza maintainer, ma nessuno costringe gli utenti ad usarla.
Se tra X anni saremo in un mondo in cui i linux predominanti saranno “maintainerless” sarà perché se lo sono scelto gli utenti (a prescindere che sia una cosa buona o meno).
E poi una cosa non esclude l’altra… già ora potete usare, per fare un esempio a caso ma è realmente applicabile a qualsiasi distro, una Debian (con i suoi repository curati dai maintainer) a cui aggiungete un repository esterno (Postgres? Puppet? Google Pagespeed? MongoDB? Oracle Virtualbox? Enlightenment?)
Ho volutamente citato solo quelli relativi a software opensource e gestiti dall’autore stesso (gli ISV, per usare la terminologia dell’articolo), ma ne abbiamo anche di software non opensource (Google Chrome? Dell OMSA community?), oppure di non gestiti dall’ISV ma da qualcosa che somiglia più ad un maintainer non-ufficiale-della-distro (Debian Multimedia? Webupd8team? etc...).
E potrei andare avanti a lungo.
Tecnicamente lo strumento esiste già. In alcuni casi è mediamente semplice (repository DEB / RPM e simili) in altri ancora più semplice ed “aiutato” dalla distribuzione (Ubuntu PPA, Gentoo overlays, etc…). Snappy è solo un’altra voce nel coro.
> Dopodiché mi han segnalato quest'altro articolo sul motivo per cui è saltato fuori quell'articolo:
> https://www.happyassassin.net/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/
>
> che invece è da un punto di vista totalmente diverso (di chi sta sviluppando un sistema simile, se ho capito bene, o comunque che conosce bene chi lo fa), ma che mi ha lasciato senza parole quanto a scorrettezza da parte del reparto marketing di Canonical.
Io ho letto, oltre all’articolo, anche la press release di Canonical. Non sto a discutere sull’oggetto dell’annuncio (i pacchetti “snap”) se sia buono o cattivo, però devo constatare che la press release non parla assolutamente di abbandonare i metodi di packaging classici, curati dai maintainer, anzi c’è un paragrafo esplicito su "Complementary to existing Linux packages”.
Insomma c’è una feature in più, l’utente può scegliere se usarla o meno, anche se decide di usarla non deve rinunciare ai repository classici… perché c’è gente che si lamenta???
E poi mi chiedo anche come mai non si sia discusso altrettanto della “moda” recente sulla containerizzazione (che, badate bene, fa la stessa cosa: taglia via il maintainer e vi fa “succhiare” direttamente quanto pubblicato dall’ISV, incluse le librerie utilizzate).
Così a occhio e croce questa cosa di snappy sembra un po’ il porting al mondo “utenti / desktop” degli stessi concetti già presenti ormai da un po’ nel mondo “sysadmin / servers”.
Sulle questioni a favore del mondo maintaner non commento perché non sarei tanto bravo quando l’autore del primo articolo citato, vi rimando a quello.
Ma vogliamo qualche controesempio? Quanti utenti vedo sulle mailinglist che necessitano aiuto per mettere il software X sulla tal distro? E se passano all’altra distro c’è X ma manca Y?
Quanto smadonnano i vostri cari sysadmin che vogliono usare Debian (o Ubuntu, o Arch, o Gentoo, o….) sui server del vendor “X", dal momento che non esistono distribuzioni dei pacchetti software per gestirli (hint hint: io lavoro con hardware Dell)? Così finisce che non puoi scegliere e devi usare una distro specifica, o rinunciare a versioni recenti di qualcosa perché non si integrano bene, o devi sbatterti a manutenere qualcosa tu, etc etc. In tutti questi casi roba stile container, o stile snappy, etc… eviterebbe le problematiche citate.
> Elena ``of Valhalla'' - e poi qualcuno si chiede ancora perché sconsiglio ubuntu?
Ogni caso d’uso è diverso, ognuno di noi ha una testa diversa: personalmente e molto umilmente IMHO, per il mio caso d’uso (server, mai desktop), ad oggi continuo a consigliare Ubuntu (non la Snappy).
Ha release molto precise e supporto molto predicibile (ogni 2 anni esce una LTS, che “dura” 5 anni).
Consente comodamente di aggiungere pacchetti dall’esterno del mondo maintainer (tramite repo deb oppure tramite i PPA), una manna in certi casi (vuoi l’ultimo PostgreSQL stabile? vai dall’ISV e ti cucchi i pacchetti curati dal PostgreSQL Global Development Group. vuoi Puppet OpenSource, o Puppet Enterprise? vai di repository ufficiali di Puppetlabs. vuoi l’ultima OpenJDK o l’ultima Oracle JDK? ci sono dei ppa non gestiti da ISV ma da altri maintainer non-ufficiali-Ubuntu)
Non sto dicendo che uno dei due modelli è totalmente giusto e l’altro totalmente sbagliato, ma mi pare che molti titoli stile “DEB e RPM sono morti?” siano un po’ fuorvianti se non si va a fondo delle questioni.
Boh, ho buttato lì un po’ di “my two cents" sparsi… fatene ciò che volete :-)
--
Luca Lesinigo
_______________________________________________
Talking mailing list
Talking@ml.linuxvar.it
http://ml.linuxvar.it/cgi-bin/mailman/listinfo/talking