jump to navigation

LSB Package API: Linux Foundation vs i Dinosauri

felipe in: News e altre Sciccherie il 24/06/08 @ 15:08 , trackback
1 vote, average: 4 out of 51 vote, average: 4 out of 51 vote, average: 4 out of 51 vote, average: 4 out of 51 vote, average: 4 out of 5 (media: 4, registrati per votare)
Loading ... Loading ...


Da qualche giorno leggo con crescente interesse la proposta di Linux Foundation per risolvere i problemi di gestione delle applicazioni di terze parti con quello che loro chiamano “LSB Package API“, anche se con un occhio un po’ disincantato per la risposta degli sviluppatori.

Il problema è quello classico (ne accennavo ieri, cfr “Non-recensione di AerX 1.0“): installare applicazioni di terze parti su Linux e altri *nix è scomodo, irrazionale e assurdamente complicato, almeno quanto per contro è comodo, razionale e semplice installare applicazioni e librerie di sistema. Nonostante questo evidente problema, c’è un grande fetta di distributori poco disposti a cedere un millimetro nella gestione del software per i loro prodotti.

Comodo, razionale, semplice. O tutto l’opposto

Potevo includere anche qualche altro aggettivo, ma questi tre bastano ad indicare la situazione attuale riguardo alla gestione del software di sistema su Linux.

Comodo, razionale e semplice come può essere un comando via terminale o qualche di click in una interfaccia con cui è possibile installare, rimuovere, aggiornare software di sistema. Al contrario invece, basta allontanarsi dal caso d’uso precotto dal distributore per trovarsi totalmente spaesati. Voglio installare un software di terze parti, sconosciuto come AerX o famoso come Firefox? Mi tocca sudare, aspettare o combinare impiastri, sempre e comunque.

Resta poi aperta la questione della definizione di cosa sia software di sistema e cosa no. Perché ad esempio non dovrei volere aggiornare all’ultimo kernel installando un semplice pacchetto funzionante per qualsiasi distribuzione?

PackageKit e LSB Package API

PackageKit, di cui ho spesso scritto in passato e LSB Package API sono entrambi nati come semplici livelli di astrazione per accomunare sotto un’unica interfaccia le potenzialità di APT, RPM e tutti gli altri gestori di pacchetti. Quello che contraddistingue LSB Package API è inoltre la definizione di Manifest Files per i pacchetti, documenti XML contenenti informazioni necessarie alla gestione dei pacchetti.

La differenza principale tra i due sembra essere che PackageKit è più mirato ad affiancare sistemi di gestione del software basati su repository (APT, YUM) mentre LSB Package API è indirizzato a gestire singoli pacchetti in maniera neutrale. Possiamo dunque azzardare che i due progetti svolgano compiti in qualche modo complementari.

Per noi poveri mortali non è immediato capire il motivo per cui la Linux Foundation non abbia abbracciato PackageKit, ma poi basta leggere cosa ha da dire Richard Hughes a riguardo, per avere tutto un po’ più (o meno?) chiaro:

[they] Try to solve a problem that doesn’t exist

Cercano di risolvere un problema che non esiste (T.d.felipe)

If there was a requirement for a distro-neutral 3rd party application installer (which I don’t think there actually is) then it should be a tiny shared (static?) library that just depends on libc or /bin/sh

Se ci fosse l’esigenza di un installatore di applicazioni di terze parti neutrale rispetto alle distribuzioni (e non penso che ci sia), dovrebbe essere una piccola libreria condivisa (statica?) che dipenda solo da libc o /bin/sh (T.d.felipe)

I’m afraid the LSB Package API has got caught in the classic new project trap of “wouldn’t it be cool if we used ${technology}” and actually forgotten to ask customers what they want.

Temo che la LSB Package API sia rimasta nella classica trappola del nuovo progetto che “non sarebbe bello usare ${tecnologia}?” e in realtà dimentica di chiedere all’utente cosa voglia. (T.d.felipe)

