Commenti a: LSB Package API: Linux Foundation vs i Dinosauri

Di: evamos

evamos — Tue, 08 Jul 2008 18:28:44 +0000

“Perché ad esempio non dovrei volere aggiornare all’ultimo kernel installando un semplice pacchetto funzionante per qualsiasi distribuzione?”

magari, visto che gli ultimi driver sono solo nei kernel in sviluppo, ma non vorrei che poi si debba combattere con l’instabilita’ dei kernel non testati. inoltre c’era qualche programmino che ora non ricordo che prometteva di semplificare al massimo la compilazione e l’installazione del kernel, salvo poi non funzionare come promesso.
rimane la sfida di trovare un posto ai driver diverso dal kernel per poterli aggiornare separatamente, chissa’.

Di: gitpen

gitpen — Sun, 06 Jul 2008 16:18:23 +0000

sperando che parlarne sia utile …
il concetto di distribuzione comincia a stare stretto e sarebbe utile superarlo.
ammirazione per Mark Shuttleworth.
installare programmi come wiznwd o come il mac (infodomestic), basta che ci si decide.
e le belle idee sui driver hardware sono finite nel dimenticatoio?
secondo me ci devono essere persone molto fighe e ben stipendiate che si occupino di valutare le idee e di scegliere come metterle in pratica.
ottimizzazione del codice, esiste ancora un concetto simile?

Di: Lele

Lele — Tue, 01 Jul 2008 21:10:28 +0000

Ho usato linux per 8 mesi ( archlinux, ubuntu, kubuntu, xubuntu e altre 10/11 distro ) su un pc che davo per morto e che volevo resuscitare come “server” p2p. Era la prima volta che usavo un sistema basato su linux ed ho imputato i primi fallimenti ( nel senso che il pc rendeva meno di quel che pensavo ), alla mia inesperienza. Ma dopo “non so quante ore” spese ad aggiornare pacchetti e librerie e aggiornare pacchetti di librerie che andavano in conflitto con altre librerie pacchettizzate male e miliardi di password di root inserite e compila il kernel che forse è quello che rompe e ma va che è tutto opensource ed è gratis…mi son rotto le scatole e in meno di mezz’ora gli ho messo un sistema che funziona benissimo, che non è open ma che comunque ha tanto gustoso software freeware. Vi giuro che se non fosse stato per tutti quei pallosissimi pacchetti da complilare e tutti quei conflitti incrociati risolvibili SOLO grazie a forum tecnici ultraintasati ( sfido io un utente inesperto a capire gli errori di compilazione ) probabilmente avrei tenuto linux. Da quel poco che ho visto ( per fortuna ) direi che il problema sollevato in questo topic è fondamentale per la riuscita di questo SO. Ma credo anche che non sia possibile risolverlo senza limitare in qualche modo il concetto stesso di Opensource.

Di: Golem

Golem — Mon, 30 Jun 2008 17:18:01 +0000

l’ipotesi del complotto nel mondo *nix mi mancava

Di: jack

jack — Mon, 30 Jun 2008 11:33:37 +0000

@2 non ho intenzione di mettere sul mio pc anche una sola riga di codice proprietario…(magari solo il bios ;) )

Di: aNoNiMo

aNoNiMo — Thu, 26 Jun 2008 08:13:36 +0000

@Don
certo che un’analisi sulla stabilità di un sistema operativo fatta da uno che non sa nemmeno i concetti basilari di un sistema operativo è tutta un programma -_-
non è affatto vero che windows è instabile perchè i programmi usano librerie linkate staticamente, non esiste alcun problema di stabilità e ti sfido a dimostrare il contrario.
e non è affatto vero che io auspico una gestione delle applicazioni alla windows! le applicazioni closed source sono in netta minoranza nella mia (come in tutte le altre) installazione di linux.
in questa minoranza di applicazioni ci sono anche software house che hanno tempo e denaro da investire su linux e forniscono il loro software pacchettizzato (skype e picasa per fare un paio di esempi). quindi sarebbe solo una parte di questa minoranza che dovrebbe ricorrere alle librerie statiche.
ma anche se fosse le librerie statiche non sono mica un crimine di guerra, sono solo uno strumento di sviluppo.

