On 17 Feb 2002 at 0:06, Pier Luigi Fiorini wrote:
[snipped here and there]
> > mmm appunto... ma perchè una volta che ho installato SuSE/Red
> > Hat/Debian... non posso fare il resto dai sorgenti? perchè devo
> > dipendere da un backend di una distro?
> Perchè bisogna guardare in faccia alla realtà.
> Ogni distro ci vuole mettere del suo, quindi si inventano un modo non
Si ma realismo non è necessariamente sinonimo di fatalismo :)
> distribuzione vuole essere fatta a suo modo. Purtroppo per come la vedo
> io se LSB darà i frutti sperati sarà già un miracolo.
Ma porti jella.
> > Secondo me a un occhiata superficiale XST non risolve alla base il
> > problema...
> 100% d'accordo.
> È solo un paliativo, e lasciamelo dire, molto ben riuscito.
> Vedi paragrafo precedente.
Usato con successo? anche per "portare" cfg da una distro all'altra?
> > Parsing and analisys of the system configuration.
> > Sembra prescindere dal provvedere uno standard alla base che
> > suggerisca come realizzare i pacchetti non solo per indicare le
> > dipendenze tra applicazioni/librerie ma le dipendenze/correlazioni tra
> > file di configurazione.
> Per certe cose lo standard c'è, per come la penso io.
> Mi riferisco a quelle cose tipo lilo o apache.
> Vedi l'inizio del mio reply.
non ci siamo su quello che intendo per standard... nel senso che ci
sono i backend... OK! ma rimango dell'idea che semplicemente se ai
pacchetti venisse aggiunto un file per indicare le dipendenze dei file
di configurazione di altri pacchetti e si realizzasse un browser di
questi file per spostarsi da un file di configurazione all'altro, anche
cambiare le cose a mano sarebbe MOLTO più semplice...
La GUI per quanto comoda a volte, è inutile se poi le cose NON
funzionano perchè c'è qualche porcheria che collide/dimenticata da
qualche parte.
> > Il risultato è che il whitepaper annovera un capitolo "The current
> > components" che non è altro che una lista dei pezzi di sistema che il
> > programma può supportare.
> > Questo è un deterrente al successo di nuove applicazioni che se non
> > supportate da questo tipo di tool (che come i tool click click crea
> > dipendenza) non avrebbero diffusione pari a quella delle applicazioni
> > supportate...
> Basta scrivere un opportuno backend e frontend.
> Ho capito il ragionamento che vuoi fare, ma è la strada del "punta e
> clicca". Puoi approvarla o meno, ma è così. A me le gui piacciono un
Giusto per essere sicuri di essere stato chiaro, intendevo che una
volta che si impone un tool di configurazione basato su XST, magari con
un frontend luser friendly (l intenzionale), le nuove applicazioni si
devono adeguare a questa logica che mette al centro un tool che finisce
per essere gestibile solo dalle distro e non l'applicazione. Non è
affatto una critica ai tool GUI.
Realizzare un backend richiede la conoscenza di come una distro piazza
i suoi file etc... e ogni backend deve tener conto delle differenze tra
le varie distro... a questo punto è ovvio che il soggetto più
avvantaggiato nella realizzazione di un backend è proprio la distro...
e sei al punto da capo che per installare gli rpm devi prendere gli rpm
di quella distro... e quando esce la release n+1 del pacchetto che ti
interessa devi aspettare che la distro faccia il suo rpm e anche in
questo caso non hai un buon controllo sulla cfg ma ti devi accontentare
di quello che la distro pensava fosse ragionevole come cfg.
Certo che per qualcuno non è questo gran sbattimento, perchè ha la
mano, lo fa da un sacco di tempo, sa dove mettere le mani etc... ma
questo non significa che non ci possa essere un approccio più
razionale.
> casino, per la configurazione vado ancora a mano (rischiando di
> diventare cieco), ma alcune volte uso dei tool grafici perchè sono
> pigro.
OK... ma ogni applicazione ha il suo backend e frontend la
realizzazione dei quali può essere un casino per via delle dipendenze.
Questo rallenta i tempi di sviluppo e mette nelle mani di chi gestisce
l'organizzazione delle distro la realizzazione di backend ragionevoli e
funzionanti poichè è necessario sapere il dove e il come di molte cose.
Invece spostando queste informazioni all'interno dei pacchetti stessi,
in realtà per arrivare a livelli più che soddisfacenti almeno per
sapere cosa si stà facendo e se si stà dimenticando qualche cosa
basterebbe un semplice script che ti fa passare da un file di cfg
all'altro usando come "guida" le stesse informazioni contenute nel
pacchetto.
Ovviamente chi realizza un pacchetto sa senz'altro il come... e il come
molto spesso è gia spiegato nei file di doc del pacchetto stesso (ma
anche qua manca uno standard help<->opzione di configurazione).
Aggiungere info sul dove/correlazione con altri pacchetti probabilmente
non costituirebbe operazione sovrumana per chi ha realizzato il
pacchetto...
Se queste info hanno uno standard la realizzazione di un tool che
permetta di surfare tra i vari file di cfg in maniera razionale ed
efficente non dovrebbe essere drammatica, che sia grafico o no è il
meno.
--
Salve
Ivan Sergio Borgonovo
http://www.webthatworks.it/
|