Beh in realtà direi che al contrario il problema esiste, eccome: c’è una sentita necessità di avere un sistema neutrale per installare applicazioni di terze parti e sono anni che faccio eco alle intenzioni della Linux Foundation e di Ian Murdock (Mr papà di Debian) di mettere i principali distributori d’accordo su questo punto. Un possibile punto d’incontro o convergenza tra i due progetti a questo punto mi sembra decisamente fuori luogo.

Dobbiamo aspettare una qualche glaciazione?


PS: Lo so che questo è uno degli argomenti più noiosi che si possano trovare su pollycoke, ma resto convinto che dalla soluzione del problema dipenda gran parte dell’affermazione di Linux e affini.

Commenti»

1. matty - 24/06/08 @ 15:14

Non è che c’è qualcuno che sembra considerare la semplicità una cosa brutta,sporca e immorale?
Una di quelle cose di dubbio gusto di cui non è bene parlare tra persone bennate?

2. Rocker - 24/06/08 @ 15:20

Dopo diverso tempo che leggo il tuo blog, mi sembra arrivato il momento giusto per scrivere.

L’installazione di software di terze parti su Linux e’ un punto chiave per lo sviluppo del sistema operativo. Immaginate quante software di alto livello inchioda ancora la gente all’utilizzo di Windows (Photoshop? Video Editing professionale? Audio?), che e’ un sistema operativo mediocre. E’ come mettere su una intellaiatura di cartone (Windows) motori da centinaia di cavalli. Forse la macchina andra’ lo stesso a 300km/h, ma per quanto?

Quando si trovera’ un metodo univoco per installare software di terze parti su Linux, la sua diffusione non potra’ che trarne giovamento.

3. Anonymous - 24/06/08 @ 15:36

Concordo pienamente.

4. finto - 24/06/08 @ 15:38

Ma se parliamo di quanto sia scomodo distribuire il software per terze parti su linux perchè tiri in ballo package kit? Packagekit non ha nulla a che fare con il modo di pacchettizzare e distribuire il software e riguarda solo l’interazione degli utenti con il software installato. Purtroppo non mi pare che possa facilitare la distribuzione del software in alcun modo. E di klik invece? Non ne parli più?

5. finto - 24/06/08 @ 15:46

