Newsgroup: it.comp.os.linux.iniziare
Titolo: linuxbase.org

Ho notato che i vari "vendor" di linux si stanno muovendo verso la
standardizzazione...
http://www.linuxfoundation.org/collaborate/workgroups/lsb
Tra cui l'accordo su creare sistemi di pachettizzazione comune! Era
l'ora!!! (uso mandriva e non trovo mai i pacchetti per essa)



Io, da buon "anarchico", sono contrario. :-)

 
E se ció attirasse le attenzioni dei produttori di HW, ossia
favorisseil rilascio dei drivers?
-- 
"Cuando era presidente del Banco Central de Cuba firmé los billetes con
la palabra Che, para burlarme, porque el dinero, fetiche de mierda, debe
ser feo"

 
Bhe non vedo dove stia la connessione. 
I produttori non rilasciano i driver (almeno open) perchè altrimenti non
venderebbero piu' un ghello dell'hardware nuovo, visto che quel che
abbiamo è già piu' che sufficiente... se ci fossero buoni driver.
 


Sono abbastanza d'accordo, i produttori desiderano una SOCIETA' con cui
mettersi in affari, non un sistema operativo in quanto tale.
I contratti li firmi con Microsoft (e Apple), non con Windows o Snow 
Leopard.


e la linux foundation non è 1 società? ok, non sarà potente come apple o 
ms... però quello che si risparmia in sw, lo potresti spendere in hw e 
assistenza...

 assistenza...
sui veri "scopi" della linux found. non posso parlare perchè non li so,
mi auguro solo che abbia come scopo quello del miglioramento del sistema
a tutti i costi... però chi lo può sapere veramente se non i
sovvenzionatori (ibm & co)...
Però di sicuro so che ai produttori di hardware serve vendere
hardware... sempre di piu' e ancora di piu'...
Per fare questo hanno bisogno di software che succhi risorse hardware..
sempre di piu' e ancora di piu'..
Linux non è nato con questo scopo (ovviamente) e spero che non rientrerà
in queste logiche di mercato... 
Invece Ms, Apple etc potrebbero invece trovare interessante
quest'approccio.. giusto per citarne uno di esempio.. vista.. chissà
quanti nuovi pc avrà fatto vendere...
Ps: eppoi, come se gates, jobs e co. non abbiano quote azionarie delle
varie ibm, intel, amd etc etc

 che abbiamo è già piu' che sufficiente... se ci fossero buoni driver.
È che si dice a volte che l'eccessiva frammentazione porta i produttori
a non sbattersi più di tanto per rendere compatibili i drivers con
tutto il parco Linux esistente (sai costi per
sviluppare/rilasciare/distribuire binari per ogni distro esistente, o
anche solo per le pricipali). Comunque fa nulla, sento di aver detto la
mia cazzata quotidiana. Facciamo finta di nulla ;-D


 
Ma va, figurati... c'è niente di male ad esprimere la propria
opinione... sono sempre spunti di riflessione utili .. 
ciao

 Era l'ora!!! (uso mandriva e non trovo mai i pacchetti per essa)
Un sistema unico di pacchettizzazione è inutile perché un solo sistema non
può soddisfare tutte le esigenze. Si può lavorare per rendere più semplice
la pacchettizzazione di un prodotto, ma non si può uniformare il diverso.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 la pacchettizzazione di un prodotto, ma non si può uniformare il diverso.
Il gestore dei pacchetti è un altro discorso.
-- 
"Stop staring at my output: you have no life!"
(GCC on Gentoo users)
http://med.homelinux.org/spooky

 Il gestore dei pacchetti è un altro discorso.
Ma anche no. Il gestore dei pacchetti è strettamente legato alla struttura
dei pacchetti che deve gestire. Non per niente i tentativi di commistione
non hanno avuto grande fortuna.


 non hanno avuto grande fortuna.
Usare più tipi di pacchetti su un singolo sistema è un altro discorso.


 
Tratto da wikipedia
RPM also has a few advantages over some other package managers[which?]:
      * It is the GNU/Linux (LSB) standard format.
      * It is popular: the typical rpm repository (the place where the
        packages are made available publicly) contains thousands of free
        applications.
      * 
      * Basta che poi non t'arrampichi sugli specchi zzzzzipman!

 
Finalmente..allora esiste qualcuno che dice cose sensate ...
Ti quoto.. e ti ammiro.


Bene... quindi visto che il pacchetto è SOLO un archivio compresso bisognerà
avvisare i vari mantainers che tutte quelle cose chiamate script contenute
in questi archivi non servono ad una fava e che per tutti questi anni hanno
lavorato come deficienti per renderli funzionanti senza alcun motivo. Tanto
bastava cpio.
Bah...


 deficienti
s/cie/ce/


 
Deb
Debian packages are standard Unix ar archives that include two gzipped,
bzipped or lzmaed tar archives: one that holds the control information
and another that contains the data.
Rpm
Every RPM package file can be divided into four distinct sections. They
are: 
      * The lead. 
 
      * The signature. 
 
      * The header. 
 
      * The archive. 
 
Package files are written to disk in network byte order. If required,
RPM will automatically convert to host byte order when the package file
is read. Let's take a look at each section, starting with the lead. 
Il concetto è che i "famosi" pacchetti altro non sono che archivi di
librerie... punto e stop .. ci vuole tanto a standardizzarsi su un unico
formato .. anzi no.. a capire che uno standard omogeneo è meglio di un
qualcosa disomogeneo  ???
Stiamo parlando di informatica, mica di arte o cucina o donne col culo a
mandolino, grosso o ....
Tu sei contento quando vai in inghilterra ed i tuoi arnesi elettronici
non li puoi attaccare alla spina perchè a) la spina è diversa b) magari
li c'è corrente alternata e da noi continua (la sparo) ?
Tu sei contento quando vai in giappone e non puoi usare il tuo cell
perchè li vanno sulle frequenze a 1200 mhz e qui a 900 ?
Vedi tu zipman ... vedi tu... 

 in questi archivi
