Ci siamo giocati PC-BSD... [Archivio] - Hardware Upgrade Forum

zephyr83

30-06-2007, 05:13

Tristezza. Tutti i grossi progetti puntano a supportare solo librerie shared rinunciando a tenere una copia privata (vedi Xorg, che dalla prossima versione userà una copia esterna di libpixman in comune con cairo in modo che entrambi i progetti beneficino subito delle ottimizzazioni senza dover aspettare per forza una nuova release) e con i .pbi qualche idiota ha pensato bene di reintrodurre tutti i problemi a livello di distribuzioni per niente. Speriamo che l'idea muoia il prima possibile.
scusa cn i pbi quali problemi ci sarebbero??? NESSUNO se nn quello di maggior spazio occupa su disco ma è una cosa irrisoria visto la capacità degli attuali hard disk. Nn è come su windows cn le dll (che mi sembra quasi più simile al sistema delle dipendenze ma meno controllato) ma come su osx! Tutto incluso in un file o cartella....poi per cancellare il programma basta eliminare quel file o quella cartella. Io un sistema migliore nn riesco a immaginarlo! Le varie distro potranno benissimo usare il sistema classico ma quelli che vogliono installarsi senza problemi un mediacenter, una dock station o qualsiasi altro programmino lo potranno fare benissimo!!!

ekerazha

30-06-2007, 09:19

che hanno "tutto dentro" senza conflitti di dipendenze e menate varie.

Il metodo migliore per avere la stessa libreria replicata inutilmente decine di volte sul disco...

Willy McBride

30-06-2007, 10:52

scusa cn i pbi quali problemi ci sarebbero??? NESSUNO se nn quello di maggior spazio occupa su disco ma è una cosa irrisoria visto la capacità degli attuali hard disk. Nn è come su windows cn le dll (che mi sembra quasi più simile al sistema delle dipendenze ma meno controllato) ma come su osx! Tutto incluso in un file o cartella....poi per cancellare il programma basta eliminare quel file o quella cartella. Io un sistema migliore nn riesco a immaginarlo! Le varie distro potranno benissimo usare il sistema classico ma quelli che vogliono installarsi senza problemi un mediacenter, una dock station o qualsiasi altro programmino lo potranno fare benissimo!!!

Scusa ma l'hai letto il mio post? Magari ti faccio un altro esempio, visto che forse non sai cosa sono cairo e libpixman.

Prendi Xorg. Fino alla release 6.9 Xorg era distribuito in un unico tarball che conteneva tutto, comprese copie private di librerie sviluppate esternamente nell'ambito di altri progetti, ad esempio libfreetype, che si occupa del rendering dei font, oppure mesa, che include i driver 3d per le schede grafiche.
Xorg (e Xfree prima) funzionava solo con la specifica versione delle librerie incluse nel tarball perché gli sviluppatori si preoccupavano di verificare la compatibilità solo quando, una volta all'anno, importavano il codice nuovo dalle librerie esterne e quindi sistemavano tutte le incompatibilità che si erano accumulate in mesi di lavoro indipendente.
Problema: il programma X si pianta a causa di un bug in Mesa, ma c'è un fix semplicissimo, oppure il driver Y aggiunge il supporto alle schede di nuova generazione. «Bene!», dirai, «dov'è il problema?» Il fatto è che nessuno testa il nuovo driver, perché tutti usano la copia contenuta in Xorg, e che il bugfix non si propaga finché gli sviluppatori di Xorg non aggiornano la loro copia di mesa, e possono passare mesi, e non fanno una nuova release, e possono passare altri mesi. C'è un motivo se Xorg è diventato modulare con la versione 7.0.

I .pbi sono antistorici, e continuano a creare problemi di questo genere anche per i progetti che si sono presi la briga di migliorare la modularità e di evitare duplicazioni incontrollate di codice. In un sistema standard, tutti i programmi che usano le gtk+ usano UNA versione di gtk+ presente nel sistema, tutti i programmi che hanno bisogno di freetype usano UNA versione presente nel sistema, tutti i programmi che usano le wxGTK, cdparanoia, numeric, boost, poppler, usano LA versione installata e condivisa da tutti, ma con i .pbi chi usa chi?

«Evince non mi fa vedere il pdf XYZ!»
«è un bug di poppler.»
«ma io ho l'ultima versione di poppler!»
«e il .pbi che versione si tira dietro?»
«mah!»

«il carattere ñ ha la gamba destra più corta!»
«sì, è perché freetype 2.a.b aveva un problema con il font, ma la nostra distro usa 2.a.c.»
«ma qui si vede male!»
«perché hai installato un .pbi con una copia di freetype e nessuno ti avverte degli aggiornamenti.»

«digikam non vede la mia macchina fotografica, ma con f-spot funziona!»
«ma entrambi usano libgphoto2, quindi dovrebbero supportare le stesse macchine.»
«ah, non so, ho scaricato i .pbi dai siti. boh, linux è una merda.»

Devo andare avanti?

W.S.

30-06-2007, 11:06

Il metodo migliore per avere la stessa libreria replicata inutilmente decine di volte sul disco...
*
... ... ...
*

Condivido.

zephyr83

30-06-2007, 19:48

Scusa ma l'hai letto il mio post? Magari ti faccio un altro esempio, visto che forse non sai cosa sono cairo e libpixman.

Prendi Xorg. Fino alla release 6.9 Xorg era distribuito in un unico tarball che conteneva tutto, comprese copie private di librerie sviluppate esternamente nell'ambito di altri progetti, ad esempio libfreetype, che si occupa del rendering dei font, oppure mesa, che include i driver 3d per le schede grafiche.
Xorg (e Xfree prima) funzionava solo con la specifica versione delle librerie incluse nel tarball perché gli sviluppatori si preoccupavano di verificare la compatibilità solo quando, una volta all'anno, importavano il codice nuovo dalle librerie esterne e quindi sistemavano tutte le incompatibilità che si erano accumulate in mesi di lavoro indipendente.
Problema: il programma X si pianta a causa di un bug in Mesa, ma c'è un fix semplicissimo, oppure il driver Y aggiunge il supporto alle schede di nuova generazione. «Bene!», dirai, «dov'è il problema?» Il fatto è che nessuno testa il nuovo driver, perché tutti usano la copia contenuta in Xorg, e che il bugfix non si propaga finché gli sviluppatori di Xorg non aggiornano la loro copia di mesa, e possono passare mesi, e non fanno una nuova release, e possono passare altri mesi. C'è un motivo se Xorg è diventato modulare con la versione 7.0.

I .pbi sono antistorici, e continuano a creare problemi di questo genere anche per i progetti che si sono presi la briga di migliorare la modularità e di evitare duplicazioni incontrollate di codice. In un sistema standard, tutti i programmi che usano le gtk+ usano UNA versione di gtk+ presente nel sistema, tutti i programmi che hanno bisogno di freetype usano UNA versione presente nel sistema, tutti i programmi che usano le wxGTK, cdparanoia, numeric, boost, poppler, usano LA versione installata e condivisa da tutti, ma con i .pbi chi usa chi?

«Evince non mi fa vedere il pdf XYZ!»
«è un bug di poppler.»
«ma io ho l'ultima versione di poppler!»
«e il .pbi che versione si tira dietro?»
«mah!»

«il carattere ñ ha la gamba destra più corta!»
«sì, è perché freetype 2.a.b aveva un problema con il font, ma la nostra distro usa 2.a.c.»
«ma qui si vede male!»
«perché hai installato un .pbi con una copia di freetype e nessuno ti avverte degli aggiornamenti.»

«digikam non vede la mia macchina fotografica, ma con f-spot funziona!»
«ma entrambi usano libgphoto2, quindi dovrebbero supportare le stesse macchine.»
«ah, non so, ho scaricato i .pbi dai siti. boh, linux è una merda.»

Devo andare avanti?
Nn dico si usare SOLO i pbi. Ogni distreo deve continuare cn il proprio sistema di dipendenze ma dare in più la possibilità dei pbi così se voglio installarmi ams oppure un mediacenter nn devo sbattermi cn configurazioni, ricompilazioni e tante altre menate! Avvio il programma e basta, quando mi rompo lo elimino in un secondo. Poi sta a chi rilascia il programma preoccuparsi di rendere disponibili versioni cn pacchetti aggiornatie nn buggati. Nn capisco quale sia il problema, basta scaricarsi un nuovo pbi aggiornato!!!

ekerazha

30-06-2007, 19:54

Nn dico si usare SOLO i pbi. Ogni distreo deve continuare cn il proprio sistema di dipendenze ma dare in più la possibilità dei pbi così se voglio installarmi ams oppure un mediacenter nn devo sbattermi cn configurazioni, ricompilazioni e tante altre menate!

Non mi risulta che per installare un .rpm, .deb, .fpm o simili siano necessarie "configurazioni, ricompilazioni e tante altre menate".

Avvio il programma e basta, quando mi rompo lo elimino in un secondo. Poi sta a chi rilascia il programma preoccuparsi di rendere disponibili versioni cn pacchetti aggiornatie nn buggati. Nn capisco quale sia il problema, basta scaricarsi un nuovo pbi aggiornato!!!
Sta a chi sviluppa il programma fare in modo che il proprio software non abbia problemi con le nuove versioni delle librerie (e se vogliamo: sta a chi sviluppa le librerie non interrompere brutalmente la retrocompatibilità senza ampio preavviso). Non c'è motivo per avere librerie uguali replicate per tutto il disco...

Willy McBride

30-06-2007, 21:43

Nn dico si usare SOLO i pbi. Ogni distreo deve continuare cn il proprio sistema di dipendenze ma dare in più la possibilità dei pbi così se voglio installarmi ams oppure un mediacenter nn devo sbattermi cn configurazioni, ricompilazioni e tante altre menate! Avvio il programma e basta, quando mi rompo lo elimino in un secondo. Poi sta a chi rilascia il programma preoccuparsi di rendere disponibili versioni cn pacchetti aggiornatie nn buggati. Nn capisco quale sia il problema, basta scaricarsi un nuovo pbi aggiornato!!!

Scusa ma li leggi i post altrui o scorri solo le prime righe per poi immaginare il resto? Cosa c'entra quello che mi hai risposto con quello che ho scritto io? Mi hai citato come soluzione quello che ho descritto come il problema!
Al di là del fatto che non ha proprio senso, perché se c'è un sistema di dipendenze è inutile il .pbi, visto che il software lo installi con il package manager, mentre se non c'è e si usano i .pbi diventa onere dell'utente aggiornarsi tutto il software e questo non è fattibile considerando che una installazione media comprende centinaia di pacchetti diversi.

Dcromato

30-06-2007, 22:51

Scusa ma li leggi i post altrui o scorri solo le prime righe per poi immaginare il resto? Cosa c'entra quello che mi hai risposto con quello che ho scritto io? Mi hai citato come soluzione quello che ho descritto come il problema!
Al di là del fatto che non ha proprio senso, perché se c'è un sistema di dipendenze è inutile il .pbi, visto che il software lo installi con il package manager, mentre se non c'è e si usano i .pbi diventa onere dell'utente aggiornarsi tutto il software e questo non è fattibile considerando che una installazione media comprende centinaia di pacchetti diversi.
Quoto.Un tempo l'idea non mi dispiaceva ma dopo ho capito il funzionamento e mi fanno letteralmente schifo...