Ho letto le fonti citate…ora cpisco perché packageKit entrava in ballo nel discorso. Ciò non toglie che packageKit pur essendo una ottima ed util tecnologia, non sposta di una virgola il problema di una sorta di pacchettizzazione universale. Concordo anch’io che questa situazione sia uno show-stopper per linux…anche se ormai lo sappiamo da anni :-(

6. bulgarion - 24/06/08 @ 16:00

Sono pienamente d’accordo, capita spessissimo che “o-va-alla-prima-botta-o-dopo-3-settimane”… esempio pratico, rTorrent + wTorrent (GUI). Ci ho messo 2 settimane per risolvere i minchioproblemi di cacchiodipendenza! E solo perchè non c’era un DEB aggiornato!

7. Anonymous - 24/06/08 @ 16:04

Bhe, io proprio non vedo perchè i software di terze parti debbano essere un problema… in cosa differiscono?
A questo punto è evidente che il problema non è l’ essere “di terze parti” o meno, ma di essere o non essere scritto col c*lo.. perdonatemi la volgarità.. :/

8. Golem - 24/06/08 @ 16:08

Il punto è che il paradigma della semplicità viene visto comunemente come un click&install di un binario …
Questo approccio su *Nix si porta dietro molteplici problemi … alcuni dei quali sono declinazione della disomogeneità dei pacchetti binari … altri in realtà attengono alla disomogeneità tra le distribuzioni (che non sono solo i pacchetti).

Se ciascuna distribuzone avesse un sistema semplificato per la compilazione e la gestione delle dipendenze dei sorgenti si risolverebbero molti problemi, non ultimo la qualità dei pacchetti binari, testabili da sorgenti prima di essere disponibili come binari nei vari repository … ma soprattutto l’accessibilità da parte dei 3rd party alle distribuzioni … l’impegno per la quale sarebbe piu progressivo e sostenibile.

Però, tantè … non essenso tanto una sluzione tecnica, quanto di costume … è davvero difficile

9. prot - 24/06/08 @ 16:17

sono dell’idea che se ci fosse un sistema standard di compilazione dei sorgenti in pacchetti binari sulla falsariga dei PKGBUILD di arch, i ports di freebsd o gli ebuild di Gentoo, ne trarrebbero giovamento i distributori di software (sia che distribuiscano i sorgenti, che distribuiscano binari).

10. bLax - 24/06/08 @ 16:19

ma REALMENTE esiste la possibilità di far funzionare programmi esterni in TUTTE le distro (quelle che si allinano chiaramente) sopravalicando apt, rpm, yum e quant’altro?

questo attualmente è il vero punto debole di linux (prima era la barriera del user-friendly, ma direi ampiamente abbattuta ora) a livelli commerciali. a nessuna azienda software closed conviene buttarsi nel riadattare le loro killer-app (penso ad Adobe e la sua suite) al mondo variegato-multicolor-psichedelico delle distro, tenendo conto che tutto insieme questo mondo occupa si-e-no l’1% del totale!!!

come è possibile che la linux foudation+tutte le maggiori distro non vedano e provvedano a questa falla??è chiara come il sole!!!

11. MementoMori - 24/06/08 @ 16:27

avere troppe soluzioni è spesso un problema.
Se ci fosse un modo unico di distribuire i sorgenti fare pacchetti sarebbe più semplice e automatizzabile.
Se non ci fossero 10 distro con librerie differenti installate sarebbe più semplice inserire i binari di terze parti
I produttori di software non sono abituati a rilasciare rebuild dei loro software solo perchè su un paio di distribuzioni maggiori è cambiata la versione di una lib.
Non so ma forse se ci fosse solo una distribuzione ufficiale gestita da persone in gamba sarebbe meglio.

12. Golem - 24/06/08 @ 16:34

@11 —> sarebbe la morte civile … soprattutto per chi non usa distribuzioni binarie per via dei loro limiti

13. Castore - 24/06/08 @ 16:49

Ma il progetto Klick non potrebbe ovviare il problema?

14. Anonymous - 24/06/08 @ 16:55

@13
Potrebbe eccome, se prendesse piede come standard di distribuzione…

15. markus - 24/06/08 @ 17:13

Opera si installa comodamente su parecchie distribuzioni.

16. MementoMori - 24/06/08 @ 17:33

@12
uh?
limiti delle distribuzioni binarie? non riesco a capire. forse intendi quelle distro che non accettano software non opensource ma non centra nulla comunque.
Io penso che se canonical, il gruppo debian e red hat si fondessero in un unico gruppo supervisionato dalla Linux Foundation nascerebbe una società veramente competitiva sia in ambito server che in ambito desktop. Forse non sarebbe necessaria neanche la presenza di debian a meno che non rivedano certe logiche ormai anacronistiche.
Un gruppo del genere avrebbe una potenza di sviluppo molto maggiore e si rispamierebbero tutte le risorse buttate per pacchettizzare 10 volte lo stesso software.
Questo gruppo dovrebbe creare il s.o. Linux “ufficiale” e di riferimento per tutti i vendor. Chi non fa parte del gruppo o segue o si adegua.

17. Golem - 24/06/08 @ 18:01

@16.MementoMori
Intendo i limiti intrinsechi in ciascuna distribuzione precompilata che usa pacchetti precompilati.

Se Canonical, Debian e Red Hat si fondessero, dato che ora rispondono a Target e Requisiti differenti e per molti versi incompatibili, creerebbero molto piu malcontento che soddisfazione.
Debian e RedHat sono 2 cose diverse per delle precise ragioni, non per un capriccio o per una guerra di religione

18. Satchmo - 24/06/08 @ 18:33

Ma VirtualBox è difficile da installare su linux? Matlab? Eclipse?
Sono tutte applicazioni che si possono installare facilmente in maniera indipendente dalla distribuzione.
Questo secondo me dimostra che se queste “terze parti” hanno davvero la volontà di distribuire il loro software per linux, il modo lo trovano.

19. MementoMori - 24/06/08 @ 18:34

@golem

perchè malcontento?
se ne tolgono 3 di medio livello e ne nasce una di alto livello. Eppoi malcontento x chi? Intanto si crea un punto fermo e si invogliano le aziende a svilupparci e a fare il porting delle applicazioni (questo lato desktop).
Lato server si evita di dover andare a guardare le sottili differenze di configurazione tra le varie distro rendendo la vita più semplice agli admin.
Se poi intendi quei 4 fanatici della comunità che sarebbe meglio perderli che trovarli allora si, loro sarebbero malcontenti :)

