In medias res

Ci sono due argomenti principali che causano sempre grandi dispute e flame sulla mailing list degli utenti-mplayer. Il numero uno è naturalmente l'argomento

GCC 2.96

Leggi anche questo testo !!!

Il retroscena : C'erano/ci sono le serie GCC 2.95. Il migliore era il 2.95.3 . Per favore nota lo stile di numerazione delle versioni. Così è come il team GCC numera i loro compilatori. Quelli della serie 2.95 sono buoni. Non abbiamo mai visto nulla compilato male a causa di errori del 2.95.

L' atto : RedHat cominciò ad includere una versione 2.96 di GCC con le loro distribuzioni. Nota il numero di versione. Questo dovrebbe essere una versione del team GCC. Hanno modificato la versione CVS di GCC (qualcosa tre 2.95 e 3.0) L'hanno modificata profondamente, e hanno usato questa versione nella distribuzione perchè il 3.0 non era uscito a quel tempo, e vollero che IA64 supportasse ASAP (ragioni di mercato). Oh, e GCC 2.95 compila male bash sull'architettura s390 (non esiste nessuna distribuzione RedHat per s390..) .

I fatti : Per compilare MPlayer necessita l'opzione --disable-gcc-checking per procedere dopo l'aver trovato la versione 2.96 di GCC (apparentemente la necessita anche con egcs. Questo perchè noi non testiamo MPlayer con egcs. Perdonaci, noi preferiamo sviluppare MPlayer). Se conosci MPlayer, dovresti sapere che è molto veloce. Ottiene questo grazie al fatto di avere codici MMX/SSE/3DNow/ecc stra-ottimizzati, fastmemcpy, e molte altre caratteristiche. MPlayer contiene istruzioni MMX/3DNow in una sintassi che tutti i compilaturi linux accettano... tranne il GCC della RedHat (è più compatibile con gli standard). Semplicemente li salta. Non mostra errori. Non mostra avvertimenti. E, c'è Lame. Col gcc 2.96, il suo test di qualità (make test dopo aver compilato) non parte nemmeno !!! Ma hey, compila bash su s390 e IA64.

Le dichiarazioni : la maggior parte degli sviluppatori del mondo cominciarono ad avere una cattiva idea del GCC 2.96 della RedHat, e dissero ai loro utenti RedHat di compilare con un altro compilatore. Il disappunto degli utenti RedHat si trasformò lentamente in rabbia. A cosa serviva, se non a procurare mal di testa agli sviluppatori, gettare benzina su flame anti-RedHat, confondere gli utenti? La risposta, non la conosco.

I giorni nostri : RedHat dice che il GCC 2.96-85 e superiori sono stati corretti, e funzionano propriamente. Nota il numero di versione. Avrebbero dovuto cominciare con qualcosa del genere. Com'è il GCC 2.96.85 ? Non importa ora. Non ho cercato, ma vedo ancora bug nel 2.96 . Non importa ora, si spera che ora RedHat dimenticherà il 2.96 e si rivolgerà verso il 3.0. Verso un 3.0 profondamente modificato...

Quello che non capisco è perchè gli utenti RedHat ci odino per aver inserito messaggi di avvertimento, e documenti che consigliano di stare alla larga dal 2.96 in MPlayer . Perchè siamo chiamati "teste bacate", "scemi totali", "puerili" dagli utenti RedHat, sulla nostra mailing list, e perfino su quella redhat-devel . Hanno anche considerato l'idea di un fork di MPlayer per loro stessi. Utenti RedHat. Perchè? E' RedHat che ha fatto il compilatore, perchè voi dovete odiarci? Siete così adoratori di RedHat? Per favore smettetela. Non abbiamo nessun rancore nei confronti degli utenti, non importa se vi sembra tanto il contrario. Per favore andateci di flame con Linus Torvalds, gli sviluppatori DRI (oh, ora so perchè sono stati sospesi da VA!), di Wine, di avifile. Anche se siamo arroganti, non siamo come questi elencati? Perchè noi dovremmo soffrire la vostra ingiusta collera?

Matt Willis ci ha gentilmente mandato un semplice documento su come compilare col GCC-3.0.3, lo copio qui sotto:

Scarica gcc. Vai alla pagina http://gcc.gnu.org/mirrors.html Io ho scaricato i seguenti file, ma non devi avere tutto:
gcc-g++-3.0.3.tar.gz gcc-objc-3.0.3.tar.gz gcc-3.0.3.tar.gz gcc-g77-3.0.3.tar.gz gcc-testsuite-3.0.3.tar.gz gcc-core-3.0.3.tar.gz gcc-java-3.0.3.tar.gz