R4iDei

02-07-2007, 00:13

Secondo me possono essere utili... faccio un esempio?

Amsn fa schifo se compilato con le "vecchie" tcl 8.4 quindi tocca compilarsi e installarsi le 8.5. Io l'avevo fatto ma poi avevo problemi con altre applicazion tcl/tk.

Si ok smanettando un po si riescono a far convivere due versioni di una stessa libreria.

Ma in un caso come questo non sarebbe utile? Io penso proprio di si.

Willi il tuo discorso non l'ho proprio capito. Parli di tirarsi dietro vecchie versione di librerie, di bug.... ma se il pacchetto pbi funziona.... funziona.

Dentro avrebbe le librerie necessarie e poco importa quale versione siano, se funzionano con qel determinato programma (perche solo per quello devono servire) bene.

Prendi l'esempio che facevo prima di amsn, le eventuali tcl/tk verrebbero solo usate da amsn dentro il pbi, tutto il resto del sistema userebbe quelle in /usr/lib

Dal mio punto di vista servirebbe solo per alcuni casi particolari ma sarebbe molto utile soprattutto abbinato alla possibilta di crearli facilmente

Mi sfugge qualcosa?

zephyr83

02-07-2007, 05:32

Non mi risulta che per installare un .rpm, .deb, .fpm o simili siano necessarie "configurazioni, ricompilazioni e tante altre menate".

Sta a chi sviluppa il programma fare in modo che il proprio software non abbia problemi con le nuove versioni delle librerie (e se vogliamo: sta a chi sviluppa le librerie non interrompere brutalmente la retrocompatibilità senza ampio preavviso). Non c'è motivo per avere librerie uguali replicate per tutto il disco...
E se il mio programma nn è nei repository che faccio??? E anche li a volte ci sn problemi se il programma usa dei pacchetti (magari compilatori) diversi da quelli presenti sul nostro sistema (magari nn ancora aggiornati)
Scusa ma li leggi i post altrui o scorri solo le prime righe per poi immaginare il resto? Cosa c'entra quello che mi hai risposto con quello che ho scritto io? Mi hai citato come soluzione quello che ho descritto come il problema!
Al di là del fatto che non ha proprio senso, perché se c'è un sistema di dipendenze è inutile il .pbi, visto che il software lo installi con il package manager, mentre se non c'è e si usano i .pbi diventa onere dell'utente aggiornarsi tutto il software e questo non è fattibile considerando che una installazione media comprende centinaia di pacchetti diversi.
Per me il mio discorso fila alla grande!!! :sofico: Il sistema delle dipendenza nn è perfetto, problemi ne crea (leggere sopra) inoltre si è costretti ad avere una connessione a internet. I pbi potrebbero favorire i programmi commerciali e sarebbero anche utilissimi per le varie riviste di linux (giusto per dirne una). Se ci fosse un programma per mediacenter in pbi ci metteri un secondo a installarlo e usarlo senza troppi problemi! Invece ci sto diventando scemo!!!! :muro: Mi consola il fatto vedere che però sn in molti ad avere il mio stesso problema :stordita:
Nn capisco perché i due sistemi nn possano convivere!!

zephyr83

02-07-2007, 05:33

ekerazha

02-07-2007, 08:13

E se il mio programma nn è nei repository che faccio??? E anche li a volte ci sn problemi se il programma usa dei pacchetti (magari compilatori) diversi da quelli presenti sul nostro sistema (magari nn ancora aggiornati)

E se non esiste il .pbi per il programma che voglio? ;) Gli "imprevisti" ci saranno sempre... se un pacchetto non è nei repository lo cerchi altrove... se voglio Pidgin per Ubuntu Feisty ad esempio, cerca su Google "Feisty Pidgin" e sicuramente lo trovi subito... e se proprio non esiste sei nella stessa situazione in cui può non esistere il .pbi ;) (anzi... magari i pacchetti .pbi sono anche più difficili da creare).

zephyr83

02-07-2007, 18:05

E se non esiste il .pbi per il programma che voglio? ;) Gli "imprevisti" ci saranno sempre... se un pacchetto non è nei repository lo cerchi altrove... se voglio Pidgin per Ubuntu Feisty ad esempio, cerca su Google "Feisty Pidgin" e sicuramente lo trovi subito... e se proprio non esiste sei nella stessa situazione in cui può non esistere il .pbi ;) (anzi... magari i pacchetti .pbi sono anche più difficili da creare).
se il pbi nn esiste usi il metodo tradizionale!!! Dove sta il problema? I pbi sn una comodità in più!

ekerazha

02-07-2007, 18:23

se il pbi nn esiste usi il metodo tradizionale!!! Dove sta il problema? I pbi sn una comodità in più!
Allora tantovale fare il "pacchetto tradizionale" anzichè il .pbi no?

CARVASIN

02-07-2007, 18:29

Allora tantovale fare il "pacchetto tradizionale" anzichè il .pbi no?

Se il pacchetto tradizionale richiedesse una certa libreria che non abbiamo?

Uno installa il .pbi...prova sto cavolo de programma...se non gli piace cancella il .pbi. si ritorna alla situazione iniziale...io sinceramente non ci vedo nulla di male. Non è cosi?

Ciao!

ekerazha

02-07-2007, 18:31

Se il pacchetto tradizionale richiedesse una certa libreria che non abbiamo?

Uno installa il .pbi...prova sto cavolo de programma...se non gli piace cancella il .pbi. si ritorna alla situazione iniziale...io sinceramente non ci vedo nulla di male. Non è cosi?

Ciao!

Installi la libreria... se non ti piace più lo togli ed eventualmente togli anche la libreria... non vedo il problema.

ekerazha

02-07-2007, 18:33

Tra l'altro non vedo tutta questa novità dei .pbi, gli eseguibili compilati staticamente con le librerie esistono da tempo (es. Skype esiste anche in versione con librerie compilate staticamente... e non ci sono .pbi e mazzi vari)

darkbasic

02-07-2007, 19:18

Infatti.. basterebbe un archivio compresso con le librerie compilate staticamente :O

zephyr83

02-07-2007, 19:29

Allora tantovale fare il "pacchetto tradizionale" anzichè il .pbi no?

no perchè se manca qualche pacchetto? e se epr caso la versione del pacchetto che ho io nn va bene? inoltre cosa devono fare "mille pacchetti" tradizionali per ogni distribuzione? 2-3 tipi di rpm, due tipi di deb, l'ebuild per gentoo, fpm per frugalware..........

ekerazha

02-07-2007, 20:18

no perchè se manca qualche pacchetto? e se epr caso la versione del pacchetto che ho io nn va bene?
Ariecco :D e se manca il .pbi?
E se la versione del .pbi "non va bene"? (???)

inoltre cosa devono fare "mille pacchetti" tradizionali per ogni distribuzione? 2-3 tipi di rpm, due tipi di deb, l'ebuild per gentoo, fpm per frugalware..........

Basterebbe adottare un sistema standard... che non necessariamente dovrebbe essere il .pbi. Se convinco tutti ad adottare il .pbi allora tantovale convincere tutti ad adottare un sistema migliore.

zephyr83

03-07-2007, 06:35

Ariecco :D e se manca il .pbi?
E se la versione del .pbi "non va bene"? (???)

Basterebbe adottare un sistema standard... che non necessariamente dovrebbe essere il .pbi. Se convinco tutti ad adottare il .pbi allora tantovale convincere tutti ad adottare un sistema migliore.
Mi sa che nn riusciamo a capirci! "Noi" sostenitori del pbi pensiamo a una convivenza fra i due modi di pacchettizzare i programmi! "Voi" invece escludete uno dei metodi!! Su linux è impossibile far morire il sistema delle dipendenze se no morirebbero la maggior parte delle distribuzioni, sarebbero quasi tutte la stessa cosa! Chi realizza una distro continuera a usare il sistema di dipendenza e questo varrà per i DE, per xorg e i compilatori. IN PIù però ci sn i pbi! Se io, software house, voglio realizzare un programma per linux, tipo un media center invece che stare ad ammattire cn mille dipendenze, mille distro e mille aggiornamenti di ogni stupido cazzuto pacchetto mi creo un unico pbi dove so che va TUTTO!! Lo testo e quindi sn sicuro che vada bene....ma se con il tempo si dovesse scoprire qualche bug rilasciano la versione 1.01 del pbi cn il pacchetto aggiornato e ho risolto il problema! inoltre nn è detto che tutti i bug siano dannosi e pericoli, magari per il mio programma è irrilevante!! Cn il pbi potrei distribuire il mio programma su ogni distro e potrebbero provarlo tutti senza problemi. Davvero nn riesco a trovarci lati negativi se nn quello del maggiro spazio occupato su hard disk ma viste le capienze attuali è un problema irrisorio!! Per me ci si ostina ad essere contrari a questo sistema (in aggiunto a quello tradizionale) più per una questione "ideologica", di partigianeria :sofico:

ekerazha

03-07-2007, 07:55

Mi sa che nn riusciamo a capirci! "Noi" sostenitori del pbi pensiamo a una convivenza fra i due modi di pacchettizzare i programmi! "Voi" invece escludete uno dei metodi!!

Esatto... perchè non c'è alcun motivo valido per il quale dovrebbe essercene un altro.

Su linux è impossibile far morire il sistema delle dipendenze se no morirebbero la maggior parte delle distribuzioni, sarebbero quasi tutte la stessa cosa! Chi realizza una distro continuera a usare il sistema di dipendenza e questo varrà per i DE, per xorg e i compilatori. IN PIù però ci sn i pbi! Se io, software house, voglio realizzare un programma per linux, tipo un media center invece che stare ad ammattire cn mille dipendenze, mille distro e mille aggiornamenti di ogni stupido cazzuto pacchetto mi creo un unico pbi dove so che va TUTTO!!

Ed è proprio questo il problema... si rischia di diffondere un approccio *errato* nella gestione del software. Il sistema "attuale" per me va benissimo... basta rilasciare un semplice tar.gz e poi ogni mantainer delle varie distribuzioni o qualche volenteroso lo impacchetta per le singole distribuzioni (magari se vogliamo essere pignoli l'azienda lo può anche impacchettare per le 3-4 maggiori distribuzioni: non venirmi a dire che per uno sviluppatore è invalidante creare 3-4 pacchetti). Se poi un giorno unificassero il sistema di gestione dei pacchetti (non il .pbi ;) ) sarebbe ancora meglio...

Lo testo e quindi sn sicuro che vada bene....ma se con il tempo si dovesse scoprire qualche bug rilasciano la versione 1.01 del pbi cn il pacchetto aggiornato e ho risolto il problema! inoltre nn è detto che tutti i bug siano dannosi e pericoli, magari per il mio programma è irrilevante!!

Magari si... magari no... ;)

