Lennart Poettering, il creatore di systemd, ha dedicato parte del suo tempo a portare la documentazione di Fedora su FreeDesktop: il motivo è il merging del sistema in /usr. Approntato da Harald Hoyer e Kay Sievers, esordirà con Fedora 17. È un cambiamento sostanziale della gerarchia dei percorsi di sistema in linea con Solaris 11.
In sintesi, le cartelle /bin, /lib e /sbin di Fedora 17 saranno installate in /usr e sostituite da link simbolici. È una transizione iniziata da Oracle quindici anni fa e seguita finora da tutte le distribuzioni di Linux. Fedora 17 completerà questo spostamento, com’è avvenuto col rilascio di Solaris 11. Le motivazioni sono diverse.
La modifica è legata soprattutto all’init di sistema, ovvero – nel caso di Fedora – a systemd. Poiché esiste già il bisogno di montare /usr da initramfs, lo spostamento dei componenti fondamentali è una scelta razionale: il primo beneficio è nella possibilità d’effettuare degli snapshot dell’intero sistema, montato in sola-lettura.
Lavorando con soluzioni di rete, lo spostamento riduce la tempistica di replicazione della gerarchia per tutte le macchine da gestire e migliora la virtualizzazione. Restano nella medesima posizione, invece, quei file che non potrebbero essere condivisi sul network: nello specifico, si tratta delle cartelle /etc, /run, /tmp e /var.
Uno degli obiettivi di Hoyer e Sievers è la possibilità di passare alla nuova struttura gerarchica senza necessariamente installare un sistema ex novo. È in fase d’elaborazione uno script che permetta di spostare i percorsi esistenti, prima di ricompilare i componenti essenziali: un espediente molto utile con le altre distribuzioni.
Sebbene la scelta d’emulare la gerarchia di Solaris 11 sia, al momento, limitata a Fedora 17… il merging del sistema in /usr potrebbe essere ripreso quanto prima da altre distribuzioni. Sopratutto quelle che implementeranno systemd, da openSUSE a Gentoo (che dovrebbe sostituire OpenRC). Nei pacchetti il cambiamento influirà su RPM.
Via | Lennart Poettering
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, chi siamo
© 2004-2011 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
ekerazha
27 gen 2012 - 11:20 - #1Questa frase non mi convinceva e sono andato a leggere l’articolo originale… in realtà Fedora sembrerebbe la prima distribuzione a farlo e come “precedenti” si cita solamente Solaris (poi ci sarebbe il caso a parte di GoboLinux che ha completamente modificato la struttura delle directory).
Comunque grande Fedora, per l’ennesima volta all’avanguardia nelle innovazioni.
ekerazha
27 gen 2012 - 11:23 - #2Tra l’altro il paragrafo finale contraddice (giustamente) la parte dell’articolo che ho menzionato precedentemente…
bah blah
27 gen 2012 - 12:23 - #3Mi sembra una pessima idea.
Sotto /usr c’è anche /usr/local, che appunto è locale.
Semmai bisognerebbe cambiare nome a /usr e riorganizzare tutto il FHS.
Questa dei link simbolici mi sembra solo un’idea per fare del casino nel file system invece che proporre un aggiornamento organico e soprattutto sensato.
Kim Allamandola
27 gen 2012 - 13:55 - #4Questa mossa è l’ennesima idiozia il cui scopo od effetto primario è quello
di allontanare le distro non RedHat-centriche da Red Hat sempre nell’ottica
del cosiddetto GnomeOS.
Quanto a Solaris scusatemi ma non mi risulta, lo uso dalla 9 4/06, ora ho
Nexenta come server ed ho usato Indiana come desktop di default sino a luglio
2010…
In generale l’fhs era stato concepito in tempi in cui le live non c’erano
quindi era importante per eventuali recovery avere i binari essenziali al
sicuro rispetto alla “massa” del sistema dove era più facile avere casini,
oggi questo non ha più senso ma non ha neppure senso /usr come non ha senso
/usr/local.
Per i software di terze parti IllumOS [1] usa molto /opt che GNU per ignoti
motivi ignora, mentre /usr/local anziché usato per cose da non esportare via
NFS viene usato da GNU per il software di terze parti…
Solo una cosa: da *anni* GNU/Linux ha scelto di usare /home anziché i classici
unix /export/home (Solaris) od /usr/home (*BSD) perché è più semplice, comodo
intuitivo ecc perché non fare la stessa cosa abolendo /usr/local? Perché non
unificare /proc e /sys e dedicare /sys al software minimale di sistema se lo
volete separare… Altra piccola cosa IllumOS usa lo zfs, il sistema si trova
in un volume zfs es: rpool/ROOT-$VersOS-$UpdateNum quindi non ha problemi di
mount ed è molto semplice fare cloni e snapshot dell’OS sia per gli update che
per i test personali, questa mossa invece va in direzione del solito macello
di volumi/partizioni classico…
[1]
ovvero Solaris, ma dopo le mosse di Oracle giacché Solaris è roba sua
non lo considero nemmeno e mi rivolgo ad IllumOS!
mdales68
27 gen 2012 - 14:11 - #5ma ad un utente normale … che cosa può importare? insomma, al 99,99% degli utilizzatori non cambia assolutamente nulla … piuttosto, possibile che nel 2012 abbiamo ancora bisogno di un filesystem siffatto? parlo da programmatore, ma come i sistemi mobile (IOS in primis) “virtualizzano” il file system, beh francamente mi sembra una strada da seguire.
Kim Allamandola
27 gen 2012 - 15:02 - #6@mdales68 #5
lo stravolgimento del concetto di filesytem l’ha iniziato lo zfs, peccato che
su GNU/Linux i signori esperti (che per carità lo sono anche, meno dei Sun-guy
ma cmq assolutamente tecnicamente preparati) abbian deciso che ’sta cosa l’è
una stranezza che non li interessa…
Lo zfs colla sua “rampant layer violation” fa si che l’accesso a dati salvati
su disco tramite filesystem sia solo uno dei tanti layer di accesso ai dati,
al momento c’è solo l’accesso raw e lo zpl (zfs posix layer ovvero il classico
fs) ma si possono scrivere e si sarebbe fatto se non fosse arrivato Oracle,
layer come db NoSQL, ovvero volumi dove le singole applicazioni posso avere
una forma di persistenza dei loro dati via accessi tipo pickle…
Questo però prevede un cambio del modo di pensare e taglia totalmente eventuali
concorrenti-amici (pensa alle richieste di NetApp di *nascondere* lo zfs per
evitare che loro non riuscissero a vendere le loro soluzioni di storage!) cosa
che fa paura… Così alcune aziende ed alcuni sviluppatori vista la spinta al
cambiamento si buttano a pesce su assurdità nella speranza che il trend che li
vede messi via via all’angolo vada avanti…
mavalaaa
27 gen 2012 - 16:25 - #7ma di che ti preoccupi allamandola? quel che succede su fedora non ti tocca. oltre tutto qui gnomeos c’entra come i cavoli a merenda. va a trollare su PI va…
bah blah
27 gen 2012 - 16:36 - #8@mdales68
Stai scherzando vero? Al 99% degli utenti interessa! Se usi GNU/Linux è per avere il controllo del sistema, quindi prima o poi sbatterei la testa su questi aspetti.
Non ha senso fare cambiamenti a caso come sta facendo Fedora.
Va riformato il File Hierarchy Standard in maniera più moderna piuttosto.
@Kim Allamandola
Stravolgere il concetto di file e di accesso ai dati non mi sembra affatto positivo.
Piuttosto bisogna lavorare a livello di applicazione per gestire i dati tramite database (es. configurazione dei programmi tramite SQLite invece che tanti file).
A livello di File System basterebbe riorganizzare in maniera più organica, ad esempio unendo /proc e /sys, mettendo /var/run sotto /run, la home di root in /home/root, tutte le librerie in /lib, e non /lib e /usr/lib e così via.
/usr dovrebbe sparire, non contenere tutto!
Binary Emotions
27 gen 2012 - 18:50 - #9Completamente d’accordo.
Come spiego nel mio blog (con tanto di lista delle cartelle del FHS in estremo dettaglio), le caratteristiche della suddivisione originale si perdono davvero in tante sottigliezze (logiche per carità), ma rendono la vita difficile a chi (programmatori), alla fine della fiera, poi va a creare link simbolici a manetta al fine di rispettare tali “vincoli”.
Ed agli utenti finali - financo i sysadmin dei web server - non interessa pressoché nulla.
Kim Allamandola
27 gen 2012 - 20:42 - #10@mavalaaa #7
Sei mica Ivan Ortega? Perché mi sa che non sai di cosa stai parlando…
@bah blah #8
Non intendo stravolgere il layout fhs (che già da anni riceve delle piccole
modifiche da parte di ogni *nix) ma cambiare il modo in cui le singole
applicazioni gestiscono i dati persistenti.
Mi spiego altrimenti: se usi un qualsiasi gestore di foto e musica sai che
questo si “organizza” in un suo db interno i file che presente e in più ti
permette di organizzare foto/audio al suo interno in maniera scollegata coi
file su disco (puoi “taggare”, raggruppare in vario modo audio e foto senza
che queste vengano mosse fisicamente o linkate sul fs), questo genera un po’
di confusione. In altro ambito abbiamo applicazioni come i browser che si
salvano una cache su disco e cercano di gestirla nella maniera più veloce
possibile per recuperare i dati, i programmatori devono giocarsela col fs
anziché usare strutture dati native ecc. Quel che propongo e che lo zfs ha
iniziato a fare è quel che vedi con fuse-sshfs e simili, far si che il fs
sia solo un _layer_di_presentazione_ dei dati non il modo in cui questi sono
fisicamente gestiti su disco.
Ad esempio i pkg non sono più archivi di file che vengono estratti con un po’
di script ausiliari (pre-install, post-install, pre-remove, post-remove ecc)
ma volumetti a se la cui presentazione nel layer fs è gestita dal sistema non
dal packager a priori, entro certi limiti, IPS va in questa direzione sia pur
a livello molto embrionale.
Ed ancora quando salvi dei file puoi salvare i metadati in una struttura ed i
dati in un’altra facendo si che i blocchi dati contenenti metadati siano messi
come se fossero indicizzati per la ricerca mentre i blocchi dati puri sono
organizzati in catene di inode per i fatti loro.
Tutto questo che a molti linuxari pare fantascienza è quello che lo zfs ha
iniziato a implementare, solo come esempio ti cito alcuni nella ml di btrfs
che han scritto che la deduplicazione on-line “è un casino”, “ha un’overhead
tremenda” e “non serve a nulla” quando lo zfs la ha da un bel po’ e non solo
è quasi impercettibile in termini di overhead ma a seconda dei dati che salvi
fa risparmiare un’esagerazione di spazio. Questo è uno dei limiti di una
parte della community che pur molto competente ha un bel po’ di paraocchi e
non riesce a pensare liberamente. Non che questo sia facile ma la Sun ha
dimostrato con OpenSolaris dallo zfs a dtrace alle zones all’smf all’fma ha
dimostrato che è *possibile* e non fantascienza. Pensa a cosa ti dice il
linuxaro medio se gli proponi di sostituire a caldo ram e cpu, su Solaris è
possibile, su Linux è fantascienza, però entrambi sono os scritti da uomini
con gli stessi linguaggi di programmazione, sistemi di controllo versione
simili ecc.
Ti boccio solo /home/root, talvolta vuoi andare in single-user e in genere
in tale runlevel non hai /home montata quindi senza /root non puoi loggarti…
È anche per inconsistenze giustificate come queste che lodo l’idea di avere
il fs solo come “uno dei tanti modi di maneggiare i dati” piuttosto che
l’unico…
@Binary Emotions #9
Ho letto il post sul tuo blog e non sono daccordo. Da un pezzo su GNU/Linux
i software di terze parti vanno in /usr quindi a nessun developer che non
scriva software core come shell varie, tar/pax/*, ls&c si cura di altro che
non sia sotto /usr, idem chi sviluppa shell e binari di base _non_si_cura_ di
/usr. Quindi la struttura attuale di /usr non rompe a nessun sviluppatore.
Semmai rompe (ed infatti molti big non la seguono) il fatto che GNU usi
/usr/local al posto di /opt; ad esempio Google installa chrome&c in
/opt/google e persino Ubuntu per il repo extras usa /opt. Di questo però
Fedora/RH non si occupa, è già “diverso dagli altri” e quindi va bene per il
loro Gnome-NuovoITS-OS (ITS del MIT, il sistema Incompatibile con tutti).
0xdeadbeef
27 gen 2012 - 20:46 - #11Rendersi conto di essere sulla stessa lunghezza d’onda della propria distro preferita è ogni volta una soddisfazione ;)
Si badi che /usr non conterrà tutto, ma solo i programmi e i loro dati, il che ha una sua logica. Non vedo il problema per /usr/local, come non vedo l’utilità di ritirare fuori il vecchio /opt, sempre stato fine a sé stesso. Si noti anche che per F18 c’è l’intenzione di unire anche /usr/bin e /usr/sbin. Non c’è motivo di stracciarsi le vesti, come nessuno lo fece anni fa quando vennero finalmente unite /usr/share e /share.
Oltre a risolvere i problemi di compatibilità dei percorsi di altri Unix e dare almeno una dritta agli sviluppatori che stupidamente non permettono agli autotools di configurare i path, direi che anche i packager ne traggono vantaggio. Per vederlo, basta osservare linee di specfile come:
Requires(post): /usr/bin/update-desktop-databaseo
%post -p /sbin/ldconfigper chiedersi il perché di tanti path dove cercare i programmi.
Poi sul fatto che anche altre directory andrebbero unite (come /sys e /proc, o /var/run e /run, o /var/tmp e /tmp) sono daccordo, ma questo è solo il primo passo.
Kim Allamandola
27 gen 2012 - 21:23 - #12@0xdeadbeef #11
dai una letta alla definizione di /opt ed /usr/local ed avrai la risposta, ti
risparmio anche la fatica:
/usr/local
serve a tutto ciò che non è essenziale al funzionamento del sistema e che
per varie ragioni NON VA ESPORTATO via NFS, da qui il nome local.
/opt
serve a tutto il software che non è essenziale al funzionamento del sistema
e che è gestito e sviluppato da terze partio.
Google ad esempio questo lo sa ed il suo Chrome, Earth ecc li mette in /opt,
lo sa anche la Sun, la Oracle, la Siemens (NX), la PTC ecc, per qualche
ragione l’ha scordato GNU che si è innamorata di /usr/local.
Ps usr stà per Unix System Resources; getty, brltty ecc non sono risorse ma
componenti essenziali al funzionamento del sistema, sono separati perché se
la “big-install” di gnome, kde, LO, FF, … vanno a ***** il sistema sia da
parte al sicuro…
0xdeadbeef
27 gen 2012 - 22:06 - #13@#12
E…? Non mi pare di aver scritto di unire /usr/local specificatamente con /opt, che nessuno ti impedisce di usare, peraltro. Fatto sta che non voglio che la distro istalli qualcosa in questi percorsi.
Ps. su fedora non c’è niente che va a *****. Un’eventualità che tecnicamente non dice nulla.
Binary Emotions
27 gen 2012 - 22:19 - #14/bin contiene i comandi di sistema (che devono essere disponibili anche quando non vi siano altri filesystem montati oltre la radice, quindi all’avvio ed in single user mode);
.
/sbin contiene i comandi di sistema ad esclusivo utilizzo dell’utente root (che devono essere disponibili all’avvio);
.
/usr/bin: contiene comandi usati dagli utenti, di vario genere (non essenziali all’avvio);
.
/usr/sbin, eseguibili o link ad esclusivo uso di root (non essenziali all’avvio);
.
E’ così stringente ed utile dividere i programmi in base all’essere essenziali all’avvio e non?
.
Già la distinzione tra uso root e uso non root potrebbe benissimo esser fatta a livello di permessi del file (sì, in questo caso potrebbe esser possibile listare tutti i comandi ad uso root da parte di tutti, ma non di usarli. E capirai).
.
/lib contiene le librerie usate dai programmi in /bin e /sbin ed i moduli (in /lib/modules) e deve stare sul medesimo filesystem della radice;
.
/usr/lib: cartella in cui trovano le installazioni dei programmi e le librerie (ma non essenziali all’avvio);
.
Eh mamma, poi mettiamoci le suddivisioni per 32, 64, 128.. bit…
Miracolo che non ci sia /opt/, /usr/opt, /usr/opt/lib * rand(x,y) ;)
flask
28 gen 2012 - 04:08 - #15La struttura gerarchica per organizzare un file sistem sarà sempre inadeguata come lo è in generale per organizzare qualsiasi cosa… cavolo è come se ancora avessimo a che fare con fogli di carta cassettiere e cartelle fisiche !!! Raga è ora di iniziare a sfruttare la versatilità dell’informazione digitale per ridisegnare e ripensare da aero anche le fondamenta.
L’unica cosa sensata da fare è buttare tutto al macero ed implementere natiavaente a livello di kernel un fsdb basico che peretta di organizzare i file con tags e criteri un minimo più versatili, con i quali è anche possibile eventualmente simulare una trattura gerarchica.
Bisogna prendere atto del fatto che è impossibile classificare un file in modo furbo con uno strumento limitatissimo basato sulla collocazione spaziale in una struttura ramificata rigida… per quanto ci si sforzi si ottiene sempre qualche cosa di inadeguato… che va bene si e no a soddisfare una esigenza ma che ne limita o impedisce mille altre.
Su questo fronte il mondo gnu/Linux potrebbe e dovrebbe fare molto di più… qualche fork in meno e qualche utile rivoluzione in più !!!
Reno44
28 gen 2012 - 11:49 - #16Io comincerei con l’eliminare le librerie condivise, ridondanza su disci da terabyte me la voglio permettere se così facendo mi garantisco 1cartella=1programma.
Poi mettetemele dove volete ste cartelle, purchè sia tutto lì
mavalaaa
28 gen 2012 - 14:30 - #17#16
si così per correggere un bug o una vulnerabilità in una libreria, tocca aggiornare tutti i programmi uno per uno. ma per piacere, tornate a windows va
flask
28 gen 2012 - 14:53 - #18effettivamente sono molti gli aspetti e i paradigmi che nei sistemi unix/linux dovrebbero essere completamente rivisti alla luce delle possibilità attuali.
La condivisione di librerie se portata e perseguita all’estremo è più un danno che altro… per risparmiare pochi k si introduce una complessità di gestione e una fragilità intrinseca senza avere alcun beneficio reale.
Unix deve essere ammodernato c’è bisogno di nuovi paradigmi… e mi riferisco al “core” mica agli strati sovrastanti o ad applicazioni specifiche che bene o male il loro sporco lavoro lo fanno mascherando abbastanza bene i limiti di unix.
fin quando per archiviare la lettera d’amore della morosa sarò costretto a dover litigare con me stesso perché non so se è meglio archiviarla in:
/home/documenti/morosa/lettere/amore
o in
/home/documenti/lettere/amore/morosa
o in
/home/document/amore/morosa/lettere
vuol dire che l’evoluzione informatica di unix è ancora inchiodata a 40′anni fa !!!
per non parlare di quando un documento soddisfa più criteri di classificazione… per esempio la foto di una bella bionda prosperosa la metto nella cartella bionde, prosperose o XXXX ???
questi sono i veri problemi degli utenti… compreso sviluppatori e sistemisti, altroché ;)
nel cuore di un moderno OS ci deve essere un database e l’organizzazione dei documenti seguire criteri di classificazione multipli/paralleli/ridondanti e non rigidi. Dove il fulcro di tutto è il documento con i suoi tags e non dove è collocato fisicamente nella struttura rigida.
Il moderno OS dovrebbe avere suoi criteri di base utili per il suo funzionamento e ogni utente dovrebbe poter aggiungere e organizzare i suoi specifici.
Il nuovo OS dovrebbe avere un sistema semplice per personalizzare gestire e modificare questi criteri, è complesso ma è fattibile.
Mi piange il cuore quando vedo che più semplice e veloce trovare una informazione su internet che quella che so esistere in un documento sul mio computer !!! E’ così per tutti e non venitemi a raccontare che voi avete trovato un sistema che vi soddisfa appieno perché non ci crederò mai :D
Mi rattrista constatare di vivere in un mondo dove la stragrande maggioranza degli appassionati di informatica puri (gnu/linux & C.) sono più interessati a scopiazzare qua e la e a forkare distro a nastro che affrontare e risolvere annosi problemi e limiti che oramai sono diventati ciclopici !!!
su queste cose è stata fatta molta teoria ma vigliacco che qualcuno si sia messo li a realizzare qualche cosa di funzionante: torvalds ha già dato ed è tutto preso a migliorare il suo clone unix gratuito… stllemann sono anni che vive nel suo mondo popolato di spettri digitali e legislativi ed è sopraffatto e completamente disarmato per affrontare nuove sfide tecnologiche… jobs, pace all’anima sua, era tutto concentrato a realizzare l’ideale del dell’OS perfetto, così minimale e pulito che per avere pochissimo si paga molto… gates ha lasciato MS in mano a quell’imbecille del gorilla lilla che non sa fiutare le tendenze della massa e un affare neanche a pregarlo in ginocchio per me è ipodotato… suttleworth si impegna a semplificare la gui prendendo ispirazione da OS X ma è costantemente alle prese con il tentare di fare stare in posizione verticale una colonna di sterco liquido… trovo la situazione decisamente desolante
Reno44
29 gen 2012 - 11:45 - #19Mavalaa:
Un sistema che tenga conto di quali librerie siano installate e dove potrebbe tranquillamente aggiornare tutte le copie “buggate” nel mio sistema. Esattamente come i sistemi “intelligenti” di oggi ti sbattono e ti aggiornano ogni singolo file ovunque esso drammaticamente sia ubicato.
Che poi, sto parlando di sistemi home. Sui server potete tranquillarmente tenervi i giochini da guru, è il vostro lavoro :)
Kim Allamandola
30 gen 2012 - 09:37 - #20@flask #18, Reno44 #19
Da quel che scrivete *spero* non siate sviluppatori, per lo meno non in
ambito open. Voler eliminare il linking dinamico vuol dire non sapere di
cosa si stà parlando (e non è per i kb che cmq sui sempre più diffusi ssd
sono preziosi), se vogliamo limitarci al banale l’aggiornamento di libreria
xxx del peso di 12Kb, usata da 100 binari diversi richiederebbe di scaricare
100 nuovi binari; non penserete mica di indicizzare i bit della libreria
dentro ogni singolo binario vero!?
In generare sono il primo a spingere verso un ripensamento del filesystem a
la zfs, o meglio in evoluzione del paradigma iniziato da zfs ma questo pare
non interessare, non solo su GNU/Linux ma anche su ogni altro OS, IllumOS a
parte che però ha troppo pochi sviluppatori per andare avanti sul serio…
Il punto è avere un diverso concetto di storage, le singole applicazioni possono
avere un persistenza builtin nel loro linguaggio a cui si può eventualmente
anche accedere via fs ma anche in vari altro modi. Questo sul piano dell’utente
finale comprende anche le label (@flask) ma queste sono solo la punte dell’iceberg!
Binary Emotions
30 gen 2012 - 18:01 - #21@Kim Allamandola,
il punto sulle librerie credo fosse un desiderio per una gestione delle loro dipendenze meno “frustrante” (a livello desktop), più che (lo spero anch’io..) un desiderio di eliminazione del linking dinamico…
Reno44
30 gen 2012 - 21:12 - #22Assolutamente Binary, è quello che intendevo.
Thanks
Kim Allamandola
31 gen 2012 - 08:19 - #23@Binary Emotions #21
Le librerie sono sempre state un problema su ogni os. La scelta tipo quella
da te proposta è quella di Windows: l’”inferno delle dll” penso ti sia noto…
Il problema delle librerie come delle dipendenze è che ci sono un po’ troppi
strati da gestire: quando nacque UNIX le librerie erano quelle standard del
C (all’epoca K&R poi ANSI poi POSIX poi XOpen ecc sino a GNU) e non c’era né
si sentiva il bisogno di altro.
Via via che l’hw è diventato più “grosso” ed il software evolveva la libreria
standard è diventata limitata così sono nate n librerie e/o programmi che
offrivano loro API sopra la libreria standard.
Oggi la stratificazione è notevole.
Per questo da tempo dico che è ora di uno Unix 2.0 con una nuova libreria
standard molto più carrozzata e comoda da usare (ed. oggi non si usano in
genere direttamente le XLib perché sono fottutamente scomode, si usano le
GTk o le Qt o le Wx o altro che a loro volta sono librerie sopra le XLib)
ma le dipendenze non sono un problema percepito dall’utente finale, sono
egregiamente gestite da anni dai vari package manager… Un nuovo Unix
non richiede meno sforzi (e tempi) del vecchio e visto che le competenze
di oggi sono assai inferiori a quelle di un tempo sarebbe bene mettersi un
po’ a tavolino ed iniziare prima scrivendo cosa si vuol fare e poi iniziando
ad implementarlo, non come Fedora che stà saltellando ovunque per farsi il
suo “nuovo brand” in bambinesca competizione con Ubuntu!
0xdeadbeef
31 gen 2012 - 14:44 - #24@Binary Emotions e Reno44
Eliminare il linking dinamico non può essere la soluzione in generale, che peraltro è un aspetto che all’utente finale non deve interessare. Piuttosto, a mio avviso le considerazioni sulle ABI break fatte in un altro post sono più giuste e radicali.
Poi chi produce software proprietario per linux o lo fa link statici (rischiando di riempire la memoria dell’utente, e quindi forzando un swapping continuo con conseguenti rallentamenti), o include versioni specifiche di librerie così l’utente può gestire la situazione come meglio crede. Oppure taglia la testa al toro e scrive in java, come nel caso di diverse applicazioni professionali.
@Kim Allamandola
Quello è uno dei motivi che ha portato alla scrittura di wayland. Comunque unix 2.0 (???) o no, gtk e qt continuerebbero ad essere usati comunque, per lo meno in quanto toolkit multipiattaforma.
Poi le tue infantili considerazioni su fedora/rh si commentano da sole come al solito. Prova per una volta ad essere meno egocentrico e a togliere le questioni personali da tutto questo.
Binary Emotions
31 gen 2012 - 16:53 - #25@Kim Allamandola,
> Le librerie sono sempre state un problema su ogni os. La scelta tipo quella
da te proposta è quella di Windows: l’”inferno delle dll” penso ti sia noto…
.
In realtà no, i moderni Windows più che di DLL hell soffrono di “calderone DLL”, se mi consenti questa parola.
Comunque la soluzione da me prospettata assomiglia maggiormente ai PBI di PC-BSD.
Certo, la soluzione più elegante la hanno le distro Linux, ma:
.
> ma le dipendenze non sono un problema percepito dall’utente finale, sono
egregiamente gestite da anni dai vari package manager
.
Questo non è proprio vero: vallo a dire ad un utente che non risce ad installare un nuovo software perchè… toppo nuovo per tutta la ragnatela delle dipendenze.
.
Io AMO i package manager e il loro concetto sui server, ma sui desktop meno.
Binary Emotions
31 gen 2012 - 16:54 - #26@0xdeadbeef,
beh, infatti non mi è mai saltato in mente di farlo :)
Kim Allamandola
31 gen 2012 - 19:34 - #27@0xdeadbeef #24
Unix 2.0, sì, un OS che per un verso e per l’altro è stato tirato in ballo da
tanti nel tempo: java che doveva essere il cuore di un nuovo network-OS, l’idea
di Miguel de Icaza (il suo famoso Unix suck!) ecc. nessuna di queste è riuscita
ma esperienza ed esempi né han dato.
Un OS dove il software di sistema e la toolchain di sviluppo sono molto vicini,
dove tutte le funzioni di base e le API esposte dai singoli software siano
import/#includ/use-abili da ogni altro software.
Android ha realizzato questo pur in un brodo di java, MeeGo è rimasto col
classico unix che nonostante QtQuick non s’è diffuso.
Se poi le mie considerazioni su RH/Fedora sono bambinesche…
@Binary Emotions #26
Chiediti perché PC-BSD non è diffusa né imitata da nessuno con successo, i
package-manager sono di tanto successo che l’intero mondo stà passando a
questi, dall’App Store dei prossimi Windows ad iThunes di Apple, all’Android
Market ecc, tutti implementanti il classico concetto dei repo con una gran
farcitura di spazzatura proprietaria anti-utente in mezzo.
Reno44
31 gen 2012 - 20:38 - #28Quando parlavo del problema delle dipendenze pensavo proprio a PC-BSD, che ho usato in passato..con soddisfazione. Sul perchè non abbia successo, beh non tutte le distro possono vantare il marketing di ubuntu..
Binary Emotions
31 gen 2012 - 22:09 - #29@Kim Allamandola,
gli app store NON sono package manager! Guarda caso che con gli app store puoi installare la nonna senza che ci siano mai problemi di dipendenze.
.
PC-BSD non ha successo sui desktop proprio perché.. è BSD. Che c’entra il suo sistema di installazione dei pacchetti?
Allo stesso modo si può dire che Linux sui desktop è nullo a cfr di Windows proprio per il suo sistema di installazione.
Kim Allamandola
01 feb 2012 - 09:40 - #30@Reno44 #28
C’è un motivo per cui Ubuntu ha successo e PC-BSD no, come c’è un motivo
per cui ben poca gente sviluppa PC-BSD e in generale per cui i *BSD sono
molto meno sviluppati di GNU/Linux pur avendo caratteristiche spesso un po’
superiori. Nel caso dei *BSD il motivo è la licenza che non garantisce la libertà
del software non tutelando abbastanza chi sviluppa rispetto ad es. alla GPL, nel
caso di PC-BSD il motivo è l’immantenibilità sostanziale del sistema (vedi sotto)
@Binary Emotions #29
Gli AppStore sono un frontend ai package manager, cosa credi che il Software
Center quando pigi install su un’applicazione non si installi le dipendenze
da solo? Lo fa senza che l’utente si interessi a questo…
La soluzione che presenti tu è quella di Windows dove un po’ di applicazioni
si aggiornano via Windows Update, altre via un sistema loro altre ancora devi
farlo a mano! Grazie ai package manager (inclusi i loro frontend e la struttura
dei repo) su GNU/Linux da sempre gestisci tutto in maniera semplice e centrale.
I PBI di PC-BSD sono una *tronzata tecnica nata pensando che l’utente Windows
è abituato a scaricare da internet il software e seguire un wizard mentre non
sa quanto sia comodo avere un Software Center, Synaptic, apt, pkgsrc ecc che
fa tutto da un’unica faccia. E questo è il motivo per cui PC-BSD è assai meno
diffusa di FreeBSD su cui si basa sui *desktop* pur avendo già pronte molte
cose sul supporto usb, sulle stampanti ecc.
Che il processo di gestione dei deb e degli rpm sia da riformare sulla via di
OpenSolaris/IllumOS ma anche dei ports è indubbio: avere un unico repo dove
commit-i degli spec e da questi compili l’intera distro e crei tutti i binari
è un ordine di grandezza di comodità, rapidità ed usabilità sopra le soluzioni
GNU/Linux di oggi. Ubuntu con le recipes sul Launchpad stà timidamente andando
in quella direzione ma parlare di eliminare il linking dinamico e i package
manager è semplicemente assurdo.
Prova a farti su un pezzo di carta l’architettura schematica del tuo sistema
e poi ridisegnala come la vorresti tu: l’elenco dei problemi e l’assenza di
vantaggi la vedrai subito se consideri l’intero sistema e non solo l’aspetto
dal punto di vista dell’utente finale.
Binary Emotions
01 feb 2012 - 16:02 - #31>La soluzione che presenti tu è quella di Windows dove un po’ di applicazioni
si aggiornano via Windows Update, altre via un sistema loro altre ancora devi
farlo a mano! Grazie ai package manager (inclusi i loro frontend e la struttura
dei repo) su GNU/Linux da sempre gestisci tutto in maniera semplice e centrale.
.
Mai detto. Io vorrei tutto il software del sistema gestito da p.m. con dipendenze meno stringenti per le librerie. Tutto qui.
.
Sugli app store: http://en.wikipedia.org/wiki/App_Store
Kim Allamandola
02 feb 2012 - 13:52 - #32@Binary Emotions #31
Mi spieghi che problema hai con le librerie? Se pensi ai path /lib, /usr/lib
ecc bé sappi che fan parte della compatibilità a 32bit necessaria solo ed
esclusivamente a software proprietari che ancora non sono a 64bit… Nel
mondo proprietario la qualità del codice è molto più bassa dei progetti open
vuoi perché si va di corsa, vuoi perché i programmatori sono pagati ma non
interessati od attratti dal progetto a cui lavorano, vuoi perché la qualità
non è un obbiettivo del progetto ecc ma purtroppo esistono ancora software
proprietari che sono solo a 32bit…
Per il resto la separazione /lib /usr/lib è la stessa di /bin /usr/bin ecc
che ha ragioni già spiegate.
Non vedo problemi di gestione librerie specie problemi per l’utente finale.
Sugli app store, se non ti piace il loro nome chiamali front end a package
manager, chiamali “repo”, usa il nome che vuoi ma di nuovo non vedo quale
sia il problema per l’utente finale. Il Software Center ad esempio già mette
da parte gli “elementi tecnici” per non “confondere” l’utente, cosa non va?
Binary Emotions
08 feb 2012 - 10:01 - #33@Kim Allamandola,
alla fine della fiera, all’utente finale non va una sola cosa: non poter installare il software voluto nella versione voluta senza che una “qualche cosa” del SO non gli dica “Non posso perché..non posso”.
Questo per rispondere alla domanda “Cosa non va?” riferito alle librerie.