20. khelidan - 24/06/08 @ 19:11

Non c’è bisogno di fondere le varie debian ecc,basta avere dei criteri ufficiale e ben definiti su come dovrebbe essere strutturata una distro,poi chi si adatta bene e gli altri facciano come vogliono,i distributori tipo adobe forniranno il loro sw aderente a quei criteri,e sicuramente funzionerà sulle distro che li hanno implementati,sulle altre forse si o forse no,ma i vari vendor dovranno far riferimento solo a quello che stabilisci la linux foundation

21. Golem - 24/06/08 @ 19:15

@Mementomori
perche, come ho scritto sopra, distribuzioni come Debian e RedHat (…) non si differenziano per capriccio … ma seguono paradigmi diversi … non sono incompatibili perché si stanno sulle balle reciprocamente, ma forniscono a problemi diversi soluzioni che (per via dei paradigmi di cui sopra) hanno la tendenza a escludere chi naviga al di fuori del proprio ambito.

Dimmi Memento … come faresti a fare fondere Debian e RedHat … convinceresti Debian a rinunciare ai suoi paradigmi etici e alla suo modello di sviluppo (unico e che la rende unica) … oppure convinceresti RedHat a rinunciare alla sua vocazione Enterprise, alla sua certificabilità, ai suoi brevetti (considerando che RedHat è fatta per fare business)?
Non sto descrivendo il Buono e il Cattivo … e non sono le due uniche distribuzioni ad essere come l’olio e l’acqua … ma se prendi ciascuna delle grandi distribuzioni, scopri che è una grande distribuzione proprio perchè a fatto delle scelte precise, che tra le altre cose le escludono quegli utenti incompatibili con quelle scelte.

Non esiste la distribuzione universale … nemmeno windows è un sistema operativo universale … perche ha molti flavour, e per molti che siano sono comunque troppo pochi per intercettare tutti i potenziali utenti.

Lato desktop, quali principi seguiresti per etichettare come Alto o Basso livello le distribuzioni candidate? … e chi lasceresti fuori? e quali delle soluzioni concorrenti di ciascuna di queste distribuzioni abbandoneresti, creando chiaramente un Fork per mantenere in vita quella distribuzione?

Lato server … Il Configuration Management non è minimamente un problema, e i SysAdmin hanno tutte le soluzioni per gestire situazioni uniformi o miste.

22. grigio - 24/06/08 @ 19:19

I distributori di software proprietario, driver, giochi, vogliono lo standard e sarebbe anche l’ora (oppure si passa a .msi)

Nel frattempo c’é PackageKit, un’ulteriore astrazione, che per lo meno prova a dare una GUI coerente (Desktop, mobile, qt, gtk) ai vari sistemi di pacchettizzazione.

23. grigio - 24/06/08 @ 19:19