In genere ci sono un paio file di "configurazione": dipendenze e
descrizione, il resto sono i file del programma.
Per pacchetti particolari, tipo il kernel, a volte sono usati anche
degli script di post-installazione. Ma non è certo su queste cose che
impazziscono i manteiner.
È curioso infatti come la maggior parte dei pacchetti si possano
trasformare da rpm/deb/tgz con alien.


 s/cie/ce/
No, dai :)

 trasformare da rpm/deb/tgz con alien.
Ma anche no. I pacchetti alien-abili spesso e volentieri hanno problemi o
non si integrano correttamente nel sistema, e questo in genere vale più per
il passaggio da deb a rpm che non viceversa. Sono realmente pochi i
pacchetti che alienati funzionano in modo ottimale e con dipendenze
soddisfatte, in pratica solo quelli che utilizzano unicamente librerie
previste dalla LSB.


 > In genere ci sono un paio file di "configurazione": dipendenze e
Ho trovato la soluzione: setup.exe

 librerie... punto e stop .. 
Non è così. Ci sono script di pre/post installazione che fanno varie 
cose tipo: aggiungere utenti/gruppi, fermare/(ri)avviare servizi, 
aggiungere/modificare file di configurazione, aggiornare la cache delle 
icone etc, etc..
La stai facendo troppo facile.
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 previste dalla LSB.
C'entra il giusto che siano conformi al LSB, basta che tu abbia quello
che ti serve.
Quando "alienavo" o convertivo pacchetti con rpm2tgz, in genere si
trattava di driver per stampanti o altre periferiche per le quali
venivano rilasciati solo driver binari in formato rpm.
Se la versione del kernel era quella giusta in genere i driver funzionavano.
Credo che ora la situazione sia cambiata, ma un tempo per installare
openoffice su slackware si doveva scaricare un tar.gz pieno di rpm.
Non ricordo di aver mai avuto problemi a convertirli ed installarli, ma
la cosa era cmq frustrante.
Ovviamente non mi metterei mai a convertire da deb a rpm o viceversa un
demone, un kernel o xorg...
Non dico che rpm sia il miglior tipo di pacchetto, probabilmente sotto
molti aspetti è preferibile il deb.
Guarda la cosa da un altro punto di vista.
Se deb fosse il formato indicato dal LSB e tutti lo adottassero non ti
sembrerebbe (almeno per i nuovi utenti, per noi fa poca differenza) una
gradevole semplificazione?
Ciò non toglie che usare lo stesso tipo di pacchetto non garantisca
affatto la compatibilità tra due distro.
Ciò che ci salva è l'operosità (e la numerosità) dei manteiner che
ripacchettizzano tutto ciò che riescono a trovare.
Uso prevalentemente Arch Linux ed il suo tipo di pacchetti non è certo
uno dei più usati. Non mi sognerei mai di veder rilasciati driver in
formato pkg.tar.xz. Però prontamente nei repository di Arch si trovano i
pacchetti convertiti e pronti all'installazione.



Non credere che non ci abbiano già pensato.
Esistono vari progetti del genere, il più famoso è Autopackage.
C'è anche chi ha pensato di fare dei pacchetti stile MacOSX: un
filesystem con tutto compreso da montare in loop. come il progetto klik
http://en.wikipedia.org/wiki/Klik_(packaging_method)
Entrambi per ora non hanno riscosso il successo sperato per varie ragioni:
1) La maggior parte dei nuovi utenti usa Ubuntu ed ha a disposizione un
sistema di aggiornamento/installazione di pacchetti abbastanza
intuitivo, per cui non è una priorità adottare un sistema di pacchetti
del genere.
Cliccando su un pacchetto deb, se si è connessi ad internet, il sistema
prova ad installarlo ed a scaricarne automaticamente tutte le dipendenze.
2) Quei pacchetti "tutto incluso" non sono fatti per installare il
sistema di base, per cui si tratterebbe di affiancarli al gestore di
pacchetti già presente sulla distribuzione. Questo in alcuni casi
disorienta l'utente invece di semplificargli la vita.
3) Gli utenti più smaliziati non hanno bisogno di cose del genere, anzi...


 Un sistema unico di pacchettizzazione è inutile perché un solo sistema non
]zac[
A essere pignoli è inutile perché non è la pachetizzazione la fonte dei 
problemi, ma è quello che c'è dentro.
Infatti pachettizzare è una procedura che si può completamente 
automatizzare, cosa che già fanno le varie distribuzioni, che hanno server 
dedicati alla compilazione automatica per le varie piattaforme e per la 
pubblicazione nei repository.
L'enorme mole di distribuzioni linux, di versioni delle distribuzioni, delle 
versioni del kernel, delle librerie fondamentali, ecc. , è paragonabile 
all'uscita di una nuova versione di windows ogni sei mesi.
Tutto li il problema, se non si fanno driver/programmi autocompilanti sul 
cliente dell'utente i produttori di hardware e, molto meno, anche i 
produttori di software, ci lasciano le penne, visto che l'esiguo 'parco 
macchine pagante' non è in grado di coprire l'impegno richiesto dalla 
continua rincorsa delle nuove versioni di linux.
Altre soluzioni sono un palliativo, o semplicemente il frutto della mancata 
conoscenza della situazione.