Cn il pbi potrei distribuire il mio programma su ogni distro e potrebbero provarlo tutti senza problemi. Davvero nn riesco a trovarci lati negativi se nn quello del maggiro spazio occupato su hard disk ma viste le capienze attuali è un problema irrisorio!! Per me ci si ostina ad essere contrari a questo sistema (in aggiunto a quello tradizionale) più per una questione "ideologica", di partigianeria :sofico:
Irrisoria mica tanto... io ad esempio ho 520GB di hard disk (complessivo tra 4 dischi, 2 esterni) e sono quasi tutti saturi ed ho installati decine e decine di applicativi... se usassi i .pbi a quest'ora avrei dovuto acquistare il 5° disco perchè avrei librerie *inutilmente* replicate su tutto il disco.

Tra l'altro c'è anche un problema di occupazione in memoria centrale oltre che di disco fisso. Se ogni programma usa la sua versioncina differente delle librerie, significa che devo caricare in memoria ulteriori dati inutili.

Comunque ripeto... i .pbi non sono nemmeno questa grandissima novità, gli eseguibili compilati staticamente con le librerie ci sono da tempo.

zephyr83

03-07-2007, 18:44

Irrisoria mica tanto... io ad esempio ho 520GB di hard disk (complessivo tra 4 dischi, 2 esterni) e sono quasi tutti saturi ed ho installati decine e decine di applicativi... se usassi i .pbi a quest'ora avrei dovuto acquistare il 5° disco perchè avrei librerie *inutilmente* replicate su tutto il disco.

Tra l'altro c'è anche un problema di occupazione in memoria centrale oltre che di disco fisso. Se ogni programma usa la sua versioncina differente delle librerie, significa che devo caricare in memoria ulteriori dati inutili.

Comunque ripeto... i .pbi non sono nemmeno questa grandissima novità, gli eseguibili compilati staticamente con le librerie ci sono da tempo.
Allora su windows, o meglio ancora su osx come fanno?? Nn mi sembra che gli utenti mac abbiano problemi di spazio o di memoria centrale occupata!!! Lo so che i pbi nn sono una novità....ma la sarebbero per il mondo linux

ekerazha

03-07-2007, 19:56

Allora su windows, o meglio ancora su osx come fanno?? Nn mi sembra che gli utenti mac abbiano problemi di spazio o di memoria centrale occupata!!! Lo so che i pbi nn sono una novità....ma la sarebbero per il mondo linux

Se usano un metodo come quello ce l'hanno eccome... e se lo tengono.

P.S.
Non sarebbe una novità nemmeno per Linux... vedi eseguibili compilati staticamente con le librerie.

Gh0stRiDer

20-07-2007, 10:48

R4iDei

20-07-2007, 13:03

mi sembra una pessima idea, poi oggi ci sono degli strumenti come apt che sono davvero comodi, mi sembra di retrocedere invece che andare avanti, che serve avere la stessa libreria installata 20 venti inutilmente? i pbi se li può tenere bsd :nonsifa:

Oggi.... apt è uno strumento vecchio... e per carità funziona alla grande.

Cmq i possibili utilizzi sono gia stati scritti da me e da zeyphir, se voi non ne vedete la possibile utilità è perche probabilmente non vi siete mai trovati in situazioni simili.

Nessuno ha sostenuto che dovrebbe rimpiazziare gli attuali sistemi di packaging di un intero sistema, solo che sarebbeo utili in alcuni ambiti. Poi sarebbe una scelta in più, mica in meno.

Gh0stRiDer

20-07-2007, 13:17

sarebbe una scelta in più, mica in meno.
su questo sono daccordissimo però pensa che abituarsi a usare sooftware fuori dai repository può diventare un punto debole per quanto riguarda la sicurezza di GNU/linux, già oggi si rischia di rendere il sistema instabile con repository non ufficiali su parecchie distribuzioni, pensa se gli utenti prendessero l'abitudine di installare software come avviene su winzozz, con un doppio clic e già fatto

R4iDei

22-07-2007, 00:10

su questo sono daccordissimo però pensa che abituarsi a usare sooftware fuori dai repository può diventare un punto debole per quanto riguarda la sicurezza di GNU/linux, già oggi si rischia di rendere il sistema instabile con repository non ufficiali su parecchie distribuzioni, pensa se gli utenti prendessero l'abitudine di installare software come avviene su winzozz, con un doppio clic e già fatto

Ma l'eventuale software instabile rimarrebbe nel pbi, quindi al massimo implode quel programma. E se pure facesse crashare tutto il sistema si riavvia e basta... (ed è difficile inchiodare tutto cosi tanto). Sarebbe una soluzione rivolta ai desktop dove un crash si può accetare se ne capisci la causa!

Poi sta a noi usare bene gli strumenti, a chi si installa software di merda beh catzi loro :Prrr: . Ma la libertà di usare qualsiasi repository anche il piu zozzo della terra noi utenti dobbiamo averlo!

Gh0stRiDer

22-07-2007, 07:11

andreas.troschka

04-12-2007, 20:59

Ma l'eventuale software instabile rimarrebbe nel pbi, quindi al massimo implode quel programma. E se pure facesse crashare tutto il sistema si riavvia e basta... (ed è difficile inchiodare tutto cosi tanto). Sarebbe una soluzione rivolta ai desktop dove un crash si può accetare se ne capisci la causa!

Poi sta a noi usare bene gli strumenti, a chi si installa software di merda beh catzi loro :Prrr: . Ma la libertà di usare qualsiasi repository anche il piu zozzo della terra noi utenti dobbiamo averlo!

Ciao, e' un po' che vi leggo. Vediamo se riesco a dire la mia senza farvi scappare.:D

:muro:!!!
Qui si dimenticano un paio di cosette di non poco conto.;)

1. I sistemi operativi basati sul kernel Linux sono sistemi "multiutente", non monoutente come (di fatto) Winzozz; questo significa che in Linux ci sono da rispettare delle regole che definiscono, per es., i diritti di accesso ai file. La manutenzione del s.o. e l'installazione di applicativi le deve poter fare esclusivamente l'amministratore del sistema (root o chi per esso) per motivi di sicurezza. Infatti in Winzozz i problemi di virus, spyware, malware & c. ci sono e in Linux no, proprio perche' nel primo vige l'unica regola "chiunque fa quello che gli pare dove vuole" e nel secondo un utente fa solo quello che gli viene concesso di fare dall'amm. di sistema e praticamente solo nello spazio a lui riservato (user space). Molti applicativi hanno bisogno di appoggiarsi a servizi del sistema operativo che non possono essere interpellati dal livello utente e questo impedisce che un tale applicativo possa funzionare in "user-space", cioe' con i diritti di accesso dell'utente, che sono limitati.
Il pbi, per come e' fatto, puo' essere utilizzato per installare solo in user-space, e quindi inadatto ad un ambiente sicuro *nix come quelli Linux-based.

2. Linux non e' un sistema operativo, e' un kernel (alla faccia di chi, sbagliando e creando confusione, afferma il contrario, e sono in tanti).
Le distro sono sistemi operativi basati sul kernel Linux, tutti uno diverso dall'altro. Pretendere di utilizzare un applicativo preso dalla repository di un altro sistema operativo Linux (altra distro) e' letteralmente assurdo perche' dimostra solo una cosa, il non aver capito cosa e' e il perche' di una distro e la rispettiva repository.
Sarebbe come prendere un applicativo scritto e compilato per Vista e pretendere di installarlo e farlo funzionare su Win98SE.

Una volta ben compresi questi due elementari princìpi legati ai sistemi operativi Linux-kernel based :read: si capisce anche il perche' pbi non puo' essere compatibile con essi.

Ci sono, naturalmente anche altri motivi piu' tecnicamente profondi, che cozzano con la filosofia dietro al pbi.

A parte lo spreco di spazio sul disco che puo' anche non essere considerato significativo, c'e' il problema che le librerie (anche se identiche fra applicativi diversi) non possono essere messe in share per diversi motivi.

Il principale di essi e' di nuovo la sicurezza del sistema che non puo' essere compromessa condividendo parti di codice (es. le librerie) fra applicativi che "girano" in user-space diversi (utenti diversi) a meno che non sia il sistema operativo a offrire le medesime librerie (quindi sicure).

Dato che secondo pbi ogni installazione utilizza le proprie librerie, queste, in memoria, non possono che essere caricate separatamente con uno spreco di memoria RAM non indifferente.
Invece, se e' il s.o. a offrire le librerie (sicure) queste possono essere caricate in singola copia in memoria e condivise da tutti gli applicativi dei vari utenti che le richiedono, senza problemi.

Cio' comporta, alla fine della fiera, una gestione piu' semplice dei processi in esecuzione e quindi una velocita' di elaborazione *molto* piu' elevata!

Se volete trasformare un vero s.o. come *nix in un ciospo malfunzionante, lento, instabile ed insicuro come Winzozz, sostenete pure pbi.

Se invece vi interessa la sicurezza (niente virus&c, hackers, danni da bug nei programmi etc.), prestazioni, robustezza, costi limitati sia sw che hw, etc. rifiutate pbi su s.o. Linux-based e imparate ad utilizzare "Linux" capendo cosa state facendo. :cincin:

I problemi che riscontrate ora dipendono dal fatto che non conoscete il s.o. e come va usato.
Su questo fronte, la "userfriendlyness", effettivamente c'e' ancora da fare per arrivare ad una interfaccia (UI) rigorosa e a prova di utOnto, ma ci stiamo lavorando. :cool:

Le soluzioni come PC-BSD non sono nè carne, nè pesce e sono destinate a morire prima o poi, che ai loro sviluppatori piaccia o meno. :mc: Peccato per la fatica sprecata che poteva essere utilizzata in modo piu' razionale.:(

Naturalmente ho semplificato per rendere i concetti piu' immediati, ragazzi.
Una spiega, pero' ci voleva, senno sta' storia continua ad andare avanti all'infinito.

zephyr83

04-12-2007, 23:54

Ciao, e' un po' che vi leggo. Vediamo se riesco a dire la mia senza farvi scappare.:D

:muro:!!!
Qui si dimenticano un paio di cosette di non poco conto.;)

1. I sistemi operativi basati sul kernel Linux sono sistemi "multiutente", non monoutente come (di fatto) Winzozz; questo significa che in Linux ci sono da rispettare delle regole che definiscono, per es., i diritti di accesso ai file. La manutenzione del s.o. e l'installazione di applicativi le deve poter fare esclusivamente l'amministratore del sistema (root o chi per esso) per motivi di sicurezza. Infatti in Winzozz i problemi di virus, spyware, malware & c. ci sono e in Linux no, proprio perche' nel primo vige l'unica regola "chiunque fa quello che gli pare dove vuole" e nel secondo un utente fa solo quello che gli viene concesso di fare dall'amm. di sistema e praticamente solo nello spazio a lui riservato (user space). Molti applicativi hanno bisogno di appoggiarsi a servizi del sistema operativo che non possono essere interpellati dal livello utente e questo impedisce che un tale applicativo possa funzionare in "user-space", cioe' con i diritti di accesso dell'utente, che sono limitati.
Il pbi, per come e' fatto, puo' essere utilizzato per installare solo in user-space, e quindi inadatto ad un ambiente sicuro *nix come quelli Linux-based.

