Alcune funzionalità sono disabilitate, accedi per attivarle e partecipare!
Activity results for #fedora
-
Fedora 18 Spherical Cow è tra noi
Dopo ben 3 mesi di ritardo (!), Fedora 18 è stato rilasciato.
Tra le features: Samba 4, Active Directory (conseguenza di Samba 4), DragonEgg, GNOME Ibus, Secure Boot e tanta altra roba.
#fedora -
Fedora 17 ”Beefy Miracle” c’è
http://www.reddit.com/r/linux/comments/ua0h9/the_beefy_miracle_has_arrived_grab_your_fedora_17/
Qui la feature list: http://fedoraproject.org/wiki/Releases/17/FeatureList (tra cui: tutto in /usr e aggiornamenti varii)
#fedora-
Era ora!!! La proverò uno di questi giorni
-
Avevo già eseguito l’upgrade all’ultima RC
magari è solo un’impressione ma me sembra molto più reattiva della 16. -
La proverò :)
Fedora è una di quelle distro che gira bene sul mio vecchio laptop! Per fare un esempio: Ubuntu 12.04 LTS non mi parte nemmeno :\
Ora sono su arch + kde (alquanto lento per il mio hardware), ma visto che avevo in mente di tornare a gnome3 forse installerò direttamente fedora.Che package manager usa? Ancora yum?
-
si si, ancora yum
-
-
Ho fatto partire l’iso con unetbootin da grub, ma non riesco ad installarla! In fase di partizionamento – manuale – mi dice che non ho selezionato il target device del bootloader stage1, cosa che comunque non si può fare!
-
purtroppo io e fedora non andiamo troppo d’accordo…
-
purtroppo fedora non va d’accordo con la stragrande maggioranza dell’hardware che ho avuto :-/ (tranne per un acer aspire da 300 euri su cui girava da dio)
-
a me ha sempre dato problemi con i driver proprietari. c’è da dire che le uniche distro che non vacillano sotto questo punto di vista sono le mandriva e figlie. ho provato anche a compilare i driver con gentoo adottando un file make.conf creato appositamente per il mio hardware ma non è servito a molto. ora sto provando con una arch ma ho la vaga sensazione che tornerò su pclinuxos abbastanza presto.
-
-
-
-
Fedora 17
Visto che nessuno lo ha segnalato… è uscita Fedora 17 betahttp://www.ossblog.it/post/9827/fedora-17-rilasciata-la-versione-beta
Qualcuno di voi, l’ha provata?
-
ah, quella col filesystem riorganizzato… ha pure gimp 2.8. Sto fine settimana la provo :)
-
Certo che per essere la distro di punta di Gnome nessuno se la fila.
La notizia viene data qui con un paio di giorni di ritardo e anche su oss blog nessuno se l’è filata (0 commenti per un posto del 18 aprile)!Poi c’è chi dice che è unity la ”cosa che non piace”….
-
A mio parere le beta non fanno notizia…
-
Beh vedendo la lista di blog che annunciano la roadmap della prosima ubutnu (di cui ancora non sappiamo il nome), le migliaia di pagine scritte sulle alpha di ubuntu e le milioni di pagine scritte per commentare il possibile aspetto del prossimo SGS3 e la princiaple notizia dei tg di oggi (la baruffata tra una zoccola e una pseudocantante che si litigano un tamarro in prima serata su canale 5) mi viene da dire che forse non hai capito un cxxxo di come vanno le notizie a questo mondo…
-
-
Io per il momento l’ho solo installata… che dire, la prima impressione è che tutto funziona correttamente.
Sembra essere reattiva, e solo saltuariamente si è notato un leggerissimo ”impallamento” quando si andava in alto a sinistra su ”Activity”.
Penso che la terrò installata sul mio portatile per provarla un po’ più nel dettaglio.
La cosa che mi manca di più sono il sudo attivato di default, e apt, ppa e compagnia bella.
E credo che Gnome 3 non sia così male.-
se ti mancano i ppa è perché non conosci RPM Fusion un repository per Fedora gestito dalla comunità contenente tutto il ben di Dio esistente per Fedora. È suddiviso in varie sezioni tra cui spunta la segmentazione ”testing”, precedente a ”relase”, in modo da rilasciare solo pacchetti effettivamente stabili (questa cosa manca a Launchpad).
Basta che aggiungi questo e altro che Ubuntu… mai più dover aggiungere un ppa e/o andare in casino di dipendenze per via di un ppa tenuto su da un Uzbekistano frettoloso che non ha controllato bene le dipendenze-
infatti la prima regola e’ proprio evitare ppa che contengono tutto il ben di Dio, proprio per evitare casini con dipendenze e librerie. Il bello dei ppa e’ che aggiorni un app, punto.
-
molti ppa si portano dietro librerie che ti spaccano il sistema, ricordo ad esempio il ppa di gnome-shell per maverik o il ppa di elementary os per oneiric etc…
-
…appunto, evitare repository con tutto il ben di Dio dentro
-
-
Ma quanto è comodo, invece il ppa di grails?
Si possono avere sul sitema un sacco di versioni contemporaneamente e via update-config –alternative scegliere la versione che si vuole usare.
Al lavoro ci ho campato che è una meraviglia… ci sono ppa e PPA :-) -
@lorem rpmfusion è un repository parallelo ma non comunitario. È vero che non è ufficiale ma dato che è praticamente il solo repository per Fedora è supercontrollato. I mantainer dei pacchetti possono essere solo gli stessi dev di Fedora.
http://rpmfusion.org/Contributors #Becoming_a_RPM_Fusion_contributor
È organizato prendendo in considerazione un canale di testing prima che il pacchetto sia rilasciato nel repo stabile.
Insomma tutte le manate sui repository che contengono il ben di Dio ce le si deve fare su Launchpad dove basta aprire un account per poter caricare anche tutta una distribuzione (elementary OS ad esempio).
Non sparare cavolate senza informarti.-
e che cavolata avrei sparato?
anche su launchpad e’ pieno di ppa di [ex]dipendenti canonical (prendi quello di Kubuntu), quindi? vogliamo venire qui a gettare m3rda su Ubuntu perche’ un poveretto si apre un ppa, magari ci scrive pure di non utilizzarlo, e ti sputtana il sistema?
mah, siamo alla follia…
-
+1
-
+millemila
-
Hai travisato il senso del mio commento. Volevo solo sottolineare che la sicurezza e la stabilità di RPMFusion, che è un repository bello pieno, non è comparabile con un ppa pieno di roba su launchpad poichè questo è controllato direttamente dai dev della stessa Fedora e ha un canale di testing che elimina rogne di compatibilità e stabilità.
-
sono cose diverse non puoi applicare la regola ”evitare ppa pieni di roba” (valida per launchad) anche per rpmfusion… non è una legge universale
-
non ho mai voluto insinuare niente su RPMFusion, ti facevo solo il verso, +o- bonariamente
-
-
-
-
-
-
-
-
-
Mi chiedo se tutte le distro puriste avranno lo stesso approccio, in pratica darsi la zappa sul piede
Si, certo, continuiamo a usare roba closed e a lamentarci che nessuno investe sull’open.
-
Sarò un purista ma io dico: ben fatto!
Esistono in ogni caso i repository rpmfusion per chi vuole software proprietario sulla sua Fedora.-
+100
-
+1
Anche io purista. Per 2 ragioni:
0. Perché il software proprietario/i formati proprietari sono MALE! (cit.)
1. Se continuiamo a usare software e formati proprietari, non sentiremo il bisogno di alternative libere, e non le svilupperemo, fino a quando non ce lo metteranno in quel posto (il brevetto, dico).
2. Non è il caso di H.264, per il quale mi pare esistano implementazioni in software libero, ma con il software proprietario ci si ritrova troppo spesso a dover rinunciare al controllo, al debug e alle ottimizzazzioni che potremmo fare se fosse tutto sotto licenza libera. I problemi di Ubuntu 11.04 e con i driver Nvidia sono stati emblematici in proposito: una nuova versione di Xorg, i driver proprietari in ritardo, e tutti quelli che avevano schede Nvidia a lanciare maledizioni ai quattro venti.
Questo non dovrebbe accadere.
-
-
ben fatto!
facendo un esempio di comparazione…
è lasciando correre che la corruzione in italia, nel tempo, è arrivata alle situazioni da far venire i brividi… -
Per amor di precisione:
H.264 è uno standard, messo a punto dall’MPEG e certificato dall’ISO. WebM invece non è uno standard, e ne esiste solo un’implementazione di riferimento open source, non una specifica.
Il codec H.264 che usiamo sotto Linux è software libero.
L’unico problema è che H.264 è composto da tanti algoritmi soggetti a brevetti. I detentori di questi brevetti hanno formato un’ente chiamato MPEG LA (totalmente scorrelato dall’MPEG) che ha il compito di riscuotere i soldi delle licenze e dividerli tra i suoi membri. Questi soldi vengono solitamente riscossi dai produttori di hardware in grado di decodificare l’H.264, come i PC, i set-top box e gli home theater.
Non c’è niente da pagare per mettere on-line un video H.264, e se non sbaglio la MPEG LA ha formalmente promesso che non ci sarà mai niente da pagare. Distribuire dei codec H.264 potrebbe esporre ad una causa, ma tutto espone a una causa: non credo che Fedora Project o Canonical siano in grado di sostenere una causa contro chicchessia senza l’aiuto di IBM, e nessuno è in grado di sostenere una causa contro IBM.
Insomma, la questione è puramente ideologica e non ha niente a che fare con la libertà del software intesa come aderenza alla GPL. Ciò non toglie che i brevetti sul software siano un enorme problema che dovrebbe essere risolto alla radice, abolendoli o regolamentandoli in modo chiaro e stringente – cosa che la lobby degli avvocati non permetterà mai, mettiamoci l’animo in pace.
-
Grazie per l’interessante precisazione.
Anche se MPEG LA ha promesso che non ci sarà mai niente da pagare, quando abbiamo a che fare con brevetti c’è sempre il rischio che qualcuno ne abusi. E visto che un codec video non si fa dalla notte alla mattina, è sempre meglio premunirsi con un’alternativa libera da questi vincoli, e pressare perché venga adottata.
Quanto meno per ”dissuadere” chi voglia abusare dei brevetti dal farlo: l’esistenza dell’alternativa libera limita la dipendenza e quindi la forza di costrizione che ha il detentore del brevetto: se ho due formati, A e B, tecnicamente equivalenti o quasi, se domani qualcuno decide imporre restrizioni su A, tutti potremo passare a B, ed A perderebbe clienti (risultato non certo desiderabile).-
Parole sante: non è un caso se MPEG LA ha esteso la sua licenza gratuita per i video sul web a tempo indeterminato (prima si riservava il diritto di chiedere royalties a partire dal 2015, mi pare) subito dopo che Google ha rilasciato WebM ed è stato evidente che l’attacco FUD era poco credibile.
-
-
Quoto. Non c’è nulla di closed nei codec soggetti a brevetti e, per quanto ne sappiamo, qualsiasi codec potrebbe essere brevettato. L’unica differenza tra WebM e H.264 è che il secondo è sicuramente brevettato (anche se sulla validità effettiva di quei brevetti ci sarebbe da discutere), mentre il primo potrebbe esserlo.
Ben venga la presenza di alternative (purché siano standard ISO e Google, dopo un anno, non sembra interessata a sottoporlo come tale): ben venga la presenza di codec royalty-free (possibile solo finché qualcuno non fa il patent-troll) e via discorrendo, ma costringere gli utenti a usare rpm-fusion per usare dei codec liberi è una scelta legale, non ideologica.
Fedora non sta difendendo la libertà degli utenti, ha solo paura di un’azione legale di MPEG-LA nei suoi confronti.
(E ve lo dice un sostenitore di WebM e di Fedora. Molto deluso da Google.)
-
-
-
Zif, il package manager alternativo a YUM, ritorna in auge su Fedora
Non ne avevo mai sentito parlare. Pare che sia più veloce di Yum, con cui comunque non mi sono mai trovato male.
Richard Hughes, il suo creatore, chiede anche aiuto per migliorarloFonte: Ossblog
#fedora #packagemanager-
Cool! C’è una bella varietà di package manager ma alla fine ci si ritrova tutti a puntare su apt.
-
con tutta la buona volontà ed il codice che si sta mettendo nel cercare di unificare il più possibile il sistema di installazione dei pacchetti nel mondo linux, qui si spinge per una soluzione che non solo fa discriminanza tra RPM e DEB (senza contare i TGZ o altro), ma addirittura è un package manager che è compatibile solo con l’infrastruttura di RH/Fedora!
Non mi sembra una buona idea.-
Volontà di chi per unificare? Ultimamente RH/Fedora ha mostrato che non sono interessanti a ”unificarsi”…
-
non mi riferivo al mondo rh/fedora ma in generale allo sforzo che in tutto il resto delle distro si sta facendo con packagekit e le integrazioni di basso livello…
-
-
-
-
Rilasciato Fedora Remix per Raspberry Pi
Un’altra distribuzione si unisce a Debian Squeeze e Ark Arm Linux. Con l’annuncio un piccolo tutoria per l’installazione che ho pensato di tradurre tanto mi è sembrato ben fatto
[1] http://www.raspberrypi.org/archives/805
[2] La traduzione
#raspberrypi #Fedora #FedoraRemix -
Le performance di #Btrfs lasciano ben sperare
In una comparazione di #Phoronix con #ext4 sul kernel 3.3, il filesystem del futuro sembra cavarsela abbastanza bene (nonostante non siano state utilizzate alcune ottimizzazion,i come la compressione trasparente a livello fs).
Considerando che il codice preliminare di #btrfsck è già disponibile (esclusivamente per testing) e che sono attese numerose altre ottimizzazioni per il kernel 3.4, questa è la volta buona in cui potremmo vederlo di default su #Fedora 18 :)
-
dalla lettura si evince che come fs va bene su un server che compila tutto il tempo. Negli altri casi testati è ancora (spesso decisamente) meglio ext4.
Diamo tempo al tempo, prima o poi sarà un’opzione affidabile e veloce.-
A livello prestazionale, per un computer generico, è sicuramente (ancora) meglio EXT4. Però il dislivello non è così netto, anche senza ottimizzazioni di sorta, e le nuove funzionalità di Btrfs possono far gola anche agli utenti desktop.
-
-
Se solo Dpkg fosse un po’ più veloce. Ovviamente altrove Btrfs andrà meglio.
-
-
Scorri tra 17 notizie.





Il Secure Boot sta iniziando volenti o nolenti ad ”affliggere” le distro Linux :)
Spero solo che sia un transitorio che si risolverà in tempi ragionevoli…