Ci siamo giocati PC-BSD...

[R4iDei]

Originariamente inviato da †Gh0stRiDer†

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 . Ma la libertà di usare qualsiasi repository anche il piu zozzo della terra noi utenti dobbiamo averlo!

[Gh0stRiDer]

Originariamente inviato da R4iDei

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 . Ma la libertà di usare qualsiasi repository anche il piu zozzo della terra noi utenti dobbiamo averlo!

Spero solo non li metta ubuntu questi .pbi...

[andreas.troschka]

Originariamente inviato da R4iDei

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 . 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.

!!!
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 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.

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.

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. 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]

Originariamente inviato da andreas.troschka

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

!!!
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 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.

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.

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. 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?
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]

Originariamente inviato da zephyr83

quindi vista è sicuro come linux perché è finalmente un vero sistema multi utente?
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]

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]

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

[khelidan1980]

Originariamente inviato da Fil9998

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

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

[Dcromato]

Originariamente inviato da khelidan1980

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]

Originariamente inviato da Dcromato

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]

Originariamente inviato da khelidan1980

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

[zephyr83]

Originariamente inviato da Dcromato

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 è 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]

Originariamente inviato da zephyr83

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

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.

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.

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).

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).

[zephyr83]

Originariamente inviato da andreas.troschka

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.




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.



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).

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).

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]

Originariamente inviato da zephyr83

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?

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...

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!

Meditate gente, meditate. ;-)

[zephyr83]

Originariamente inviato da andreas.troschka

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?

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]

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]

Originariamente inviato da andreas.troschka

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]

Originariamente inviato da mad_hhatter

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...
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]

Originariamente inviato da mad_hhatter

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