2. Linux non e' un sistema operativo, e' un kernel (alla faccia di chi, sbagliando e creando confusione, afferma il contrario, e sono in tanti).
Le distro sono sistemi operativi basati sul kernel Linux, tutti uno diverso dall'altro. Pretendere di utilizzare un applicativo preso dalla repository di un altro sistema operativo Linux (altra distro) e' letteralmente assurdo perche' dimostra solo una cosa, il non aver capito cosa e' e il perche' di una distro e la rispettiva repository.
Sarebbe come prendere un applicativo scritto e compilato per Vista e pretendere di installarlo e farlo funzionare su Win98SE.

Una volta ben compresi questi due elementari princìpi legati ai sistemi operativi Linux-kernel based :read: si capisce anche il perche' pbi non puo' essere compatibile con essi.

Ci sono, naturalmente anche altri motivi piu' tecnicamente profondi, che cozzano con la filosofia dietro al pbi.

A parte lo spreco di spazio sul disco che puo' anche non essere considerato significativo, c'e' il problema che le librerie (anche se identiche fra applicativi diversi) non possono essere messe in share per diversi motivi.

Il principale di essi e' di nuovo la sicurezza del sistema che non puo' essere compromessa condividendo parti di codice (es. le librerie) fra applicativi che "girano" in user-space diversi (utenti diversi) a meno che non sia il sistema operativo a offrire le medesime librerie (quindi sicure).

Dato che secondo pbi ogni installazione utilizza le proprie librerie, queste, in memoria, non possono che essere caricate separatamente con uno spreco di memoria RAM non indifferente.
Invece, se e' il s.o. a offrire le librerie (sicure) queste possono essere caricate in singola copia in memoria e condivise da tutti gli applicativi dei vari utenti che le richiedono, senza problemi.

Cio' comporta, alla fine della fiera, una gestione piu' semplice dei processi in esecuzione e quindi una velocita' di elaborazione *molto* piu' elevata!

Se volete trasformare un vero s.o. come *nix in un ciospo malfunzionante, lento, instabile ed insicuro come Winzozz, sostenete pure pbi.

Se invece vi interessa la sicurezza (niente virus&c, hackers, danni da bug nei programmi etc.), prestazioni, robustezza, costi limitati sia sw che hw, etc. rifiutate pbi su s.o. Linux-based e imparate ad utilizzare "Linux" capendo cosa state facendo. :cincin:

I problemi che riscontrate ora dipendono dal fatto che non conoscete il s.o. e come va usato.
Su questo fronte, la "userfriendlyness", effettivamente c'e' ancora da fare per arrivare ad una interfaccia (UI) rigorosa e a prova di utOnto, ma ci stiamo lavorando. :cool:

Le soluzioni come PC-BSD non sono nè carne, nè pesce e sono destinate a morire prima o poi, che ai loro sviluppatori piaccia o meno. :mc: Peccato per la fatica sprecata che poteva essere utilizzata in modo piu' razionale.:(

Naturalmente ho semplificato per rendere i concetti piu' immediati, ragazzi.
Una spiega, pero' ci voleva, senno sta' storia continua ad andare avanti all'infinito.
quindi vista è sicuro come linux perché è finalmente un vero sistema multi utente? :sofico:
Dei PBI, l'unico svantaggio mi sembra quello della memoria, tutto il resto nn conta! Che importa a me se il sistema è multiutente? Ogni utente instalalre quell'applicazione, l'unico inconveniente è lo spazio sprecato ma cn gli hard disk di oggi nn mi sembra un problema! Il vantaggio del PBI è che può girare senza problemi anche su distribuzioni linux differenti! A me questo sembra un vantaggio e nn uno svantaggio. Nessuno ha detto di sostituire il sistema di dipendenze cn i pbi ma solo di aggiungere quest'ultimo. Il sistema viene normalmente gestito e amministrato cn il sistema delle dipendenze dei pacchetti ma se voglio provare uno stupidissimo programma come la dock station stile osx lo faccio senza problemi! Avvio il programma, provo e se nn mi piace lo cestino senza inzozzare l'hard disk! Nn capisco perché sia così difficile da accettare!

Artemisyu

05-12-2007, 08:50

quindi vista è sicuro come linux perché è finalmente un vero sistema multi utente? :sofico:
Dei PBI, l'unico svantaggio mi sembra quello della memoria, tutto il resto nn conta! Che importa a me se il sistema è multiutente? Ogni utente instalalre quell'applicazione, l'unico inconveniente è lo spazio sprecato ma cn gli hard disk di oggi nn mi sembra un problema! Il vantaggio del PBI è che può girare senza problemi anche su distribuzioni linux differenti! A me questo sembra un vantaggio e nn uno svantaggio. Nessuno ha detto di sostituire il sistema di dipendenze cn i pbi ma solo di aggiungere quest'ultimo. Il sistema viene normalmente gestito e amministrato cn il sistema delle dipendenze dei pacchetti ma se voglio provare uno stupidissimo programma come la dock station stile osx lo faccio senza problemi! Avvio il programma, provo e se nn mi piace lo cestino senza inzozzare l'hard disk! Nn capisco perché sia così difficile da accettare!

Non vedo che utilità abbia il valutare l'uso di un infrastruttura per la gestione del software sulla base dell'installazione una tantum di qualche software esoterico e basta.
Se bisogna valutare i pbi è necessario farlo in un sistema operativo dove tutta la gestione dell'installazione/disinstallazione/reperibilità del software è demandato a tale sistema, altrimenti non ha proprio senso parlarne.

In questo senso quello che ha detto il collega più sopra è assolutamente sensato.
Se un software distribuito in pbi è compilato in modo da reperire nella propria cartella di installazione tutto il necessario per funzionare significa che tutte le sue dipendenze devono trovarsi li, e che andranno caricate tutte in memoria all'atto dell'avvio del programma.
Significa che se ho 3 software aperti che fanno uso delle GTK avrò 3 copie della libreria GTK, magari anche in versione diversa, caricate in ram.
Non posso condividere il codice delle librerie tra più applicazioni, così come non posso condividerlo tra più applicazioni di più utenti (cosa abbastanza assurda visto che un medio sistema basato su linux ha molti utenti di sistema che fanno uso di altrettanto software e che non interagiscono direttamente con l'utente in carne e ossa).
Un problema del genere è abbastanza scottante da aver meritato 20 anni di ricerca nel campo dei sistemi operativi sull'uso della memoria condivisa e sulle comunicazioni tra processi. Concetti di cui i pbi, evidentemente, preferiscono farsi allegramente beffe.

Certo, se uno poi sostiene di non voler sostituire il sistema di dipendenze con i pbi significa che afferma che può esistere un sistema in cui i pbi portano *non si sa cosa* ma dove la maggiorparte delle librerie condivise (quelle grafiche, per esempio) sono invece fornite dal sistema operativo che gestisce a parte il sistema di installazione e disinstallazione di queste, in modo da utilizzare una struttura condivisa e scongiurare così la morte e distruzione.
A quel punto il pbi stesso, comportandosi così, ammette egli stesso il suo grosso limite, ovvero che è impossibile portare tutte le dipendenze di un software nello stesso pacchetto.
A parte la demenzialità nel gestire il software, in un sistema operativo, tramite 2 canali indipendenti, questo sistema fa venire anche meno la presunta portabilità di tali pbi, in quanto se un pbi cerca una libreria condivisa, basta che io progetto il sistema per mettere le librerie in un luogo diverso e siamo belli che daccapo, diventa come installare un rpm su debian.

il progetto pbi offre una soluzione raffazzonata per la non-gestione delle dipendenze, in cui non offre una gestione "trasparente" all'utente, ma semplicemente non offre alcuna gestione.
Non ha alcun futuro ed è completamente inadatta ad una gestione infrastrutturale di un sistema operativo.
Come detto, è un sistema che può andare bene al limite per l'installazione di qualche software esoterico una tantum, ai fini di prova, ma veramente non è buono per null'altro.
E, sinceramente, non è proprio una priorità trovare soluzioni rivoluzionarie utilizzabili una volta ogni tanto.

PS: occhio a dire "Che importa a me se il sistema è multiutente? Ogni utente instalalre quell'applicazione". Si rideva dietro a Windows 9x per questa cosa, che poi è uno dei motivi che ne ha decretato il completo abbandono. E lo svantaggio non è che ogni utente debba installare lo stesso programma, e quindi lo spreco di spazio, quello è il meno.

khelidan1980

05-12-2007, 09:35

Comunque secondo me ci si scanna su un non problema,se una software house vuole rilasciare il proprio sw in maniera simile a os x,si compila programma e librerie,un bell'archivio e via,l'utente lo scompatta nella proprio home e lo avvia....questi pbi proprio non li capisco

Fil9998

05-12-2007, 10:40

io si, li trovo oltremodo comodi per software "in prova".

khelidan1980

05-12-2007, 14:51

io si, li trovo oltremodo comodi per software "in prova".

pardonami,ma dove starebbe la differenza con un semplice archivio piu librerie?

Dcromato

05-12-2007, 15:12

pardonami,ma dove starebbe la differenza con un semplice archivio piu librerie?
alcuni provano fatica a scrivere quattro parole in shell o a fare una spunta su synaptic*

*citato come esempio

khelidan1980

05-12-2007, 15:32

alcuni provano fatica a scrivere quattro parole in shell o a fare una spunta su synaptic*

*citato come esempio

ma l'idea di provare programmi in questo modo,in una sorta di sandbox ci sta anche,a prescindere da tutti i contro elencati in precedenza,ma se qualcuno vuole distribuire sw così,è gia possibile farlo,e skype gia lo fa,archivio con programma e librerie compilati staticamente,scompatti e lanci e stop!
Vorrei proprio capire in cosa si differenziano questi .pbi dal metodo sopracitato!

Dcromato

05-12-2007, 15:47

Vorrei proprio capire in cosa si differenziano questi .pbi dal metodo sopracitato!

Che nel giro di 10 giorni passi da 2 a 10 giga di disco occupato:ciapet:

zephyr83

05-12-2007, 18:02

alcuni provano fatica a scrivere quattro parole in shell o a fare una spunta su synaptic*

*citato come esempio
io ci passo anche un'intera nottata davanti a linux :D è proprio per evitare di perdere ore e ore per installare una stupida dock station che mi piacerebbe avere ANCHE i pbi (o simili). Nn capisco perché per alcuni sia così tragica! Nessuno vuole eliminare il sistema di dipendenze....credo sarebbe impossibile farlo, nn si potrebbe mai mantenere una qualsiasi distro cn un sistema diverso!

andreas.troschka

05-12-2007, 18:31

quindi vista è sicuro come linux perché è finalmente un vero sistema multi utente? :sofico:

Nient'affato. In Vista sono stati aggiunti (alla buon'ora!) alcuni elementi scopiazzando *nix. Questo pero' non basta.
Cio' che e' stato fatto non e' sufficiente per garantire la separazione efficiente dei processi interni del sistema operativo fra loro e dagli altri. Tutt'al piu' puo' servire a dividere gli ambienti di esecuzione utente (user-space) ma su questo occorrerebbe fare uno studio approfondito di sicurezza prima di dire che e' veramente cosi' e che lo e' in modo efficiente.
Occorre anche tenere in considerazione il fatto che finche' l'unico utente ha la pessima abitudine di operare come amministratore, tutta la sicurezza che puo' esserci in un tale sistema e' come se non esistesse. In altre parole qualunque programma lanciato dall'utente puo' accedere a qualunque parte del sistema e fare il danno che vuole. :cry:

Dei PBI, l'unico svantaggio mi sembra quello della memoria, tutto il resto nn conta! Che importa a me se il sistema è multiutente?

In Unix, e quindi anche in s.o. Linux-based, anche root, e i servizi, sono "utenti", i quali sono assegnati a gruppi e hanno diritti di accesso e di esecuzione all'interno del sistema similmente a cio' che succede per gli "utenti fisici".

Cio' permette di isolare ogni programma (che sia applicativo o di sistema) dal resto del sistema assegnandogli con esattezza i contesti e gli spazi (memoria, file, directory, interazione con altri processi) a cui ha diritto di accedere (e con quali diritti accedervi; elenco, lettura, scrittura, esecuzione etc.).
E' questa la base su cui si appoggia la sicurezza di questi sistemi operativi.
Ad es., un virus "tirato dentro" con l'e-mail, non potra' mai andare a scrivere, che so io, nel settore di boot (MBR) sul disco principale o infettare i dati nell'area disco riservata ad un altro utente fisico, perche' avra' al piu' diritto di accesso ai file dell'utente che ha lanciato il programma di posta, ma mai! gli sara' permesso di avere i diritti di accesso come quelli dell'amministratore di sistema o del comando fdisk, che invece possono accedere all'MBR (AKA, un utente normale non puo' usare fdisk!).

Ogni utente instalalre quell'applicazione, l'unico inconveniente è lo spazio sprecato ma cn gli hard disk di oggi nn mi sembra un problema! Il vantaggio del PBI è che può girare senza problemi anche su distribuzioni linux differenti! A me questo sembra un vantaggio e nn uno svantaggio.

Infatti cio' non e' assolutamente vero! Un applicativo in user-space (cioe' lanciato da un utente) non potra' usufruire che dei soli servizi messigli a disposizione dall'amministratore di sistema, che spesso non sono sufficienti.
In altre parole, utilizzando il sistema pbi, molti applicativi non possono funzionare in quanto non hanno i necessari diritti per usufruire dei servizi ed accedere alle parti del disco rigido etc. che gli servono.

Essendo poi, il filesystem (nonche' l'organizzazione dei servizi attivi ai vari livelli o "runlevel") configurati in modo diverso a seconda della distro, pbi, dovrebbe tenere conto per ogni distribuzione di queste differenze e chiedere all'utente la modifica dei diritti di accesso per quello specifico applicativo da installare. L'utente dovrebbe accedere come amministratore di sistema e pasticciare con i permessi, cosa che pochissimi sanno fare bene. :read:

Nessuno ha detto di sostituire il sistema di dipendenze cn i pbi ma solo di aggiungere quest'ultimo. Il sistema viene normalmente gestito e amministrato cn il sistema delle dipendenze dei pacchetti ma se voglio provare uno stupidissimo programma come la dock station stile osx lo faccio senza problemi! Avvio il programma, provo e se nn mi piace lo cestino senza inzozzare l'hard disk! Nn capisco perché sia così difficile da accettare!

E' difficile da accettare semplicemente perche' non e' realizzabile, oltre ad essere inutile.

Si, inutile, dato che utilizzando il s.o. nel modo corretto, cioe' non pretendendo di usarlo come se fosse Winzozz (che e' un'altro! sistema operativo con una filosofia e un target completamente diversi), si possono ottenere esattamente le cose previste per l'utente.

I problemi tipici, in tal senso, riscontrati da chi si avvicina ad un sistema Linux-based (sopratutto proveniendo dall'ambiente Windows) sono determinati principalmente da due elementi:

1. utenti - mancanza di conoscenza del sistema operativo in questione e di come esso va utilizzato;
2. idem per molti programmatori, che venendo da ambienti di programmazione M$ non sanno quali sono i princìpi della programmazione in ambiente Unix, per molti versi simili a quelli dei s.o. Linux-based, oltre che essere completamente a digiuno in ambito pacchettizzazione (diversa per ogni distro per via delle differenze dei modelli di filesystem). :confused:

Ancora piu' disastroso e' il fatto che sia gli uni che gli altri cercano di applicare (per lo piu' involontariamente) abitudini prese operando con altri sistemi operativi (es. Winzozz), cosa che, ovviamente, sfocia in stressanti ore di combattimenti con cio' che sembra non funzionare (ma semplicemente non viene utilizzato nel modo corretto).:muro:

zephyr83

05-12-2007, 19:30

Nient'affato. In Vista sono stati aggiunti (alla buon'ora!) alcuni elementi scopiazzando *nix. Questo pero' non basta.
Cio' che e' stato fatto non e' sufficiente per garantire la separazione efficiente dei processi interni del sistema operativo fra loro e dagli altri. Tutt'al piu' puo' servire a dividere gli ambienti di esecuzione utente (user-space) ma su questo occorrerebbe fare uno studio approfondito di sicurezza prima di dire che e' veramente cosi' e che lo e' in modo efficiente.
Occorre anche tenere in considerazione il fatto che finche' l'unico utente ha la pessima abitudine di operare come amministratore, tutta la sicurezza che puo' esserci in un tale sistema e' come se non esistesse. In altre parole qualunque programma lanciato dall'utente puo' accedere a qualunque parte del sistema e fare il danno che vuole. :cry:

In Unix, e quindi anche in s.o. Linux-based, anche root, e i servizi, sono "utenti", i quali sono assegnati a gruppi e hanno diritti di accesso e di esecuzione all'interno del sistema similmente a cio' che succede per gli "utenti fisici".

Cio' permette di isolare ogni programma (che sia applicativo o di sistema) dal resto del sistema assegnandogli con esattezza i contesti e gli spazi (memoria, file, directory, interazione con altri processi) a cui ha diritto di accedere (e con quali diritti accedervi; elenco, lettura, scrittura, esecuzione etc.).
E' questa la base su cui si appoggia la sicurezza di questi sistemi operativi.
Ad es., un virus "tirato dentro" con l'e-mail, non potra' mai andare a scrivere, che so io, nel settore di boot (MBR) sul disco principale o infettare i dati nell'area disco riservata ad un altro utente fisico, perche' avra' al piu' diritto di accesso ai file dell'utente che ha lanciato il programma di posta, ma mai! gli sara' permesso di avere i diritti di accesso come quelli dell'amministratore di sistema o del comando fdisk, che invece possono accedere all'MBR (AKA, un utente normale non puo' usare fdisk!).

Infatti cio' non e' assolutamente vero! Un applicativo in user-space (cioe' lanciato da un utente) non potra' usufruire che dei soli servizi messigli a disposizione dall'amministratore di sistema, che spesso non sono sufficienti.
In altre parole, utilizzando il sistema pbi, molti applicativi non possono funzionare in quanto non hanno i necessari diritti per usufruire dei servizi ed accedere alle parti del disco rigido etc. che gli servono.

Essendo poi, il filesystem (nonche' l'organizzazione dei servizi attivi ai vari livelli o "runlevel") configurati in modo diverso a seconda della distro, pbi, dovrebbe tenere conto per ogni distribuzione di queste differenze e chiedere all'utente la modifica dei diritti di accesso per quello specifico applicativo da installare. L'utente dovrebbe accedere come amministratore di sistema e pasticciare con i permessi, cosa che pochissimi sanno fare bene. :read:

E' difficile da accettare semplicemente perche' non e' realizzabile, oltre ad essere inutile.

Si, inutile, dato che utilizzando il s.o. nel modo corretto, cioe' non pretendendo di usarlo come se fosse Winzozz (che e' un'altro! sistema operativo con una filosofia e un target completamente diversi), si possono ottenere esattamente le cose previste per l'utente.

I problemi tipici, in tal senso, riscontrati da chi si avvicina ad un sistema Linux-based (sopratutto proveniendo dall'ambiente Windows) sono determinati principalmente da due elementi:

1. utenti - mancanza di conoscenza del sistema operativo in questione e di come esso va utilizzato;
2. idem per molti programmatori, che venendo da ambienti di programmazione M$ non sanno quali sono i princìpi della programmazione in ambiente Unix, per molti versi simili a quelli dei s.o. Linux-based, oltre che essere completamente a digiuno in ambito pacchettizzazione (diversa per ogni distro per via delle differenze dei modelli di filesystem). :confused:

Ancora piu' disastroso e' il fatto che sia gli uni che gli altri cercano di applicare (per lo piu' involontariamente) abitudini prese operando con altri sistemi operativi (es. Winzozz), cosa che, ovviamente, sfocia in stressanti ore di combattimenti con cio' che sembra non funzionare (ma semplicemente non viene utilizzato nel modo corretto).:muro:
Ma chi è che guarda a windows? si mena sempre cn sta storia di windows ma che cavolo c'entra? Anche windows ha "problemi stile" linux per via delle dll. Al massimo si potrebbe citare osx cmq il caso mi sembra ancora diverso. A me i pbi nn sembrano affatto un problema, se devo eseguire uno stupidissimo programma che la mia distro nn ha fra i repository, che richederebbe nn so quante stupide dipendense e soprattutto voglio che giri senza problemi su più distribuzioni allora il pbi è ottimo!

andreas.troschka

05-12-2007, 23:48

Ma chi è che guarda a windows?si mena sempre cn sta storia di windows ma che cavolo c'entra?

Tu hai fatto una domanda su Vista (mi pare sia una flavour di Windows o sbaglio?) e io ti ho risposto mantenendo l'esempio anche per i ragionamenti successivi.
Alcuni dei discorsi che ho fatto valgono anche per mille altri s.o., certo! ;)

Anche windows ha "problemi stile" linux per via delle dll.

Adesso saro' volutamente polemico: a quali problemi di Linux ti riferisci? :eek:

I problemi li ha l'utente regolare che vuole utilizzare sulla distro che ha installato, applicativi:

1. provenienti dalle repository di un'altra distro;
2. in formato sorgente se non sa compilarli correttamente;
3. che richiedono d'interagire con servizi del s.o. o con parti del filesystem per i quali l'utente (e quindi i processi che girano in user-space) non ha diritti d'accesso.

N.B. Il punto 3. riguarda proprio i pbi.
Faccio un esempio:

Tu normale utente Linux installi un applicativo da un pbi secondo il princìpio "butto tutto in /home/zephyr83/Programmi/applicativobello".

In quella directory ci sara', dunque, l'insieme completo dei file dell'applicativo + cio' che normalmente sta dietro alle dipendenze (librerie, comandi vari, script, interpreti etc.).

Lanci e l'applicativo non va... :confused:

Eh si, succedera' quasi sempre!

La causa e' che quasi tutti gli applicativi fanno uso anche di servizi del s.o. che non possono essere raggiunti con i diritti di accesso di un normale utente (e che l'applicativo da te lanciato eredita automaticamente) e/o fanno uso di servizi che non sono relativi a singoli file eseguibili che si possono copiare nel pacchetto pbi.
E anche se si potessero copiare tutti nel pacchetto pbi, quando venissero eseguiti richiederebbero di accedere ad altre parti del s.o. che con i diritti di accesso dell'utente (e quindi dell'applicativo che hai lanciato) sono irraggiungibili.
In altre parole: crash!

Al massimo si potrebbe citare osx cmq il caso mi sembra ancora diverso. A me i pbi nn sembrano affatto un problema, se devo eseguire uno stupidissimo programma che la mia distro nn ha fra i repository, che richederebbe nn so quante stupide dipendense e soprattutto voglio che giri senza problemi su più distribuzioni allora il pbi è ottimo!

Ripeto, la maggior parte degli applicativi che installi con pbi non potra' funzionare perche' non basta avere tutte le librerie etc. insieme al programma, ma bisogna che il medesimo abbia anche il diritto di accedere a tutte le parti che gli necessitano del sistema operativo, cosa che non avra' mai finche' "gira" completamente nello spazio a te (e di conseguenza ad esso) riservato come utente normale.
Ed e' bene che sia cosi' perche' in caso contrario qualunque virus lanciato inconsapevolmente con un applicativo "ospite" da te installato con pbi, avrebbe la possibilita' di distruggere qualunque parte del s.o. e dei dati visto che avrebbe il diritto di accedervi! :ciapet:

Meditate gente, meditate. ;-)

zephyr83

06-12-2007, 00:29

Tu hai fatto una domanda su Vista (mi pare sia una flavour di Windows o sbaglio?) e io ti ho risposto mantenendo l'esempio anche per i ragionamenti successivi.
Alcuni dei discorsi che ho fatto valgono anche per mille altri s.o., certo! ;)

Adesso saro' volutamente polemico: a quali problemi di Linux ti riferisci? :eek:

la mia prima uscita su vista era chiaramente ironica! Ovviamente intendevo intendere che nn basta che il sistema sia multiutente epr renderlo sicuro.

I "problemi stile" windows l'ho volutamente messo tra virgolette! Come in windows ci sn problemi cn le dll di versioni diverse (magari sovrascritte da vari programmi anche in linux ci sn problemi cn pacchetti che usano versioni differenti di alcune librerie...e nn è neanche una cosa così rara (anche se ovviamente nn c'è il problema di librerie sovrascritte).

I pbi ancora nn li ho usati ma l'idea nn mi sembra così malvagia e sicuramente un modo per risolvere la questione dei diritti ci sarà visto che i sistemi BSD li usano senza troppi problemi e se nn sbaglio anche sabyon dovrebbe supportarli. Poi che nn sia propriamente il pbi ma qualcos'altro poco mi cambia ma come idea nn mi sembra affatto male.

fmele

09-12-2007, 12:56

Scusate ragazzi, mi intrometto perché ho scelto ed uso PCBSD da un po'.

I "problemi" dei pbi sono sicuramente quelli citati e che riguardano essenzialmente l'uso della memoria, ma quello che cercavo era un sistema che limita le dipendenze al minimo.

Scenario:
_ Installo il software A che porta dietro n librerie
_ Installo il software B che ha in parte le stesse librerie di A .. o quasi! Mi tocca aggiornare qua e là il sistema
_ torno ad usare A, ma ops, non va più perché B gli ha cambiato le librerie sotto il naso

I pbi tentano di limitare questi effetti collaterali dovuti alle dipendenze portando con questo un inevitabile peso di struttura.

Per quanto riguarda i problemi di sicurezza credo di poter dire che non ve ne siano. Gli applicativi girano comunque in user-space (questo mi ha comportato seri problemi per esempio nell'aggiornamento di eclipse non potendo usare direttamente il suo sistema interno).

Un aspetto che ritengo ottimo nell'utilizzo di pbi sta nel poter utilizzare (e valutare) anche versioni differenti dello stesso software. Se poi decido che una va bene e l'altra no, sono sicuro di poter eliminare l'una o l'alta senza problemi ... e scusate se è poco!!!

Una nota in chiusura: uso PCBSD su un PIII 950. Con 256MB di ram andava un un po' lento, ma mai crash e comunque andava. Adesso con 512MB non mi lamento affatto.

saluti

mad_hhatter

09-12-2007, 14:23

1. I sistemi operativi basati sul kernel Linux sono sistemi "multiutente", non monoutente come (di fatto) Winzozz; questo significa che in Linux ci sono da rispettare delle regole che definiscono, per es., i diritti di accesso ai file. La manutenzione del s.o. e l'installazione di applicativi le deve poter fare esclusivamente l'amministratore del sistema (root o chi per esso) per motivi di sicurezza. Infatti in Winzozz i problemi di virus, spyware, malware & c. ci sono e in Linux no, proprio perche' nel primo vige l'unica regola "chiunque fa quello che gli pare dove vuole" e nel secondo un utente fa solo quello che gli viene concesso di fare dall'amm. di sistema e praticamente solo nello spazio a lui riservato (user space). Molti applicativi hanno bisogno di appoggiarsi a servizi del sistema operativo che non possono essere interpellati dal livello utente e questo impedisce che un tale applicativo possa funzionare in "user-space", cioe' con i diritti di accesso dell'utente, che sono limitati.
Il pbi, per come e' fatto, puo' essere utilizzato per installare solo in user-space, e quindi inadatto ad un ambiente sicuro *nix come quelli Linux-based.

precisiamo un paio di cose...
1. windows E' multiutente e HA una gestione dei permessi... che poi l'uso comune sia quello di loggarsi come Administrator e' un discorso diverso: in Linux nessuno mi impedisce di usare il sistema come root... solo che gli utenti sanno che non e' buona cosa farlo e, soprattutto, gli applicativi sono scritti con quel pizzico di testa sufficiente a farli girare senza richiedere i privilegi di root
2. user-space e kernel/space non c'entrano nulla coi privilegi dei vari utenti: anche un processo di un utente che non e' root esegue istruzioni in kernel space, solo che per farlo deve delegare il compito al kernel, ma questo vale per un processo che gira come root

darkbasic

09-12-2007, 14:49

precisiamo un paio di cose...
1. windows E' multiutente e HA una gestione dei permessi...
Sì, e poi c'era la marmotta che confezionava la cioccolata... :rolleyes:
Finché di default winzozz continuerà a creare utenti con privilegi di administrator non ci sarà niente da fare, infatti molti software sono all'atto pratico inutilizzabili senza privilegi di amministrazione.

zephyr83

09-12-2007, 23:50

precisiamo un paio di cose...
1. windows E' multiutente e HA una gestione dei permessi... che poi l'uso comune sia quello di loggarsi come Administrator e' un discorso diverso: in Linux nessuno mi impedisce di usare il sistema come root... solo che gli utenti sanno che non e' buona cosa farlo e, soprattutto, gli applicativi sono scritti con quel pizzico di testa sufficiente a farli girare senza richiedere i privilegi di root
Vista è un verso sistema multiutente....xp è una cazzata sotto questo aspetto! L'utente normale era troppo limitato nn poteva fare nulla di nulla! Così diventava assurdo e impossibile usare il sistema non come amministratore

mad_hhatter

10-12-2007, 08:52

Vista è un verso sistema multiutente....xp è una cazzata sotto questo aspetto! L'utente normale era troppo limitato nn poteva fare nulla di nulla! Così diventava assurdo e impossibile usare il sistema non come amministratore

uso windows xp da 2 anni con privilegi di User... mai avuto problemi... che poi molti software applicativi siano scritti male non credo sia imputabile al s.o.

certo, windows xp di default ha una gestione utenti a dir poco criticabile, ma mi pare che quando si tratta di linux si critica l'utente che non legge la documentazione e non si informa, poi quando si passa a windows si pretende che l'utente sappia tutto da subito... mah.

mad_hhatter

10-12-2007, 08:55

Sì, e poi c'era la marmotta che confezionava la cioccolata... :rolleyes:
Finché di default winzozz continuerà a creare utenti con privilegi di administrator non ci sarà niente da fare, infatti molti software sono all'atto pratico inutilizzabili senza privilegi di amministrazione.

intanto abbi la cortesia di mostarrmi il dovuto rispetto.

poi, i sw applicativi NON fanno parte del s.o., quindi sono 2 cose diverse: o parliamo del s.o. o dei sw applcativi

che poi la gestione di default degli utenti di win xp sia una schifezza è ampiamente dimostrato, ma da qui a dire che il sistema operativo NON è multiutente ce ne passa

khelidan1980

10-12-2007, 09:25

uso windows xp da 2 anni con privilegi di User... mai avuto problemi... che poi molti software applicativi siano scritti male non credo sia imputabile al s.o.

Il fatto che questo sw siano scritti male è direttamente imputabile alla politica ms,che ha sempre presentato xp e precedenti con account administrator di default,scusa se la casa madre installa il suo sw con gia un account root abilitato e di default,perchè le software house dovrebbero andare contro corrente e scrivere sw che funzioni bene in ambienti multiutenti?tanto verranno sempre usati come root,perchè quella è la via scelta dalla casa produttrice del sw(ovviamente parlo fino a xp)

darkbasic

10-12-2007, 10:22

intanto abbi la cortesia di mostarrmi il dovuto rispetto.
Ti chiedo scusa, non era mia intenzione mancarti di rispetto e il tono indignato era rivolto ad alcune scelte molto discutibili ad opera della M$, come dare di default privilegi di amministrazione a cani e porci.

che poi molti software applicativi siano scritti male non credo sia imputabile al s.o.
E' colpa del SO eccome invece. Fintanto che la la M$ continuerà a dare privilegi di amministrazione di default, se i produttori scriveranno programmi senza pensare alla multiutenza sarà solo ed esclusivamente colpa sua.

poi quando si passa a windows si pretende che l'utente sappia tutto da subito... mah.
Una qualsiasi distro linux non ti da in mano un account utente con privilegi di root. Prima ancora che l'utente, il colpevole la M$ stessa.

darkbasic

10-12-2007, 10:23

che ha sempre presentato xp e precedenti con account administrator di default
E vista dove lo metti? La M$ è ben lungi dal perdere questo schifoso vizietto...

khelidan1980

10-12-2007, 10:41

E vista dove lo metti? La M$ è ben lungi dal perdere questo schifoso vizietto...

Siceramente non ho ancora usato nemmeno una volta Vista,quindi ti credo sulla parola e spero di non avere necessità di verificare! :)

mad_hhatter

10-12-2007, 11:12

Il fatto che questo sw siano scritti male è direttamente imputabile alla politica ms,che ha sempre presentato xp e precedenti con account administrator di default,scusa se la casa madre installa il suo sw con gia un account root abilitato e di default,perchè le software house dovrebbero andare contro corrente e scrivere sw che funzioni bene in ambienti multiutenti?tanto verranno sempre usati come root,perchè quella è la via scelta dalla casa produttrice del sw(ovviamente parlo fino a xp)

E' colpa del SO eccome invece. Fintanto che la la M$ continuerà a dare privilegi di amministrazione di default, se i produttori scriveranno programmi senza pensare alla multiutenza sarà solo ed esclusivamente colpa sua.

totalmente in disaccordo: se il sistema di default fa acqua non significa che chi scrive applicativi debba seguire pedissequamente questa linea, infatti ci sono un mucchio di software che funzionano perfettamente con account limitato. vediamo di dare le colpe a chi se le merita, non solo a chi vogliamo

khelidan1980

10-12-2007, 11:31

totalmente in disaccordo: se il sistema di default fa acqua non significa che chi scrive applicativi debba seguire pedissequamente questa linea, infatti ci sono un mucchio di software che funzionano perfettamente con account limitato. vediamo di dare le colpe a chi se le merita, non solo a chi vogliamo

Io non giustifico i produttori di software,dico solo che un determinato comportamento è incentivato dalla scelta di assumere come condizione di default l'uso dell'account administrator!

darkbasic

10-12-2007, 11:33

E' chiaro che la colpa sia anche dei produttori di software, ma fintanto che le politiche di casa M$ saranno queste non me la sento di biasimarli.

vediamo di dare le colpe a chi se le merita, non solo a chi vogliamo
Figurati... la sorte di windows mi è del tutto indifferente, eccetto quando le imposizioni della M$ vanno a minare le mie libertà.

mad_hhatter

10-12-2007, 16:19

un determinato comportamento è incentivato dalla scelta di assumere come condizione di default l'uso dell'account administrator!

E' chiaro che la colpa sia anche dei produttori di software, ma fintanto che le politiche di casa M$ saranno queste non me la sento di biasimarli.

opinabile.
in ogni caso resta il fatto che windows E' multiutente e HA una gestione dei permessi. Che poi la politica di gestione degli utenti sia vergognosa è un discorso diverso.

zephyr83

10-12-2007, 18:08

uso windows xp da 2 anni con privilegi di User... mai avuto problemi... che poi molti software applicativi siano scritti male non credo sia imputabile al s.o.

certo, windows xp di default ha una gestione utenti a dir poco criticabile, ma mi pare che quando si tratta di linux si critica l'utente che non legge la documentazione e non si informa, poi quando si passa a windows si pretende che l'utente sappia tutto da subito... mah.
no fa proprio schifa il sistema utenti di windows xp! Prova a cambiare l'ora se sei un utente normale :sofico:

khelidan1980

10-12-2007, 21:13

no fa proprio schifa il sistema utenti di windows xp! Prova a cambiare l'ora se sei un utente normale :sofico:

bhe provaci sul linux! ;)