Di: Don

Don — Wed, 25 Jun 2008 22:49:08 +0000

Dite quello che volete ma intanto i fatti non cambiano.
Winz deve buona parte della sua instabilit? proprio alla ricerca esasperata di retro compatibilit? attraverso un uso eccessivamente libertino di librerie statiche mentre su questo lato l’eccessiva libert? dei maintainer delle distribuzioni di fare patch casalinghe sulle librerie condivise ci porta ad una condizione dove finiamo per ipotizzare e non vorrei dire sognare una soluzione simile al mondo winz per poter finalmente espandere il supporto software a linux.

…quando sarebbe tanto semplice organizzarsi, darsi una regolata… ma la canzone parla chiaro

la soluzione esiste,
ma non si deve dire !
Si compie gran peccato
a voler fare le cose in modo unificato
o solo un po? organizzato
no no no no no noooo

viene solo da chiedersi se la causa di una simile situazione ? ancora contenuta nella canzone con i riferimenti sul sadomaso o se pi? semplicemente c’? qualcuno che ci guadagna da questo macello (magari proponendo assistenze) guardandosi bene di tenere il resto dell’utenza nell’ignoranza e nel becero fanatismo cos? che il sistema non possa mai evolversi ed elevarsi da questo problema

Di: aNoNiMo

aNoNiMo — Wed, 25 Jun 2008 20:11:28 +0000

@Don
scusami ma veramente fatico a capire il tuo esempio :F intendi dire che la libreria buggata potrebbe sovrascrivere la memoria della libreria non buggata? questo assolutamente è da escludere perchè tutti i sistemi operativi moderni usano la paginazione della memoria.
se invece intendi che i due vettori sono nella libreria buggata allora non mi stupisce che ci sia un problema (considerando che è buggato :P )
poi non è affatto vero che l’uso delle librerie condivise è migliore sempre! ci sono pro e contro come tutte le cose di questo mondo. il vantaggio principale è che aggiornando la libreria condivisa è come se si aggiornassero anche tutti i programmi che ne fanno uso, e questo è un bene per questioni di sicurezza. altri vantaggi riguardano lo spazio occupato, ma attualmente mi sembrano considerazioni superate.
se però stiamo parlando di software closed source allora l’uso di librerie linkate staticamente ha senso perchè annulla il problema della compatibilità con le librerie presenti nel sistema.
in ogni caso mi sembra avventato parlare di “uso diffuso di librerie statiche”… ho parlato di software closed source, il resto del software (si spera il 99.9%) rimane tale e quale.
ovviamente se una software house ha tempo e denaro da investire può anche testare su quelle 5 o 6 distro più diffuse e pacchettizzare in proprio.

Di: tosky

tosky — Wed, 25 Jun 2008 19:55:46 +0000

@Don, se partiamo dal presupposto che ” ma siamo sicuri che la riuscita non dipenda in larga parte dal fatto che con tutta la ram che c’è, andare a beccare due gruppi contigui di celle di memoria è proprio una botta in culo ?” allora mi sa che mancano un po’ di fondamenti di sistemi operativi, e di gestione della memoria virtuale, e non c’è molto altro da dire.

Di: Don

Don — Wed, 25 Jun 2008 19:31:36 +0000

@46

In teoria il sistema riesce a tenere separati i programmi ma siamo sicuri che la riuscita non dipenda in larga parte dal fatto che con tutta la ram che c’è, andare a beccare due gruppi contigui di celle di memoria è proprio una botta in culo ?

Ipotizziamo che la ram disponibile sia appena sufficiente a contenere i due vettori, quante garanzie ci sono che il programma buggato non vada a colpire il vettore buono ?

E comunque senza cercare strani giri ed abusi deducibili dallo standard del c si può sempre sintetizzare che un sistema è tanto più sicuro quanto è meglio organizzato al suo interno e tra due stili organizzativi di pari sicurezza risulta sempre migliore quello più semplice.
L’uso di librerie condivise è sempre la soluzione migliore ma purtroppo con linux e le smanie di libertà di molti irresponsabili siamo costretti a rivalutare un pasticcio come l’uso diffuso di librerie statiche.