I distributori di software proprietario, driver, giochi, vogliono lo standard e sarebbe anche l’ora (oppure si passa a .msi)

Nel frattempo c’é PackageKit, un’ulteriore astrazione, che per lo meno prova a dare una GUI coerente (Desktop, mobile, qt, gtk) ai vari sistemi di pacchettizzazione.

http://packagekit.org/pk-screenshots.html

24. finto - 24/06/08 @ 19:30

@grigio: purtroppo di packagekit le terze parti non sanno che farsene. E’ un altro livello. Serve a rispondere ad un altro problema legato al software che è quello dell’interfaccia di gestione dei pacchetti unitaria per le distro. Il problema sotto rimane.
Riguardo a klik invece penso che siaun peccato che non venga utilizzato maggiormente. Certo per progetti complessi e vasti il problema rimane. Le dipendenze sono tante ed includerle tutte in un pacchetto klik è spesso ridondante e quantomeno sub-ottimo.

25. Don (in versione Elio) - 24/06/08 @ 19:45

(canticchiando elio…)

ti amo
ti amo pinguinazzo
perchè non sei incasinato
mi avevano detto che eri incasinato
ma no no non sei incasinato
a me mi eri sembrato incasinato
mi hanno detto che era solo libertà
due o tre (mila) persone di troppo che fanno le cose a caxxooooo….

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

l’anarchia è cosa tanto bella
indi, cantiamo tutti insieme

ti amo
ti amo pinguinazzo
perchè non sei incasinato
mi avevano detto che eri razzo
ma non funziona mai un caxxo
se sputo sangue ti degni di girare
altrimenti me le fai solo roteare
tra una promessa e l’altra
siamo arrivati nel duemilaeotto
e stiamo ancora qui
a cincischiare su come installare i pacchetti…

soffrire è tanto bello,
ognuno per se,
Dio per tutti,
ma quale gusto c’è
ad aver le cose semplici
se sei un vero utente
godi a soffrire come un demente
una botta la va l’altra
un calcio qua
una chiappa là
oh si ti porgo anche quella làaaa…

la sodomia è cosa tanto bella
indi cantiamo tutti insieme

ti amo
ti amo pinguinazzo
perchè non sei incasinato
mi avevano detto che eri incasinato
ma no no non sei incasinato
a me mi eri sembrato incasinato
mi hanno detto che era solo libertà
due o tre (mila) persone di troppo che fanno le cose a caxxooooo….

è così bello
inventare nuovi casini
spacciarli per soluzioni
che fanno cilecca anche loro
così il problema rimane

il mondo va avanti
l’importante è credere di stare al passo
indi, cantiamo tutti insieme…

ti amo
ti amo pinguinazzo
perchè non sei incasinato
mi avevano detto che eri razzo
ma non funziona mai un caxxo
se sputo sangue ti degni di girare
altrimenti me le fai solo roteare
tra una promessa e l’altra
siamo arrivati nel duemilaeotto
e stiamo ancora qui
a cincischiare su come installare i pacchetti…

26. Gianvacca - 24/06/08 @ 20:21

GRANDE DON!!!!!!

27. ? - 24/06/08 @ 20:57

ma a me che me frega della diffusione linux? ho ubuntu, funziona, pace :D

28. Luca - 24/06/08 @ 21:50

AHAHAH
mitico Don , mi ti ci EEST!

29. Njkjta - 24/06/08 @ 21:58

Volevo provare la nuova release di FireFox 3.0 sfruttando KLIK, quindi mi sono recato sul sito del progetto nella speranza di trovare la soluzione, ma ho avuto la spiacevole sensazione che fosse tutto fermo: FF è disponibile alla versione 2.0.0.1 ed anche altri software risultano molto datati (il blog è disabilitato).
Su KLIK2 non ho trovato molte notizie.

Felipe, siamo sicuri che non sia tutto finito in un klik?

30. aNoNiMo - 24/06/08 @ 22:14