mad_hhatter

10-12-2007, 23:51

di default windows xp professional presenta le ACL... di default su linux mi pare ci siano solo le categorie owner,owner's group e others e come possibili azioni lettura, scrittura, esecuzione.

mi sbaglio?

darkbasic

11-12-2007, 00:06

mad_hhatter

11-12-2007, 00:24

Dipende dalla distro... in ogni caso per uso desktop sono assolutamente inutili e volendo ci vuole un secondo a modificare le impostazioni di default.
Queste sono solo pagliuzze se confrontate con le travi (ma cosa dico... pilastri di calcestruzzo) di windows... quando ho scoperto che anche in vista l'utente aveva di default i privilegi di amministrazione sono rimasto allibito.

edit:
http://www.hwupgrade.it/forum/showpost.php?p=18826107&postcount=53

dunque, intanto dipende dalla distro, mentre windows ce l'ha e basta e le usa di default, mentre in linux non sono di default.
inoltre, non stavamo riferendoci al solo ambito desktop, ma alla struttura generale del s.o.
e infine, no, non sono pagliuzze se stiamo discutendo dei pro e contro nella gestione degli utenti nei vari s.o. cercando di fare un'analisi seria.

darkbasic

11-12-2007, 09:08

A mio parere sono pagliuzze perché comunque le ACL sono pienamente supportate dal SO e il loro target non è sicuramente l'home user. Per un utente avanzato o un sysadmin non vedo dove sia il problema a montare una partizione con un parametro in più qualora ne dovesse fare uso.
Se proprio vuoi muovere una critica contro le principali distro linux ci sono veramente moltri altri punti su cui fare leva e ogni distro ha le sue travi più o meno grosse, specie le più gettonate.
Ad esempio non è ammissibile che una distro come ubuntu di default ti si pianti per colpa di una gif studiata per saturare la memoria, oppure che uno stupidissimo scriptino lanciato senza privilegi di root e che si richiami ricorsivamente ti costringa a riavviare. _Questi_ sono problemi seri (anche se non al livello di mettere un account di amministrazione in mano a un utente :doh: ). Nello specifico questi due affliggono anche windows, ma ce ne sono altri che non lo riguardano.
Di contro, se prendi ad esempio una fedora, ti ritrovi di default un hardening del sistema che poche distro possono vantare.

