LSB 3.2 rende Linux più standard

Linux Foundation ha pubblicato una versione aggiornata della specifica Linux Standard Base, ora comprensiva del supporto ai linguaggi Perl e Python e di un'interfaccia standard per la stampa e l'audio

San Francisco (USA) - Prosegue senza soste il lavoro di Linux Foundation per estendere e rifinire Linux Standard Base (LSB), una specifica tesa a migliorare l'interoperabilità tra le applicazioni e le varie distribuzioni di Linux. La nuova versione 3.2, che arriva a dieci mesi di distanza dall'aggiornamento precedente, introduce un miglior supporto ai linguaggi interpretati e alle funzionalità multimediali e di stampa.

"LSB va incontro alla sempre più sentita esigenza, da parte degli sviluppatori indipendenti di software (ISV), di creare applicazioni portabili per Linux", ha spiegato Jim Zemlin, executive director di Linux Foundation. "Con l'inclusione dei linguaggi interpretati e del supporto a stampa e altre caratteristiche particolarmente richieste, questa release fornisce le funzionalità di cui gli ISV necessitano per fornire applicazioni sempre più sofisticate in un formato portabile e cross-distribution".

LSB comprende un insieme di librerie, API, linee guida e tool che gli sviluppatori possono utilizzare per creare applicazioni in grado di funzionare su tutte le distribuzioni conformi allo standard. Questa specifica è oggi supportata da alcune delle più importanti distribuzioni Linux, tra le quali Red Hat Linux, SUSE Linux, Ubuntu, Xandros, Mandriva e Debian (qui l'elenco completo).
Nello specifico, LSB 3.2 include il supporto ai famosi linguaggi di scripting open source Perl e Python, consentendo agli sviluppatori che programmano in questi linguaggi di scrivere applicazioni capaci di girare sulla stragrande maggioranza delle distribuzioni Linux. Il team di LSB, in collaborazione con l'OpenPrinting Workgroup, ha poi aggiunto alla specifica un'interfaccia per il supporto a driver di stampa multi-distribuzione e multi-piattaforma (si veda a tal proposito questa notizia).

LSB 3.2 integra il supporto sperimentale alle librerie audio ALSA (Advanced Linux Sound Architecture) ed a quelle xdg-utils, sviluppate in seno al Progetto Portland con lo scopo di semplificare l'integrazione delle applicazioni desktop con le interfacce KDE e GNOME. Tale supporto viene considerato da Linux Foundation "un importante primo passo nel rendere possibile la creazione di applicazioni multimediali per Linux cross-distribution".

Tra le altre novità di LSB 3.2 si citano infine l'aggiunta di alcuni componenti standard di freedesktop.org come menù e temi per le icone, il supporto al motore di rendering dei font FreeType, e il supporto a XRender, un'estensione di X Window System che permette di applicare alle finestre effetti di trasparenza e antialiasing.

Linux Foundation prevede che le prime distribuzioni Linux ad implementare la nuova versione di LSB arriveranno verso la fine dell'anno.
116 Commenti alla Notizia LSB 3.2 rende Linux più standard
Ordina
  • ...ed uso Linux dal '93 c.ca eh: come mai se un file, seguendo non tanto uno standard ma proprio un minimo di logica, andrebbe in /etc/pkgname/ c'è sempre il "programmatore duro e puro, figlio di Torvalds" che lo vuol mettere in /cazzimiei/dirchedicoio/quidicertononlotrovi/ eh?

    Ma sarebbe "libertà" quella?

    Più che altro: mettiamo, per amor di discussione, che quella sopra sia libertà (alla fine posso anche dire "ok, lo è"), e penso che Linux attualmente permetta senza troppi problemi di fare cose del genere. Quel che mi lascia un pò esterrefatto è la necessità della cosa.

    Mentre posso anche capire, ma non approvare la ditta (RH, SuSE, MDK, ecc.) che, per proteggere il proprio business, crea delle artificiose differenze (perchè non venite a dirmi che mettere un file in un posto, piuttosto che in un altro, cambia qualcosa eh) in modo da (1) manutenere solo lei i repository delle modifiche, (2) legare a sè i clienti col fatto che, prendendo i pacchetti altrove, questi potrebbero non funzionare... ma quando dico così mi par di sentire puzza di M$ eh: è triste parlarne a proposito di Linux. :/

    Non riesco invece a capire lo sviluppatore indipendente che decide di non "integrare" il suo pacchetto con gli standard esistenti: a meno che non sia un pacchetto di nessuna importanza, credo che maggior distribuzione questo abbia e maggior fortuna possa fare, indipendentemente dal fatto che sia o meno a pagamento.
    La "libertà" del "lo metto dove voglio io" (ed a questo punto lo useranno in 4, dovendo manutenerselo a mano) mi pare più un suicidio che altro.

    Mi spiace che molti sviluppatori (ed esperti di Linux) vedano l'adozione di uno standard come "il male": in fondo quando voi compilate un prodotto, se le librerie fossero "a caxxo", e contenessero funzioni "a caxxo" (per cui il linker vi prende x il cu£0 e rifiuta di compilare) ce l'avreste in quel posto anche voi no?
    Io dico: siamo tutti seduti sulle spalle di "giganti" (chiunque ci abbia preceduto ed abbia lasciato una traccia o, comunque, un tool che oggi usiamo): perchè non vogliamo fare "quel passo in più" e cercare di adeguare un minimo il Nostro Perfetto Prodotto agli standard generali? (es. LSB, che si propone come tale)
    Ma no: la si prende come un'offesa personale. :/

    Di contro: non vi piacciono gli "standard"... ma usate GPL: fatevi una licenza diversa per OGNI prodotto che sviluppate (e difendetela, da soli, in tribunale).
    Non vi piacciono gli standard... ma compilate con GCC: scrivetevi voi il compilatore, che capisca anche statement come "sò caxxi miei" o "for ballrotations from 1 to N rpm do...".

    Dai... discorsi del genere mi fanno veramente pensare alla poca maturità del "popolo di Linux" (e ci son dentro pure io): sono il primo a cui non piace il "punta & clicca a tutti i costi" (i miei client hanno, tutti, l'interfaccia grafica, i miei server non l'hanno mai avuta by default) ed il rendere le cose "facili a tutti i costi": se una cosa è "difficile" è giusto che lo sia.
    Ma renderle "artificiosamente difficili" mi pare un'enorme caxxata, tutto qui... evviva la libertà eh.Occhiolino
    878
  • Ma infatti molti credono che anarchia sia libertà.
    Come gli ingorghi che si formano nelle strade di napoli, nessuno rispetta le "regole" e quindi ci si pianta.
    Dettare due linee guida eviterebbero un sacco di problemi e non minerebbe la libertà di nessuno. Ma nel mondo linux le "linee guida" sono viste come un attentato alla libertà.
    L'unico nemico di linux è la sua stessa comunità.
    non+autenticato
  • Ma guarda... l'anarchia può anche esser bella eh, se fatta cum grano salis (parlo per diretta esperienza personale).
    Quello che continuo a faticare a comprendere è come un "linaro" (io lo sono) possa non volere la massima espansione del "proprio" OS, tutto qui.

    Non è una questione di semplici "religion wars" eh, che lasciano le cose come prima, senza vincitori ma con solo vinti, è proprio una questione di soddisfazione personale: io son contento, ad esempio, pensando che dentro WindowsNT batte un kernel *BSD (e lo si vede nell'uso). Son contento, anche se non me ne viene nulla in tasca, che una marea di macchine grosse, quelle usate nei CED, girino sotto unix E linux: per me significa progresso E significa che la strada intrapresa da Linux è valida... ma che fatica, caxxo.
    Poi... finchè la cosa è confinata nel CED e/o Centro di Ricerca, puoi anche pensare che ci si prenda i sorgenti e li si ricompili da zero, si sviluppino cose da zero ecc. ecc. (magari con le logiche commerciali, non necessariamente in standard, di cui sopra).

    Oramai però Linux è arrivato sui tavoli della gente: non è una questione di "libertà" o meno, è questione di diffusione di una cosa valida che, come dicevi, viene ostacolata proprio dalla comunità (almeno a parole, se non nei fatti: si usa comunque GPL, si usa gcc, PERL, ecc. ecc.).

    Mi metto nei panni della persona che di PC, OS, distro non sa nulla e "vuol comprare il piccì":

    1) da un lato il (falsamente) monolitico Windows (falsamente perchè c'è XP/Home, XP/Pro, Vista, ecc.) dove, con magari piccoli problemi superabili, "più o meno tutto il software gira". Io, che non ne so nulla, so però che IlMioBelGiocoNuovo gira... poi, visto che HO provato l'OS e, tutto sommato, "gira" (evito di dire "come"A bocca aperta) lo adotterò anche nel mio ufficio... e giù quattrini a palate, sempre nella stessa direzione. :/

    2) dall'altro però... uhmmm... il "solito amico che sa tutto" mi ha parlato di Grande Libertà e di "distribuzione"... della prima, non essendo programmatore, non so che farmene, ma della seconda?... cosa sarà?..
    Nessun problema: viene lui a casa ad installarmi tutto (o, peggio, "ti faccio i CiDdì che poi è un gioco, vedrai come ti diverti")... installo una OpenSuSE... cioè... la installa lui.
    Ma ci gira IlMioBelGiocoNuovo?.. no... ohhhhh... "ehhh... è stato pacchettizzato per ubuntudebianmadrivalindosxandros ma non per OpenSuSE"... uff... "mavedraicheinstallandoVINEcedegaSalcaxxoClementinaLoFacciamoAndareEh"... wow... dev'esser questa la libertà... siamo alcuni giorni dopo l'acquisto del macchinino nuovo ed il "meccanico" sta rifilettando i tappi dell'olio "perchè qui non vanno bene"
    Maaaa... ed Excel ci gira? "no, ma c'è OpenOffice cheèanchemeglio" (e qui okOcchiolino)

    Insomma... 'ste cose le so io e le sapete voi, inutile prenderci x il cu£0 ed inutile che continui l'elenco: è tutto un deja vu. Oltre a tutto questo momento dovrebbe essere molto favorevole a "noi" Fan Linux, dato che Vista è quello che è (lol) e tanti winari (scusate il termine) sono parecchio incaxxati con M$... e stanno valutando il "salto della barricata".
    Però... da un lato soffrire, con SP1 bloccato, patch che bloccano il PC e Vista compatibile con nulla... ma che si sta stabilizzando.
    Dall'altro "ich sunt leones": vi pare una condizione, anche se indubbiamente libera, tranquillizzante? :/
    878
  • Già però quale barricata saltano ? Quella di linux o quella di Apple ?
    Ed in futuro quando Haiku sarà pronto (che a differenza di linux fin da adesso spinge per una standarizzazione, c'è proprio una pagina sul sito ufficiale dedicata, semplice e chiara da capire) attirando molto più facilmente gli sviluppatori a dispetto di linux ?
    non+autenticato
  • - Scritto da: Overture
    > Già però quale barricata saltano ? Quella di
    > linux o quella di Apple
    > ?
    > Ed in futuro quando Haiku sarà pronto (che a
    > differenza di linux fin da adesso spinge per una
    > standarizzazione, c'è proprio una pagina sul sito
    > ufficiale dedicata, semplice e chiara da capire)
    > attirand molto più facilmente gli sviluppatori a
    > dispetto di linux ?

    Cioe' stai dicendo che c'e' piu' gente che sviluppa su Haiku che su linux ?
    Mi dai del link a prova di cio ?
    krane
    22544
  • - Scritto da: Sky

    > Mi spiace che molti sviluppatori (ed esperti di
    > Linux) vedano l'adozione di uno standard come "il
    > male":

    A si ? Capita ?
    Io non ho sentito cose del genere, mi dai qualche link a discussioni serie a riguardo ?
    krane
    22544
  • Googla tu stesso: sono anni che in LUGBS prendo carciofi (tant'è che m'è passata la voglia di parlarne) a proposito di LSB.
    878
  • - Scritto da: Sky
    > "programmatore duro e puro, figlio di Torvalds"

    Che vuol dire?

    > Ma sarebbe "libertà" quella?

    Sì.

    > penso che Linux
    > attualmente permetta senza troppi problemi
    > di fare cose del genere.

    Non è Linux che lo permette, ma la libertà garantita dalla GPL. Puoi fare quel che ti pare. Come sei libero di scegliere di usare o meno quel che ti pare. Dov'è il problema?

    > non venite a
    > dirmi che mettere un file in un posto, piuttosto
    > che in un altro, cambia qualcosa

    Dipende dal file. E dipende dal posto.

    > (1) manutenere solo lei i repository delle
    > modifiche, (2) legare a sè i clienti col fatto
    > che, prendendo i pacchetti altrove, questi
    > potrebbero non funzionare...

    Assurdi entrambi gli scenari. Sarebbe un danno per ogni azienda che decidesse di comportarsi così. Parliamo di software libero, e la licenza garantisce tutti.

    > Non riesco invece a capire lo sviluppatore
    > indipendente che decide di non "integrare"
    > il suo pacchetto con gli standard esistenti

    Avrà avuto i suoi motivi. Puoi chiedere direttamente al team di sviluppo della distribuzione di cui non comprendi le scelte: ti risponderanno esaurientemente.

    > maggior distribuzione
    > questo abbia e maggior fortuna possa fare,

    Di solito chi crea e mantiene una distribuzione lo fa non per aver 'fortuna', ma perché pensa che sia la strada giusta.

    > La "libertà" del "lo metto dove voglio io" (ed a
    > questo punto lo useranno in 4, dovendo
    > manutenerselo a mano) mi pare più un suicidio che altro.

    A te quale danno comporta?

    > Mi spiace che molti sviluppatori (ed esperti di
    > Linux) vedano l'adozione di uno standard come "il
    > male"

    Chi? A me non sembra che sia così. Al massimo si sceglie di non adottarlo. Liberamente.

    > in fondo quando voi compilate un prodotto,
    > se le librerie fossero "a caxxo", e contenessero
    > funzioni "a caxxo" (per cui il linker vi prende x
    > il cu£0 e rifiuta di compilare) ce l'avreste in
    > quel posto anche voi no?

    Al di là dell'eloquio non proprio elegante, ti faccio notare che le librerie fondamentali sono le stesse su ogni distribuzione. E sono sviluppate secondo linee guida precise e conosciute, tra cui spicca una notevole retrocompatibilità. Inoltre sono sempre disponibili le versioni precedenti. Quindi lo scenario da te finemente destritto è semplicemente irrealistico.

    > perchè non vogliamo fare "quel
    > passo in più" e cercare di adeguare un
    > minimo
    il Nostro Perfetto Prodotto agli
    > standard generali?

    Chi ha detto che non vuole?

    > Di contro: non vi piacciono gli "standard"...

    A qualcuno può non piacere UNO standard. Magari apprezzando tutti gli altri.

    > usate GPL: fatevi una licenza diversa per OGNI
    > prodotto che sviluppate (e difendetela, da soli,
    > in tribunale).

    Perché?

    > compilate con GCC: scrivetevi voi il compilatore

    Perché?

    > Dai... discorsi del genere mi fanno veramente
    > pensare alla poca maturità del "popolo di Linux"

    Parli dei tuoi discorsi? Perché non è che appaiano 'maturi' ed argomentati...

    > sono il primo a cui non piace il "punta & clicca a
    > tutti i costi"

    E allora?

    > ed il rendere le cose "facili a tutti i costi":
    > se una cosa è "difficile" è giusto che lo sia.

    Ma anche no...
  • Ahahahahahahahahaha...
    878
  • - Scritto da: Sky
    > Ahahahahahahahahaha...

    Non mi sembra una risposta convincente.
    Nemmeno educata.
  • mi sono adeguatoOcchiolino
    878
  • mi sembra strano sia incluso solo ora nelle specifiche LSB, in fondo il Perl è sempre stato utilizzato nel mondo Uni*/Linux...
    non+autenticato
  • Infatti, aggiungete il perlo solo quando è quasi morto mi raccomando.
    non+autenticato
  • - Scritto da: Garixi
    > Infatti, aggiungete il perlo solo quando è quasi
    > morto mi
    > raccomando.

    Non è affatto quasi morto.
    Anzi viene usato ancora un bel po'.
  • purtroppo (?)
    si purtroppo !!!
    non+autenticato
  • - Scritto da: rtfm
    > purtroppo (?)
    > si purtroppo !!!

    Perché purtroppo?

    E' un linguaggio molto potente e versatile, da noi lo usiamo
    per un sacco di cose (sia script per attività sistemistiche che una collezione di librerie per la creazione di Web Application).

    Certo, non è adatto a tutti, ma per chi lo sa usare bene è un ottimo strumento.
  • ho provato anch'io ad usarlo all'inizio.
    grazie a dio sono passato a python. Ogni volta che dovevo mettere mano nel codice di qualcuno o anche al MIO mi veniva da dare testate al muro.
    conosco solo java,c,c++,assembler,perl,python,php,pascal e tra questi solo l'assembler è meno leggibile IMHO.
    è vero anni fa le librerie che aveva il perl tutti gli altri se le scordavano, ma è da un bel pezzo che non è più così.

    salut
    non+autenticato
  • - Scritto da: tizio
    > ho provato anch'io ad usarlo all'inizio.
    > grazie a dio sono passato a python. Ogni volta
    > che dovevo mettere mano nel codice di qualcuno o
    > anche al MIO mi veniva da dare testate al
    > muro.

    Eh eh, ti posso capire.
    Il Perl lascia una libertà estrema (anche troppa) e questo può (e sottolineo "può") portare a codice molto criptico.
    Ma basta un minimo di pratica per scrivere codice leggibile.

    > conosco solo
    > java,c,c++,assembler,perl,python,php,pascal e tra
    > questi solo l'assembler è meno leggibile
    > IMHO.

    A parte l'assembler, tutti gli altri hanno regole abbastanza rigide che impediscono certe cose che invece il Perl lascia fare. Ma questo è un punto debole solo per chi non lo sa "masticare" bene.

    Dal lato opposto c'è Java che ti obbliga a scrivere quintali di righe di codice inutili solo per motivi formali .

    Ho delle librerie che utilizzo per applicazioni web: la stessa versione l'ho dovuta fare in Perl e in Java (per certi progetti sono obbligato a usare Java) e non c'è paragone la versione in Perl è estremamente più leggera.

    > è vero anni fa le librerie che aveva il perl
    > tutti gli altri se le scordavano, ma è da un bel
    > pezzo che non è più così.

    CPAN rimane sempre il punto di forza (senza di lui, il Perl sarebbe ben poca cosa). Ma è ben vivo e vegeto.
  • - Scritto da: tizio
    > conosco solo
    > java,c,c++,assembler,perl,python,php,pascal e tra
    > questi solo l'assembler è meno leggibile
    > IMHO.

    certo che se conosci italiano spagnolo francese il tedesco ti sembrera' meno leggibile ad es. del portoghese!
    il problema e' che Perl e' un po' un altra cosa, piu' vicina a linguaggi come il lisp, piu' ostici ma una volta entrati nella loro logica (perversa?) potentissimi ad esempio nella gestione di stringhe, liste etc...
  • - Scritto da: LeoLinux
    > - Scritto da: tizio
    > > conosco solo
    > > java,c,c++,assembler,perl,python,php,pascal e
    > tra
    > > questi solo l'assembler è meno leggibile
    > > IMHO.
    >
    > certo che se conosci italiano spagnolo francese
    > il tedesco ti sembrera' meno leggibile ad es. del
    > portoghese!
    > il problema e' che Perl e' un po' un altra cosa,
    > piu' vicina a linguaggi come il lisp, piu' ostici
    > ma una volta entrati nella loro logica
    > (perversa?) potentissimi ad esempio nella
    > gestione di stringhe, liste
    > etc...

    hmmm

    ricorda che mi sono cimentato prima col perl e poi visto le sue manchevolezze (ai mie occhi) ,che non ripeto, sono passato a python.
    Comunque il tuo discorso si può facilmente ribaltare.
    un latino (nel senso di lingua latina) madre lingua troverà molto più facile esprimersi in latino che in inglese, italiano... questo non significa che il latino non sia superato e obbiettivamente più ostico da imparare.
    morale (IMHO) : se sei (tu sviluppatore generico) molto bravo col perl (io non lo sono) continua pure non morirà certo domani, ma se hai tempo e curiosità dai un occhiata alle alternative. Se invece ti affacci al mondo della programmazione script: be stanne alla larga se puoi.
    non+autenticato
  • Tu non sai di cosa farnetichi!

    Il Perl è l'unico linguaggio dove con poche righe di codice ti fai dei processori di testo che ti scovano qualsiasi cosa tu voglia dall'output di un servizio SNMP.

    Tutti i motori di diagnostica e monitoring per una miriade di dispositivi, sistemi operativi e servizi sono fatti in Perl.
  • 2008: supporto audio standard per Linux!

    </flame on>
    ... peccato che andava fatto nel 1988... Newbie, inesperto
    </flame off>
    non+autenticato
  • leggi meglio!
    supporto sperimentale.
    Non ci sono ancora arrivati al definitivo.
    Vedrai che lo faranno nel 2009 ovvero l'anno di linux!
  • Tanto per capirci LSB 'e praticamente solo uno standard di _dove_ mettere librerie, programmi e componenti.

    ad esempio:
    directory "/bin", qui ci vanno tutti i programmi necessari all'avvio, LSB indica _quali_ sono considerati tali e debbano trovarsi qui.

    La qualita del supporto audio in Linux non ha assolutamente _niente_ a che vedere con quanto sia sperimentale il suo supporto in LSB.

    Per avere un _ottimo_ (cioe'di livello professionale) supporto audio basta usare la libreria "Jack" oppure "Pulseaudio" oppure googla a piacere.
    non+autenticato
  • Mizzeca... hanno letto il vecchio documento relativo allo hierarchical file system e gli hanno cambiato nome... sempre migliori...
    non+autenticato
  • complimenti, ti scrivo per la prima volta, ti seguo da sempre.
    non+autenticato
  • ahem. ahem. ALSA funziona, non è sperimentale il supporto audio; ma la definizione del LSB; inoltre con il mio vecchio portatile i drivers win32 forzavano i 2 canali, nonostante il portatile stesso avesse una scheda 5.1; indovina come ho fatto a far funzionare i 5.1 canali propri di quella scheda.

    Ma dopotutto il supporto audio in linux è sperimentale, per questo JACK viene utilizzato a livello professionale per l'applicazione di filtri audio, il mixaggio e la registrazione in realtime; per questo PulseAudio è considerato uno dei server sonori più avanzati in circolazione, ai livelli di CoreAudio della Apple.

    Informati la prossima volta, sempre se non vuoi fare brutte figure.
  • > Informati la prossima volta, sempre se non vuoi
    > fare brutte figure.

    Guarda che ha fatto un abbonamento alle figuracce (vedi topic sulle patch ritirate da MS per Vista) e le deve in qualche modo smaltire. Io spero sempre che al termine del carnet di cavolate che puntualmente spara il suo unico neurone si riprenda un attimo.
    non+autenticato
  • se rispondi a un topic in cui ha postato anche Renji Abarai potresti essere considerato un trollSorride non parlare con gli gnomi.
    non+autenticato
  • - Scritto da: Renji Abarai
    > leggi meglio!
    > supporto sperimentale.
    > Non ci sono ancora arrivati al definitivo.
    > Vedrai che lo faranno nel 2009 ovvero l'anno di linux!

    Non può essere vero.
    Tu fingi di essere così ignorante, non puoi dire seriamente cose del genere... oppure non hai mai visto un computer nemmeno da lontano!
  • Rotola dal ridereRotola dal ridereRotola dal ridere

    Beh dai da quando c'è ALSA problemi non en ho ami avuti...



    Fan Atari
  • - Scritto da: Ciccio
    > 2008: supporto audio standard per Linux!
    >
    > </flame on>
    > ... peccato che andava fatto nel 1988... Newbie, inesperto
    > </flame off>

    ahahha ma quale flame, si chiama puttanata
    non+autenticato
  • ...pochi i partecipanti rispetto la totalità delle distribuzioni esistenti, quando parlano di standard e quindi si suppone che un programma fatto su una distribuzione, si installi e giri in maniera presso che perfetta qualcuno mi spieghi questa cosa:

    Direttamente dalla lista:

    Red Hat Enterprise Linux Version 5
    Mandriva Linux 2007.0
    SUSE LINUX Enterprise 10

    Se tanto mi dà tanto un programma fatto su RHEL dovrebbe essere pienamente compatibile nella sua forma binaria su Mandriva come su SLE10

    Allora perchè vado qua http://www.virtualbox.org/wiki/Downloads e vedo che per ogni distribuzione c'è il pacchetto fatto su misura che mi può far supporre che le differenze non si limitano al pacchetto in se ma anche ad eventuali adattamenti interni.
    2 Note di colore interessanti, non solo c'è un pacchetto diverso per ogni distribuzione ma anche per ogni sottoversione di una stessa distribuzione. Seconda nota curiosa: se l'ultimo pacchetto disponibile è "All distributions" allora cosa li hanno messi a fare quelli personalizzati sopra ?

    Qualcosa non mi torna... o LSB è uno standard all'acqua di rose, ovvero non standarizza una benemerita mazza o a dispetto dei "bollini" che rilascia non viene rispettato seriamente (probabilmente viene visto come un'alternativa e non come la via necessariamente da seguire)
    non+autenticato
  • Credo che LSB stia facendo un lavoro egregio, tuttavia devi vederlo nell'ottica della certificazione "equivalente" Unix.
    Non tutti i sistemi *nix hanno la certificazione Unix, ma questo non vuol dire che non siano ad esso compatibili.

    Questo si riflette anche nella LSB, se guardi tutte le distro certificate o in via di certificazione hanno dietro aziende che le supoprtano (più o meno direttamente). Una organizzazione no-profit non credo senta la necessità (ahimé!) di certificare la propria distro.

    Ad ogni modo, i pacchetti sono in forma diversa perchè sebbene ci sia un formato di pacchetto "unico" stabilito dalla LSB (che è rpm), molte distro sono compatibili con esso, ma non lo adottano come principale (es: Debian).

    Non farti ingannare però, la compatibilità tra le distro LSB e non LSB è comunque molto alta, cambia il fatto che non è "certificata".
    Ad esempio i driver Ati e Nvidia sono certificati per funzionare su RHEL e Suse, quindi sei sicuro che vadano su altre distro LSB-compliant. Tuttavia va anche su una distro non certificata senza grandi problemi.

    Spero di non aver fatto confusione, se c'è da correggere pregoOcchiolino

    Saluti!



    Fan Atari
  • Non mi piace molto come cosa.

    Sul sito di virtualbox non dovrei trovare quella lista di pacchetti ma qualcosa tipo "pacchetto per linux certificati lsb" e pacchetti vari per tutte le altre (che ovviamente non saranno tutte accontentate e più facilmente si finirà alla solita tarball di sorgenti).
    Per conoscere la compatibilità, dal canto mio dovrei semplicemente cercare la mia distro dentro la lista del sito ufficiale o semplicemente trovare un logo specifico dentro una schermata di about.

    Quando si dice che più cose seguono uno standard vuol dire che "possono scambiarsi i pezzi", nel caso di sistemi operativi diversi (inutile prenderci per il naso, attualmente le varie distribuzioni fanno praticamente di tutto per non avere una vera parentela tra di loro, anche se a livello di facciata dicono cose diverse) questi "pezzi" dovrebbero essere i programmi.

    Un LSB tipo "certificazione alla unix" non serve ad un bel niente, basta vedere come solo adesso puntino a supportare sperimentalmente alsa...
    Una "certificazione alla unix" dovrebbe dire in anticipo quello che le distribuzioni dovrebbero fare per essere accettate e non accettare cose che sono già standard di fatto.

    MacOsX ha dovuto fare delle modifiche per essere accettato entro il clan degli os unix, non è stato quest'ultimo ad adattarsi a macosx
    non+autenticato
  • Si quello che intendevo è che non tutti gli Unix sono certificati, ma comunque moltissimi programi girano.

    Il fatto che trovi diversi pacchetti ha tre motivi:

    1- Una distro per essere LSB compliant deve SUPPORTARE RPM, ma non deve averlo come metodo rpedefinito (esempio: Debian) anche attraversi "traduttori" di pacchetti. In Debian e derivate puoi installare pacchetti rpm grazie a un meccanismo di "traduzione" per dirla alla buona

    2- LSB esiste da poco, per cui molti produttori ancora forniscono i paccchetti differenziati da distro a distro

    3- Esistono pacchetti diversi perchè (credo) non tutte le distro hanno le dipendenze richieste inserite di default.

    Insomma vedi LSB come una base dalla quale partire, dei requisiti minimi. Poi ogni distro può metterci tutte le cose in più che vuole.

    Come MacOS ha dovuto cambiare per entrare nella famiglia Unix, così anche una distro come Gentoo dovrebbe cambiare motle cose per essere LSB... Tuttavia non è detto che un pacchetto per red hat non giri su gentoo.

    So che non è una grande cosa dal punto delle aziende, ma qualcosa si sta facendo per standardizzare, e seppur minima, per me può essere utile e interessante vedere quando LSB standardizzerà buona parte del SOOcchiolino

    Non sono contro LSB, anzi, spero che le distro si allineino alle direttive, questo non può fare altro che beneSorride

    Saluti!



    Fan Atari
  • A me sembra che lsb esista da parecchio tempo e che fondamentalmente non venga spinto come sarebbe necessario (una cosa, stupida ma, utile sarebbe la fabbricazione di un bollino "compatibile con..." come microsoft fa praticamente dal 95 e anche prima).

    Sembra una cretinata ma piazza il bollino sui computer (ci trovi perfino quelli dei fabbricanti di dissipatori), piazza il bollino sulle scatole di software e hardware e vedi come dopo linux prende una spinta.

    Il fumo in genere fa male, ma a volte a piccole dosi allarga gli orizzonti
    non+autenticato
  • L'idea del "bollino" può essere molto buona, su alcune scatole di hardware ci sta già segnalata la compatibilità con RHEL o Suse perlopiù...

    Purtroppo come dici anche tu, LSB è sottovalutata spesso dalle distro, vuoi anche perchè non tutte hanno dietro un'azienda che spinge per vendere...

    Fan Atari
  • Credevo che red hat vendesse assistenza. Il fatto che esista cent os mi porta a confermare questa ipotesi.
    Red Hat non dovrebbe vendere assistenza o in realtà proprio su queste incompatibilità un po' vere, un po' false e spesso plateali è stato costruito un business da morti di fame (red hat non vale 1/30 di microsoft e novell finchè le girava netware se ne strafregava di linux) ?
    non+autenticato
  • - Scritto da: Overture
    > Credevo che red hat vendesse assistenza. Il fatto
    > che esista cent os mi porta a confermare questa
    > ipotesi.
    > Red Hat non dovrebbe vendere assistenza o in
    > realtà proprio su queste incompatibilità un po'
    > vere, un po' false e spesso plateali è stato
    > costruito un business da morti di fame (red hat
    > non vale 1/30 di microsoft e novell finchè le
    > girava netware se ne strafregava di linux)
    > ?

    No io intendevo dire che distro come Mint o come Gentoo o come Slakware non hanno dietro un'azienda a cui interessa la diffusione della distro per guadagnarci, quindi prendono LSB sottogamba.

    Per rispondere a quello che hai scritto, Red hat vende assisitenza, però considera che sui problemi hardware e mancanza drivers può fare ben poco. Il maggiore introito di Red Hat è l'assistenza e la personalizzazione di pacchetti non tanto sull'hardware. Certo, poi finanzia gli sviluppatori di driver open, ma in mancanza di specifiche anche li è dura creare driver dal nulla.

    Inoltre spesso Red Hat guadagna sui servizi ad aziende che usano software terzi. Esempio software di grafica certificati per RHEL che vengono acquistati da un'azienda che sicuramente vorrà premunirsi contro possibili problemi e sottoscrive l'assistenza con red hat (un po come fa a cnhe con Microsoft).

    Sulle incompatibilità RH e Novell credo non guadagnino di certo, proprio perchè è una discrimanante verso l'adozione di linuz.
    Paradossalmente anche l'esistenza del clone CentOS gioca a favore di Red Hat...
  • Ok mettiamo da parte le distro come slackware ma perchè esistono pacchetti diversi per mandriva, red hat e suse se tutte e tre puntano al mercato e tutte e tre si dichiarano compatibili con lsb ?
    non+autenticato
  • Non è che si dichiarano, SONO compatibili.
    Questo perchè tutte e tre rispettano lo "standard" di LSB. Un pacchetto rpm può essere installato su Suse. Poi che nessuno lo faccia e tutti preferiscono usare il gestore pacchetti di Suse è un altro discorso.

    Idem per le funzionalità delle librerie. Tutte le distr LSB rispondono alle richieste sulle librerie dello standard.

    Non capisco se il problema per te è che ci siano tanti pacchetti differenti o se sia altro.
    Io installo quasi sempre da sorgenti e problemi non ne ho avuti finora, non creiamone dove non ce ne sono...
  • - Scritto da: AtariLover
    > Il fatto che trovi diversi pacchetti ha tre
    > motivi:

    Io aggiungerei il motivo fondamentale. Ogni singolo utilizzatore ha il pieno diritto di modificare l'intero SO come preferisce. Anche rendendolo incompatibile.
    Fa parte delle libertà garantite dalla licenza.

    Secondo me il discorso va rovesciato. La creazione di uno standard è necessariamente rivolto alle distribuzioni 'mainstream' sviluppate da aziende specializzate. E' però solo una possibilità di scelta in più per chi sviluppa tutte le altre distribuzioni.

    Detto questo, è comunque (ovviamente) un progetto molto positivo.

    Il paragone con OSX non ha senso, dal momento che si tratta di un SO sviluppato da una unica azienda per computers 'fatti in casa'. Il modello di sviluppo è del tutto opposto.