non ho mai capito qual’è il problema di linux nella distribuzione di software di terze parti… a me sembra solo incompetenza mista a pigrizia.
basta fare esattamente ciò che si fa su windows: si compila l’eseguibile con le librerie linkate staticamente oppure fornite insieme al software e si fa un’installer del tipo avanti avanti fine
non capisco per quale motivo ciò non sarebbe possibile su linux. sicuramente è una soluzione poco elegante, ma è esattamente ciò che si fa su windows.
mi sfugge qualcosa?

31. Rjky - 25/06/08 @ 0:05

Il problema ( e lo dice un utente Gnu/Linux che amministra sistemi da mò ) è che le “distro” non sono sistemi operativi Desktop Oriented come possono essere ad esempio OS X o Windows ( malgrado tutte le loro pecche ). Mi spiego: il file system e la gerarchia delle directory non sono assolutamente adatte, deprecate e troppo complesse ( ma questo problem affligge anche apple ), non esiste una distinzione netta tra software di sistema ( e quindi anche “driver” ovvero i moduli del kernel ) e software in spazio utente ( come i browser o le applicazioni multimediali ), manca completamente uno standard tra le varie distro di una base di librerie presenti “sempre” per far funzionare un programma indipendentemente dal nome della distro stessa e il supporto hardware troppe volte è di qualità scadente ( ma questo, ovviamente, non è una colpa dei distributori, tanto dei produttori di hardware ). La situazione invece è molto più rosea dal lato server, in quanto la semlicità di gestione dei pacchetti è inredibilmente efficace e da un controllo senza pari nell’ordinaria amministrazione dei sistemi, ma non è certamente così intuitivo per un utente gestire una bash ;)

32. gondsman - 25/06/08 @ 0:16

Quoto #30, io prendo in considerazione l’esempio di MATLAB, installato senza problemi su linux con un interfaccia tipo “avanti, accetto, avanti, avanti…”. Secondo me se i produttori volessero si potrebbe adottare questa soluzione senza particolari problemi. Certo, un sistema di installer comune (meglio ancora insieme ad un sistema di directory e librerie comuni) sarebbe meglio, così come il tanto decantato e altrettanto poco usato Klik.

33. aNoNiMo - 25/06/08 @ 0:41

@rjky
secondo me non è quello il problema, lo dimostra che una soluzione come quella che auspicavo nel mio precedente post è usata con successo da diversi software di terze parti (ad esempio matlab come dice gondsman, oppure doom3 che ho provato personalmente… persino skype offre una versione compilata staticamente e che quindi funziona ovunque).
per cui la verità è che il problema non sussiste

34. Don - 25/06/08 @ 1:14

Invece il problema sussiste perchè accumulando librerie uguali, compilate staticamente c’è il rischio che possano creare dei conflitti, cosa impossibile quando per una libreria, c’è solo una serie di file non duplicata in modo sparso.

35. aNoNiMo - 25/06/08 @ 10:08

@don
non vedo come possano creare conflitti, ognuna esiste solo nell’ambito in cui serve e non interferisce con l’esecuzione di altre applicazioni. altrimenti windows non funzionerebbe visto che è pieno di applicazioni che si portano dietro librerie non condivise.

36. pippero - 25/06/08 @ 10:35

perchè, windows funziona?

37. Mercurio - 25/06/08 @ 11:23

Boh, a dire il vero ormai ne sento poco la necessità.

Le distribuzioni si stanno orientando verso tre filoni principali: Fedora/RedHat, OpenSuSE, Ubuntu/Debian. Distribuzioni come Gentoo sarebbero escluse dal discorso per ovvie ragioni.

Penso che un distributore non abbia troppi problemi a fare pacchi e collaudarli per queste tre. Addirittura i distributori potrebbero fare servizi di vendita tramite il tool di gestione pacchetti del sistema: che oltre ad essere una soluzione comodissima per gli utenti, è anche molto più sicura!