mad_hhatter

11-12-2007, 09:19

sono d'accordo... tuttavia stiamo iniziando a divagare, torniamo in tema: il fatto che la politica di default di windows riguardo agli utenti sia quantomeno disdicevole autorizza i produttori di software a creare prodotto osceni che necessitano privilegi di Admin solo perchè non si sono sforzati un minimo? A mio avviso la risposta è NO.

Per fare qualche esempio banale e spicciolo: una macchina si accende e corre anche se chi guida non ha la patente, ma non accusiamo le case automobilistiche per questo... la macchina di default non ti mette la cintura, però, ancora, non diamo la colpa alle case automobilistiche se chi, guidando senza cintura, si fa male...
per contro, però, pretendiamo di accendere un pc e di usarlo senza neanche pensare a cosa stiamo facendo... il sistema deve fare tutto: lasciarci la massima libertà ma allo stesso tempo prevenire ogni possibile comportamento dannoso... pretendiamo pure che sia il s.o. a ovviare a problemi di applicativi di terze parti... francamente mi pare eccessivo.

senza nulla togliere al fatto che la gestione di default fa schifo, ma non è accettabile avvocare questo come scusante per i produttori di sw

darkbasic

11-12-2007, 09:49

la macchina di default non ti mette la cintura
La macchina di default fa di tutto per fartela mettere: spia luminosa, segnale acustico...
Windows di default la cintura te la sgancia se provi a mettertela al massimo :D
La mia non è una giustificazione per i produttori di software, ma non c'è da stupirsi se non prestano attenzione alla multiutenza e partoriscono delle porcate se la M$ è la prima a farne. Di software scritti per linux che non funzionano in un environment multiutente non ne ho mai visti, pensi che dipenda dal fatto che linux di default non ti spiattella un account di amministrazione?

mad_hhatter

11-12-2007, 10:59

La macchina di default fa di tutto per fartela mettere: spia luminosa, segnale acustico...
Windows di default la cintura te la sgancia se provi a mettertela al massimo :D
La mia non è una giustificazione per i produttori di software, ma non c'è da stupirsi se non prestano attenzione alla multiutenza e partoriscono delle porcate se la M$ è la prima a farne. Di software scritti per linux che non funzionano in un environment multiutente non ne ho mai visti, pensi che dipenda dal fatto che linux di default non ti spiattella un account di amministrazione?

sicuramente sì, ma anche dal diverso approccio culturale di molti sviluppatori windows... ti do perfettamente ragione quando dici che che tale comportamento non è deprecato da parte di una diversa politica da parte di Ms, certo è che troppi software windows hanno una gestione dei permessi a dir poco idiota.

comunque capisco il tuo punto di vista.

altra cosa che non mi piace nei sw per windows e che raramente invece riscontro nei sw che hanno una versione linux ben seguita, non solo buttata là tanto per fare (esempio eclipse, semplicemente ottimo) è la mania di sparpagliare i file e le impostazioni dei vari utenti un po' ovunque e non in un unico luogo: è una cosa che non sopporto.
E purtroppo questo vizietto ce l'ha anche firefox che mette il profilo solo... boh, dati applicazioni e la cache sotto... boh, impostazioni locali/temp... non capisco il motivo di questa frammentazione

a essere onesti in linux anche kde mette nella cartella utente varie cartelle, ma almeno ha la buona creanza di metterle tutte allo stesso livello in modo da poter essere viste tutte insieme...

va beh, sono decisamente OT :)

arara

11-12-2007, 11:04

dunque, intanto dipende dalla distro, mentre windows ce l'ha e basta e le usa di default, mentre in linux non sono di default.
inoltre, non stavamo riferendoci al solo ambito desktop, ma alla struttura generale del s.o.
e infine, no, non sono pagliuzze se stiamo discutendo dei pro e contro nella gestione degli utenti nei vari s.o. cercando di fare un'analisi seria.
Le ACL non sono gratis, hanno un loro impatto sulle prestazioni, e visto che sono totalmente inutili per l'uso tipico di un desktop fanno bene a non abilitarle su quel tipo di distribuzioni, mentre sulle altre sono già abilitate di default.
Trovo che sia una scelta giusta, molti scelgono Linux per riutilizzare il vecchio PC, sarebbe inutile fargli sprecare risorse per abilitare una funzionalità che poi non gli serve.
E poi le ACL sono del tutto secondarie, vanno bene solo per rifinire i dettagli, il grosso del lavoro dipende da come sono configurati i permessi di base, se sono impostati bene si può anche farne a meno.
Quello che conta non sono le potenzialità che il sistema offre, ma come le configura e le implementa, è meglio un sistema senza ACL ma con i permessi di base configurati bene piuttosto di uno che offre le ACL ma di default ti fa entrare come amministratore.

sono d'accordo... tuttavia stiamo iniziando a divagare, torniamo in tema: il fatto che la politica di default di windows riguardo agli utenti sia quantomeno disdicevole autorizza i produttori di software a creare prodotto osceni che necessitano privilegi di Admin solo perchè non si sono sforzati un minimo? A mio avviso la risposta è NO.
Certo che non li autorizza, se fanno dei software scritti male la responsabilità è solo loro, ciò non toglie che se l'hanno fatto è perche il sistema li ha tratti in tentazione.
Queste cose non te le insegnano a scuola, ho visto gente uscire col diploma di perito informatico che non sapeva neanche installare windows e che andava a fare programmi in visual basic, che razza di software vuoi che scrivano questi? Se su windows i privilegi degli utenti fossero già configurati bene fin dall'installazione molti non avrebbero scritto quel software da cani che ti costringe di fatto a lavorare come administrator.

zephyr83

11-12-2007, 11:13

bhe provaci sul linux! ;)
su linux si riesce e senza problemi, cn kde basta andare nel pannello di controllo, cliccare sul tastino per accedere come amministratore, inserire la password e il gioco è fatto. cn xp se nn sbaglio devi proprio sloggarti e accedere come amministratore per modificare la password!

darkbasic

11-12-2007, 13:32

Non c'è bisogno di passare per il pannello, basta un click sull'orologio, modifica data/ora e kde ti chiede automaticamente la password di root con kdesu.

carne

19-12-2007, 14:12

.......

Attenzione questo post ha contenuto volutamente polemico, ma senza cattiveria..anzi con un pizzico di ironia. :)

ma a te windows ha ucciso qualche parente???ahahaha:D :D
nell'ambiente desktop WinXp è un gran prodotto. User friendly, leggero e i crash nel 99% dei casi riguardano solo l'applicazione che si può terminare e riprendere il lavoro senza riavviare la macchina.
Su un celeron 500 con 64 di ram Xp alleggerito con nlite VOLA! La Damn Small Linux arranca. Quindi non è vero che linux è più leggero;)