Scompatta i file, fai una directory per la compilazione, e compila

     tar xvzf gcc-*3.0.3.tar.gz
     mkdir gcc-build; cd gcc-build
     ../gcc-3.0.3/configure --prefix=/opt --program-suffix=-3.0.3
     make bootstrap; mkdir -p /opt; make install

Inserisci nel tuo path /opt/bin
export PATH=/opt/bin:${PATH}
Ora puoi compilare MPlayer.

Distribuzione binaria di MPlayer

Tonnellate di utenti ci hanno chiesto questo. Per esempio gli utenti Debian tendono a dire: Oh, Posso fare apt-get install avifile, perchè dovrei compilare MPlayer ? Sebbene questo possa sembrare ragionevole, la questione è un po' più complessa che quei-fottuti-sviluppatori-MPlayer-odiano-gcc-2.96-e-RedHat-e-Debian.

Ragioni: Legge

MPlayer designa il codice sorgente. Questo contiene molti file con licenze incompatibili specialmente a livello di clausole di redistribuzione. Come file sorgente, possono coesistere in uno stesso progetto.

Quindi, NON POSSONO ESISTERE NE BINARI NE PACCHETTI BINARI DI MPlayer IN QUANTO TALI OGGETTI VANNO CONTRO LE LICENZE. PERSONE CHE DISTRIBUISCONO TALI PACCHETTI BINARI STANNO COMPIENDO ATTIVITA' ILLEGALI.

Quindi se conosci qualcuno che mantiene un pacchetto binario mandagli questo testo e contattaci o chiedi a lui di farlo. Quello che sta facendo è illegale e NON E' PIU' MPlayer, ma il suo mplayer. Se qualcosa non va con quel pacchetto, è colpa sua. Non venite a lamentarvi sulle mailing list di MPlayer, sarete probabilmente messi in blacklist.

Ragioni: Tecniche

Le ottimizzazioni di velocità di MPlayer (MMX, SSE, fastmemcpy, ecc) sono stabilite durante la compilazione. Così un binario compilato contiene codice specifico del processore. Un binario MPlayer compilato per K6 non funzionerà su Pentium e vice versa. Questo deve essere aggirato dal riconoscimento a runtime, che non è una cosa facile da fare perchè da come risultato una grande diminuzione di velocità. Se non ci credi (è stato spiegato in dettaglio 10000 volte su mplayer-users, cerca negli archivi), risolvi il problema e mandaci una patch. Qualcuno aveva cominciato a lavorarci, ma da allora è scomparso.
Il sistema audio/video di MPlayer non è basato su plugin. E' compilato nel binario, facendolo così dipendere da varie librerie (la GUI dipende da GTK, DivX4 dipende da libdivxdecore, SDL dipende da libSDL, ogni versione di SDL contiene un bug proprio che deve essere aggirato alla compilazione, l'output X11 compila diversamente per X3 e X4, ecc). Potrai dire: si, facciamo 30 versioni di binari scaricabili! Noi no. Inseriremo queste cose come plugin nel futuro.

NVidia

Non ci piacciono i driver binari di nvidia, la loro qualità, instabilità, l'inesistente supporto all'utente, la regolare comparsa di nuovi bug. E la maggior parte degli utenti fa lo stesso. Ultimamente siamo stati contattati da NVidia, e loro hanno detto che questi bug non esistono, l'instabilità è causata da pessimi chip AGP, e che non hanno ricevuto nessuna segnalazione di bug del driver (la linea viola, per esempio). Quindi: se hai problemi con la tua NVidia, aggiorna il driver nvidia e/o compra una nuova scheda madre.

Joe Barr

Non risponde alle nostre mail. Il suo editore non risponde alle nostre mail. La rete è piena delle sue false dichiarazioni e accuse (apparentemente non gli piacciono i ragazzi BSD, a causa dei loro diversi punti di vista [su cosa?]).

Ora alcune citazioni di diverse persone circa Joe Barr (solo per farvi sapere perchè non conta assolutamente niente):

"Voi tutti ricorderete il LinuxWorld 2000, quando lui affermò che Linus T disse che 'FreeBSD è solo un aiuto per i programmatori'. Linus non disse NIENTE del genere. Quando furono chieste spiegazioni a Joe, la sua reazione fu quella di chiamare tutti i sostenitori BSD stupidi e tonti."

"E' interessante, ma non è bravo ad evitare, um... le discussioni. Joe Barr era regolarmente presente sul forum Canopus di Zachmann su Compuserve, anni fa. Allora era un sostenitore di OS/2 (anche io ero un fan di OS/2). Era solito passare il limite, insultando la gente, e credo che avesse passato dei brutti quarti d'ora, al tempo. Si è ammorbidito un po' recentemente, giudicando dalle sue colonne. L'umorismo moderatamente subdolo non era suo uso a quei tempi, per niente."