Perché dover ispirarsi al modello di Windows che facilita l’installazione di trashware e virus?

Al limite potrebbero preoccuparsi di fornire tool agli sviluppatori per semplificargli la vita.

Io comunque ormai sto installando programmi solo facendoci click da firefox…

38. Don - 25/06/08 @ 12:38

@35

Probabilmente due copie diverse di una stessa libreria fatte funzionare allo stesso tempo, se non sono state scritte con tutti i crismi, finisce che vanno ad inquinarsi i dati a vicenda.
Non è un rischio trascurabile.

@37

Le distribuzioni a grandi linee si orienteranno anche su tre grandi famiglie, ma poi finisce che ognuna fa delle patch sue in maniera completamente indipendente da un’eventuale sorella.
Basta provare a far andare i programmi di debian su ubuntu e viceversa: 2 volte su 3 non vanno quindi i programmatori non si ritroverebbero a testare per tre distribuzioni ma per molte di più.
Se la cosa fosse tanto facile i problemi si sarebbero già risolti da un pezzo.

39. Sniz92 - 25/06/08 @ 13:12

io vedo l’esempio di google earth, di tremolous, di UT2004.
un file .run da eseguire, installer e poi il programma parte.

certo fosse tutto pacchettizzato standard sarebbe meglio, pero’ anche così non è male

40. aNoNiMo - 25/06/08 @ 14:24

@Don
puoi fare un esempio che non capisco cosa intendi dire?
per adesso abbiamo già raccolto un pò di controesempi alla tua affermazione:
matlab, doom3, skype, google earth, UT2004 e tremolous

@Mercurio
perchè c’è differenza tra trashware e closed source :PPPPPPPPP a parte gli scherzi..
sono daccordo che il modello windows non è il migliore, ma per quel che riguarda la distribuzione di software closed source non è che ci siano molte strade:
- o investi un minimo su linux e pacchettizzi per le varie distibuzione
- oppure usi l’approccio windowsiano

41. anonimo - 25/06/08 @ 14:26

Scusate, ma perché non usare Autopackage (www.autopackage.org)? Non me ne intendo molto, ma ho provato ad installare un programma ed è davvero semplice, sembra un installer di Windows.

@felipe
Ma perché il campo nome per scrivere i commenti contiene sempre un nick già usato (non da me)?

42. Luca Cappelletti - 25/06/08 @ 16:13

Sentendomi in qualche modo chiamato in causa…vi invito ad assaggiare qualche succulento SpatialBundle che il vostro dedito cuoco prepara per voi con certosina meticolosità :)
A tal proposito vi invita alla degustazione degli ultimi assaggini presso:
http://downloads.infodomestic.com
dove avrete l’occasione di leccarvi i baffi con pietanze del calibro di Pidgin 2.4.2 o Opera 9.5 o OpenOffice 3 e altro (per i più maliziosi anche un Internet Explorer 6).
Come al solito tutto questo servito e riverito senza porcarvi le mani con concetto stesso di installazione o inserimenti pericolosi di password di root o peggio ancora risoluzione di librerie oltre quelle fornite dall’installazione di base standard.
Sperando di fare sempre cosa gradita con simpatia vi auguro…
buona abbuffata :)
Luca Cappelletti
http://developer.infodomestic.com

43. Luca Cappelletti - 25/06/08 @ 16:15

Sentendomi in qualche modo chiamato in causa…vi invito ad assaggiare qualche succulento SpatialBundle che il vostro dedito cuoco prepara per voi con certosina meticolosità :)
A tal proposito vi invita alla degustazione degli ultimi assaggini presso:
http://downloads.infodomestic.com
dove avrete l’occasione di leccarvi i baffi con pietanze del calibro di Pidgin 2.4.2 o Opera 9.5 o OpenOffice 3 e altro (per i più maliziosi anche un Internet Explorer 6).
Come al solito tutto questo servito e riverito senza porcarvi le mani con concetto stesso di installazione o inserimenti pericolosi di password di root o peggio ancora risoluzione di librerie oltre quelle fornite dall’installazione di base standard.
Sperando di fare sempre cosa gradita con simpatia vi auguro…
buona abbuffata :)
Luca Cappelletti

44. Don - 25/06/08 @ 18:32

@40

Più che esempi si possono fare delle congetture partendo dal fatto che una libreria è sempre un “pezzo” di programma quindi suscettibile a tutti i problemi che si possono incontrare quando si scrive un programma completo.

Studiando lo standard ansi del c si scoprono certi altarini e certe mancanze non da poco, alle quali è spesso il programmatore chiamato a far loro fronte. Basta vedere come vengono gestiti i vettori per capire quanto ci voglia poco per andare ad inquinare celle di memoria estranee a quelle inizialmente previste.
Basta che due versioni diverse di una stessa libreria, proposta in modo statico in due programmi diversi posseggano una il bug in oggetto e l’altra no per ipotizzare degli scenari non proprio piacevoli. Poi per carità, con i pc attuali traboccanti di ram ed i kernel non completamente deficienti (neanche quello di win arriva a tanto), può anche darsi che il rischio sia minimo ma è chiaro che a livello di sicurezza non è proprio il massimo lasciare le cose al caso.

45. MementoMori - 25/06/08 @ 19:12

@40

vettori? intendevi puntatori, vero?
Ram a iosa e kernel intelligenti? questo tipo di bug funziona su tutte le piattaforme che abbiano un compilatore C funzionante.

#include

int main(int argc, char *argv[]){
printf(argv[1]);
return 0;
}

46. MementoMori - 25/06/08 @ 19:14

@44
piccola correzione

ovviamente il file da includere era stdio.h ma wordpress non ha gradito la sintassi ;)

47. aNoNiMo - 25/06/08 @ 19:18

mettiamo che un programma è linkato staticamente a una libreria “non buggata” mentre un altro programma è linkato a una libreria “buggata”.. semplicemente il secondo programma conterrà un bug (quindi sarebbe il caso che gli sviluppatori di questo programma compilino con una libreria più aggiornata), ma non influisce in nessuna maniera con il primo programma perchè le due librerie stanno in due spazi di memoria completamente differenti.
su windows è abbastanza comune avere diverse copie della stessa libreria usate da diversi programmi.
affidarsi al caso sarebbe supporre che la libreria X alla versione Y sia installata nel sistema, mentre se per caso c’è la versione Z vedrai il tuo bel software crashare miseramente.

48. Andrea - 25/06/08 @ 19:34

basterebbe passare tutti ad apt + rpm che è la coppia migliore. Con gli rpm si possono gestire tutte le questioni di dipendenze da librerie varie in maniera molto più furba che con i deb. Con apt il venditore si mette un bel repo e con apt-url installare un pacchetto diventa questione di un click. (bisognerebbe fare un lavoro simile anche per aggiungere un repo).
Poi le distro potrebbero anche accordarsi sui pacchetti base e unificarli in un unico repo.
Altrimenti se vogliamo avere cento sfumature, bisogna supportarle singolarmente.

49. Don - 25/06/08 @ 21:31

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

50. tosky - 25/06/08 @ 21:55

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

51. aNoNiMo - 25/06/08 @ 22:11

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

52. Don - 26/06/08 @ 0:49

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

53. aNoNiMo - 26/06/08 @ 10:13

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

54. jack - 30/06/08 @ 13:33

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

55. Golem - 30/06/08 @ 19:18

l’ipotesi del complotto nel mondo *nix mi mancava

56. Lele - 1/07/08 @ 23:10

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.

57. gitpen - 6/07/08 @ 18:18

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?

58. evamos - 8/07/08 @ 20:28

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

(commentando accetti implicitamente le Regole di pollycoke, leggile!)