> > desktop. Sarebbe semplice e gradito se tutte le distro aiutassero questo
> > progetto nella realizzazione dei backend, e che qualche hacker di KDE
> > facesse i frontend per l'ambiente KDE. Ah dimenticavo, all'inizio (ormai
>
> 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
univoco per la configurazione del sistema.
Alcune parti, come il bootloader (sia esso lilo o grub o quant'altro) o
il server http (apache per es.) hanno una loro configurazione.
Ma le varie impostazioni di cui hanno bisogno gli script di init (faccio
riferimento ai vari file per es. in /etc/sysconfig di RH e MDK) sono
diverse da distro a distro.
E ciò è un male, però non si può fare altrimenti sarebbe un'utopia.
Nota bene, disapprovo la situazione attuale, però è inevitale perchè
ogni distribuzione vuole essere fatta a suo modo.
Purtroppo per come la vedo io se LSB darà i frutti sperati sarà già un
miracolo.
> > comportarsi in modo ottuso negando l'integrazione con KDE (del resto
> > come dargli torto, è un progetto di concorrenza). Grazie a Dio e a
> > Stallman XST (Ximian Setup Tools per i profani) è sotto GPL, quindi è
>
> 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.
> > facile per chiunque sappiamo come realizzare il codice, sviluppare i
> > frontend (magari come albero di sorgenti separato) per KDE.
>
> E di nuovo... la moltiplicazione dei problemi...
> Anzichè uno standard abbiamo più backend e più frontend ma non in
> un'ottica cooperativa/di scelta.
Non la vedo così.
XST è suddiviso in parti logiche della configurazione del sistema
(condivisioni samba, X11, utenti, etc...) e presenta una GUI per ognuna
di esse (i frontend), sotto questi frontend vi sono i backend anch'essi
disponibili per ogni parte logica e forniscono pure un output XML.
Grazie a questo output XML, ogni distro è virtualmente uguale sotto il
profilo della configurazione e per replicare la conf. di un certo
servizio da Debian a Red Hat diventa un gioco da ragazzi, anche perchè
le configurazioni possono essere archiviate e suddivise in profili.
> Purtroppo l'approccio:
>
> 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.
> 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 casino, per la configurazione vado ancora a
mano (rischiando di diventare cieco), ma alcune volte uso dei tool
grafici perchè sono pigro.
|