[gl-como] Distrø

[Matteo DarkFlash]

Ciao!

On 09/07/2011 01:18 PM, Nicola Viganò wrote:
> Come ogni progetto agli inizi ha sicuramente un vantaggio: poter ancora
> fare delle scelte strutturali radicali, senza doversi mantenere in
> schemi consolidati.

Sicuramente

> Vedo molte cose che prendono più da Gentoo che da arch.
> Gentoo supporta architetture di tutti i tipi, kernel/libc di vari tipi,
> compilatori (eh si pure quello!) di vari tipi, etc.
> Gentoo è rolling, con rami stabili, instabili, hard-masked e la
> possibilità di mischiare il tutto a piacimento.
> Gentoo permette sia di compilare che di usare i bindist, ossia pacchetti
> precompilati.

Sicuramente, ma gentoo non ha una gestione di tag dei pacchetti, portage
ha parti in bash che rendono il tutto non molto leggibile e (a mio modo
di vedere) anche la creazione di un nuovo pacchetto non e` cosi` veloce,
intuitiva e diretta. (Per carita`, a me gentoo come distribuzione piace
tantissimo, l'ho usata per anni e ne sono pienamente soddisfatto!).
Inoltre con gentoo sei sempre costretto ad installare pacchetti
compilando (che non e` sempre un bene, se si sta parlando di
installazioni su dispositivi come router ad esempio). Si`, volendo puoi
anche installare roba precompilata, ma gentoo non e` stata disegnata per
essere usata cosi` (e non so quanto abbia senso usare gentoo servendosi
solo di pacchetti precompilati), mentre Distrø nasce come distribuzione
in grado di essere usata e gestita semplicemente sia nel caso di
scegliere di compilare a mano, sia nel caso di scegliere di installare
pacchetti precompilati.

> Per quanto riguarda il repository, o forse intendi l'albero dei
> pacchetti, non so come funzioni su distro, quindi non posso far un paragone.
> Come non so cosa possa portare di più un sistema di tag ai pacchetti.

Imho un sistema di tag e` molto utile, in quanto puoi cercare in modo
piu` diretto e semplice i pacchetti che vuoi installare. (qui puoi
trovare alcuni semplici esempi di cio` che intendo [0]).

> La scelta di ruby come linguaggio per la gestione dei pacchetti potrebbe
> non esser la migliore. Ammetto che per certi task non si può sempre far
> tutto in C e C++, ma l'esperienza insegna che anche un linguaggio come
> python, che alle volte è provvidenziale, può risultare poco efficiente
> alla lunga.

Io personalmente appena posso evito di scrivere in c/c++, ma preferisco
un linguaggio come ruby o python, in quanto credo sia piu` semplice
modificare codice, sviluppare parti nuove e gestirlo in generale (stesso
discorso per cui prima si evitava di scrivere in assembly dove si poteva
usare comodamente C ^^). Tu fai un discorso di ottimizzazione/velocita`
finale?

> Ruby, per quel poco che ne so, ha lo svantaggio di esser un linguaggio
> troppo libertino e con la tendenza a far diventar il codice estremamente
> "messy".
> In questo mi ricorda proprio python, che con i suo sugar sintattici, può
> esser affascinante per far le cose in fretta, ma estremamente deleterio
> a lungo andare.

Non ne sono convinto, secondo me python o ruby generano codice molto
piu` pulito, leggibile e modificabile semplicemente rispetto a C o C++.

> Portage ha un percorso un po' travagliato di recente proprio per questi
> motivi appena elencati. Motivi che sono quindi determinanti nella
> nascita di progetti come paludis (sostituto di portage scritto in C++).

Ecco, qui non so cosa risponderti, non sapevo dell'esistenza di Paludis
e non ho seguito portage sotto questo aspetto.

> Anche il supporto a multipli kernel/libc e architetture non è
> necessariamente un vantaggio. Se il team di sviluppo è limitato,
> significa solo disperdere le forze.
> Per poter mantenere i pacchetti, e sopratutto mantener la consistenza
> del sistema con gli aggiornamenti non è un lavoro semplice.

Ti do ragione, infatti ora che si e` in pochi si inizia a sviluppare
cio` che si riesce. Il concetto che volevo esprimere era che la
distribuzione come struttura non deve assolutamente essere legata ad un
kernel, o ad un compilatore, o ad un'architettura, ma deve essere il
piu` possibile modulare e riadattabile alle proprie esigenze.

> Ci sono pacchetti che possono fallire la compilazione (o il
> funzionamento) in seguito all'aggiornamento di un altro pacchetto. Per
> chi non ha ed utilizza costantemente tutto il ramo che mantiene, questi
> breakage possono passare inosservati, con conseguente irritazione da
> parte degli utenti.

Verissimo, ma qui viene incontro l'idea di mantenere un ramo stable che
non deve soffrire di problemi simili.

> Una distro rolling e from sources, è uno sforzo immane. Penso che
> pensare troppo in grande fin dall'inizio non sia necessariamente un
> punto a favore :)

Non posso darti torto, ma credo che con un team di sviluppo piu` ampio
non ci dovrebbero porre troppi problemi.

> Infine un'altra nota sul packet manager, che a quanto vedo è basato su
> git. La cosa è sicuramente una bellissima idea sulla carta.
> Ho provato ad usare funtoo proprio per questo motivo. Purtroppo questo è
> stato anche uno dei motivi per cui sono scappato a gambe levate da
> funtoo, per tornare a gentoo.
> Col tempo, lo spazio occupato dai pacchetti aumenta a dismisura.
> Per qualcuno che come me, tiene l'albero dei pacchetti usa in file
> formattato e montato come loop device, per poter diminuire al massimo la
> frammentazione e migliorare i tempi di accesso all'albero, git è una
> soluzione terribile!!

Non ho fatto caso a questo problema, in effetti potrebbe essere qualcosa
di causare danni...

> Mi dispiace smontare tutto, ma sono sicuro che capirai le mie buone
> intenzioni nel volerti esporre i problemi, senza voler criticare una tua
> scelta.

Ma tranquillo! :D
Mi fa solo piacere la tua partecipazione e la creazione di una
discussione interessante/costruttiva!

> Di sicuro, più problemi si hanno e più si impara. Quindi se ti piace
> l'idea buttatici dentro!!

^^

[0] = https://github.com/distro/packo