qui si dimentica una cosa. pc-bsd è dichiaratamente desktop. per l'utonto che usa il pc come strumento per la sua produttività-svago, non per smanettoni che si gongolano perchè nemmeno la nasa può entrargli nel pc e fanno tutto da shell e nemmeno istallano l'interfaccia grafica! chissefrega di tutte le pastrugnate da ipertecnico che hai tirato fuori!!! sono fuori luogo.
La maggior parte delle persone non ha nè il tempo nè l'interesse per cercare, interpretare, studiare how-to e manuali. E in linux, purtroppo, se non ti armi di santa pazienza vai ben poco lontano.

Sento sempre dire Winzozz ha monopolizzato win è pesante instabile.. meglio linux ecc... io a passare a linux ci ho provato più volte perchè mi piace l'idea dell'open quindi non parlo per sentito dire, ho provato, e non son proprio tanto newbie. l'ho tenuto per anche un mese, ma alla fine dato che non ho orgasmi nel risolvere problemi son tornato a win e ne ho ottenuto più salute mentale. Il pc mi serve per produrre, svago, mantenere contatti..non perchè ho piacere e godo nell'usarlo, far andare una periferica e nel compilare sorgenti. così è per il 99% della gente. Che fa di un prodotto il successo è il 99% della massa. non l'1% composto dagli smanettoni.

Cosa serve in un pc casalingo???
1 - lavorare comodi e KDE (lo reputo più avanzato di gnome) già offre questo
2 - istallare programmi con 2 click. Il 90% delle persone istintivamente fa questo...clicca su quello che vuole. Meglio ancora trascinare il binario completo di tutto (e basta con ste dipendenze e problemi di spazio) nella cartella dei programmi e ritrovarselo poi automaticamente nel menu.
3 - se proprio necessario, istallare eventuali driver con un click.

ora pc-bsd sta cercando di fare qualcosa del genere, io lo trovo LODEVOLE perchè non è cosa da poco.
Appena avrò tempo e un pc disponibile per far prove lo proverò, anche se mi preoccupano i driver.

khelidan1980

19-12-2007, 21:07

su linux si riesce e senza problemi, cn kde basta andare nel pannello di controllo, cliccare sul tastino per accedere come amministratore, inserire la password e il gioco è fatto. cn xp se nn sbaglio devi proprio sloggarti e accedere come amministratore per modificare la password!

Non c'è bisogno di passare per il pannello, basta un click sull'orologio, modifica data/ora e kde ti chiede automaticamente la password di root con kdesu.

Si be ok,ma implica l'utilizzo di sudo nel secondo caso e della pass di root addirittura nel primo!

zephyr83

19-12-2007, 21:30

Si be ok,ma implica l'utilizzo di sudo nel secondo caso e della pass di root addirittura nel primo!
si ma si può fare! cn xp se nn sbaglio devi sloggarti e e riconnetterti come amminastratore!!! Infatti nn sto dicendo che xp nn è multiutente ma che sta parte è fatta proprio male!

Dane

19-12-2007, 23:08

x zephyr83
guarda che non è detto che è "cattivo" ciò che non chiede sempre e costantemente la password di root per ogni demenza. In un ambiente di lavoro, dove l'utilizzatore del pc deve solo lavorare e non gestire il sistema è IMHO meglio se non c'è proprio la possibilità di modificare certe impostazioni.
Poi con winxp non è che devi sloggarti e riloggarti come admin, basta fare il login parallelo, che tutti disabilitano perchè si mangia un botto di ram :stordita:

x carne
magari windows sta 10 secondi in meno ad avviarsi rispetto a DSL, ma per il resto non credo proprio che sia più veloce.
Tanto per darti un confronto avevo winxp abbondantemente purgato su un celeron 466 con 64mb di ram. xDSL su un xbox con pari ram in confronto era molto più veloce nell'utilizzo. Proverò anche DSL sullo stesso cesseron, tanto per avere un confronto diretto.

carne

20-12-2007, 11:11

x zephyr83

x carne
magari windows sta 10 secondi in meno ad avviarsi rispetto a DSL, ma per il resto non credo proprio che sia più veloce.
Tanto per darti un confronto avevo winxp abbondantemente purgato su un celeron 466 con 64mb di ram. xDSL su un xbox con pari ram in confronto era molto più veloce nell'utilizzo. Proverò anche DSL sullo stesso cesseron, tanto per avere un confronto diretto.

nono intendo anche nell'uso..soprattutto multimediale (per quanto possa essere multimediale un celeron500!!).
lo stesso divx con DSL scattava, win su VLC no.

MaxFun73

20-12-2007, 13:35

Tanto per darti un confronto avevo winxp abbondantemente purgato su un celeron 466 con 64mb di ram. xDSL su un xbox con pari ram in confronto era molto più veloce nell'utilizzo. Proverò anche DSL sullo stesso cesseron, tanto per avere un confronto diretto.

Si ci credo, la CPU dell'XBOX è una via di mezzo tra un Celeron ed un P3 e poi viaggia a 733MHz, mi sembra logico che "giri" meglio di un Celeron 466MHz. :D

Hire

20-12-2007, 19:43

Mi sembra strano che un celeron 500 e solamente 64 mb di ram riescono a far "volare" winxp, sul serio...
Ed inoltre non ci si può fare molto dato che con un solo Firefox occuperebbe tutta la RAM ed andrebbe di swap.

Con Ubuntu e le altre distro utonto-friendly ci sta il repository che contiene ben 20000 pacchetti.
Basta andare su "Aggiungi/rimuovi applicazione" e con un click installi tutto quello che ti interessa. Windows da questo lato è più facile? E come?

Il più grande problema dei driver è sempre stato uno: quelli video.
Adesso invece appena li rileva ti chiede se vuoi installarli o no. Un click ed hai quello che vuoi.

Io non capisco quindi dove sta la difficoltà, dove sta questa "perdita di tempo nello installare un programma" e perchè gnu\linux non sarebbe produttivo.

zephyr83

20-12-2007, 20:46

nono intendo anche nell'uso..soprattutto multimediale (per quanto possa essere multimediale un celeron500!!).
lo stesso divx con DSL scattava, win su VLC no.
bhe può dipendere da tante cose! spero almeno che vlc fosse nella stessa versione sia su windows che su DSL

Hire

20-12-2007, 21:01

Perchè poi usare VLC che è un bel macigno quando esiste mplayer? :mbe:

zephyr83

20-12-2007, 21:15

Perchè poi usare VLC che è un bel macigno quando esiste mplayer? :mbe:
ma per mplayer nn servono i codecs? vlc nn va senza codecs esterni?

Hire

20-12-2007, 21:30

ma per mplayer nn servono i codecs? vlc nn va senza codecs esterni?

Basta installarli ed il problema è risolto :mbe:

zephyr83

21-12-2007, 03:32

Basta installarli ed il problema è risolto :mbe:
bhe era per poter valutare meglio il comportamento del programma cn due sistemi operativi diversi!

Hire

21-12-2007, 12:03

bhe era per poter valutare meglio il comportamento del programma cn due sistemi operativi diversi!

VLC ha dei problemi comunque, non è perfetto e tipo con dei video WMV fa fatica :mbe:

Poi è anche pesante ed a questo punto preferisco mplayer che mi legge praticamente qualsiasi formato esistente.

bongo74

12-03-2008, 18:30

in ogni caso i vantaggi dei pbi sono irrinunciabili.
chissenerega se il sistema occupa 500Mb di hard disk in +, oppure 50MB di ram in +.

l'importante è che sia stabile,facile,semplice da usare,gratuito e senza virus

darkbasic

12-03-2008, 19:44

Ma anche no.
E comunque sullo "stabile" e il "senza virus" avrei qualcosa da ridire nel caso di adozione in massa dei pbi...

Barone di Sengir

20-03-2008, 01:47

mi inserisco nella diatriba e mi riporto sulla "discussione" precedente
(mi scuso anche se scrivo cose sconnesse ma ho sonno...)

Come gentilmente qualcuno ha fatto notare linux è un kernel, le distribuzioni sono gli os, il "problema" del software che non c'è nei repository (ed è poco) quando si presenta?
si presenta quando sei un "mezzo smanettone" cioè quando vuoi fare cose che non sei, in realtà, capace di fare.
Mi spiego meglio:
il cosiddetto "utonto" si installa Ubuntu bello tranquillo, fa click su applicazioni, aggiungi/rimuovi programmi e trova praticamente tutto quello che gli serve per la produttività personale (i programmi da ufficio che non ci sono lì sono solo per windows solitamente... o cmq a pagamento).
Lo smanettone si installa il kernel e sceglie con cura tutti pacchetti (o sorgenti) da installarsi per cui sa perfettamente quale versione di quale software utilizzare, e se questo è in grado o meno di girare sulla sua macchina.

il mezzo smanettone è colui il quale ha messo una distribuzione "facile", magari ubuntu, però dopo 3 mesi vede che è uscita la versione nuova del programma X che nei repository non c'è (questo perché alla canonical stanno già lavorando alla versione nuova...) e vorrebbe installarlo. allora preso dalla foga si scarica il sorgente e va a compilarlo ma si becca 1000 errori per le dipendenze e inizia a bestemmiare.

Questo atteggiamento è dannoso per il sistema perché installare software al di fuori del package manager infila file senza poi tenerne correttamente traccia! ed è grossomodo il problema di windows con le .dll
Dimenticavo: il mezzo smanettone logga come root, perché è + bravo ;)

Con questo non sto dicendo che chi ha proposto la cosa del .pbi sia un deficiente, ma semplicemente che introdurre questo tipo di gestione del software sarebbe come segare al 90% le gambe della sedia su cui poggi il beneamato c**o...

Nell'immediato futuro, si spera anche in Italia, linux è destinato ad entrare in massa nelle PA e negli uffici, dove i pc usano software generici o facilmente portabili. In questi ambiti la sicurezza fornita dai repository e dal non usare l'account root, chiunque potrebbe trovarsi un pc "nuovo" semplicemente cancellando la cartella dell'utente precedente...

Detto questo aggiungo una cosa al discorso su windows e permessi:
io sono un discreto videogiocatore e, purtroppo, i giochi che + mi piacciono non esistono e non non sono giocabili su console (civilization, serie total war, ecc ecc). Quindi uso windows (in questo momento vista 64) e, con il tempo e la pazienza, ho imparato a farlo stare sotto il mio controllo.
Però vedo i computer di amici/parenti che sono impestati da qualsivoglia malware/spyware o peggio.
E' sicuramente colpa loro, che all'atto pratico hanno scaricato ed installato il software, ma bisogna ammettere che se avessero una macchina linux con le stesse potenzialità probabilmente non si troverebbero con quei problemi, un pò perché non esistono tutti quei software, un pò perché se su un sito leggi: "scarica il .deb poi apri la shell e digita sudo bla bla bla" A ti passa la voglia B ti insospettisci pure un pochino...

Chiudo qui :D
se ho scritto troppe cazzate bastonatemi pure, tanto sto dormendo :fagiano: