Tecnologia e non solo

ottobre 24, 2008

La “moria” delle API.

Filed under: Varie — telperion @ 7:47 pm

Giocherellando con gloobus e compilandolo con le librerie di Intrepid nessun problema, ma passando a Gentoo ~x86 subito ci si scontra con:

impossibilità di compilarlo con gcc-4.3 facilmente risolvibile usando il gcc-4.2 (anche con intrepid)

Invece le nuove versioni di

ffmpeg 0.4.9_p20081014
imagemagick 6.4.4.6

rappresentano un ostacolo invalicabile per la compilazione di molti plugin, causa la rottura (consueta, ennesima) di compatibilità con le versioni precedenti.

Considerazioni.

Una grande parte delle risorse di programmazione viene impegnata regolarmente solo per mantenere il codice funzionante, dove per “mantenere” non intendo migliorare debuggare aggiungere “feature”, no si lavora solo per mantenerlo funzionante (cioè compilabile con le nuove versioni delle dipendenze necessarie).

Conseguenze.

Con questo sistema di sviluppo qualsiasi soft o entra velocemente a far parte di un gruppo di lavoro consistente, oppure nel giro di 6 mesi nel caso lo sviluppatore si “stanchi” è destinato anche fosse il “santo graal” del software, a diventare “non funzionante” e a cadere in disuso.

In questo modo brillanti idee di singoli vengono bruciate, mentre sopravvivono solo i progetti sponsorizzati dai “grandi nomi” che controllano la maggior parte dei programmatori.

Riflessioni.

A prescindere dal grandissimo numero di ore lavoro sprecate solo per mantenere il codice funzionante, questo sistema è anche poco democratico, perchè se non entri nel “giro giusto” il soft è destinato alla morte binaria, e di conseguenza noi utilizzatori possiamo usare solo quello che i “clan” decidono debba sopravvivere.
Non mi sembra un grande modello di sviluppo, non mi stupisco minimamente che aziende medie di “ferraglia” non producano alcun driver vista la necessità di metterci le mani ogni 4-6 mesi.
Per confronto su un sistema commerciale nei casi più sfavorevoli un driver lo devi aggiornare ogni 2 anni, tempo che quasi sempre rende obsoleta la “ferraglia” sostituita da nuovi modelli. I software, sempre in sistemi commerciali, sono invece molto più longevi comprendendo nell’installazione quasi tutto il necessario.

E pensare a tutte le ore/persona sprecate così anzichè migliorare il software mi mette una certa tristezza.

Il caso preso in considerazione è emblematico, ci sono migliaia di software digitalmente morti per questi motivi e altri moriranno nel tempo.

Annunci

14 commenti

  1. è quello che predico da quando ho aperto il blog, ma se lo dici così ti si da dell’eretico.
    onestamente mi sto rompendo anche di dirlo. e domani è il linux day… che triste

    Commento di LuNa — ottobre 24, 2008 @ 8:00 pm

  2. anche su archlinux un laconico segmentation fault! 😦

    Commento di nameless — ottobre 24, 2008 @ 9:08 pm

  3. condivido in pieno, mi era capitata una cosa simile con Nautilus-Actions

    Commento di grigio — ottobre 26, 2008 @ 1:29 pm

  4. Quelo è l’open source…è una cosa bella, ma allo stesso tempo provoca parecchi problemi e rompicapi.

    Non so quale sia la strada migliore…probabilmente però, se mai Linux sarà sulla bocca di tutti, allora questo fenomeno di continui mutamenti cambierà in qualcosa di migliore.

    Già comunque gestire un parco software e macchine così ampio, scollegato(ma allo stesso tempo legato) è qualcosa di meraviglioso. Linux gira su qualsiasi cosa abbia un processore praticamente. Quindi bisogna guardare a 360°x2…
    Sono in parte d’accordo con te telperion, ma certe cose, almeno per il momento, *devono* essere fatte se si vuole portare Linux ovunque, facendolo uscire dal suo guscio e uso di nicchia…
    La domanda è…ma siamo sicuri che veramente vogliamo questo?

    Ma ad ogni scelta c’è un pro e un contro…
    😉

    Commento di zidagar — ottobre 26, 2008 @ 2:43 pm

  5. @zidagar
    però basterebbe decidere che le librerie devo essere supportate almeno 2 anni, che la libreria nuova se implementa una nuova funzione incompatibile ne cambi anche il nome e mantenga anche la vecchia per compatibilità, oppure tutta la libreria cambi nome (libreria-1) in modo da poter utilizzare più versioni in contemporanea (molti già lo fanno), insomma basterebbe solo un pò di organizzazione e meno anarchia.

    Commento di telperion — ottobre 26, 2008 @ 3:58 pm

  6. su sled e rhel è così, almeno lato kernel cambia solo con la major versione (che bene o male è biennale)

    però rh non è molto interessata al desktop e sled non credo sia diffusissima (vado a naso senza alcun dato, quindi potrei sbagliare)

    Commento di shaitan — ottobre 26, 2008 @ 9:46 pm

  7. si ma su sled e rhel il problema non si pone poichè per tutta la durata della versione non cambia nulla di niente, non solo il kernel (salvo updates di sicurezza)
    quello che credo voglia dire il buon telp è un discorso desktop. fai il confronto tra un leopard o un vista e linux e scopri che quest’ultimo ne esce massacrato per suddetti motivi. tenere aggiornati i software è un gran problema, un desktop è per definizione abbastanza bleeding-edge. ma se mi escono 25 versioni della stessa libreria (che ne so ffmpeg per dirne una) e il caxxo soft non mi compila con la versione tal dei tali allora sono cavoli acidi.
    su un sistema commerciale la versione 1.x di tale soft funziona tale e quale alla versione 5.x, mentre la versione 1.x continua a funzionare anche tra 2 anni. su linux va già bene se lo stesso soft (aggiornato) a parità di distro gira tra 2 mesi :\

    Commento di LuNa — ottobre 27, 2008 @ 7:25 am

  8. Si esatto, mentre il kernel influisce praticamente solo sui driver, le librerie, essendo condivise nel modello linux, coinvolgono moltissimi software ed ogni rottura di compatibilità comporta la necessità di cambiare montagne di codice. Potendo utilizzare diverse versioni della stessa libreria almeno per un certo periodo, potrebbe consentire di limitare molto il problema.
    Non a caso già da un pò di tempo su debian vedo libreria-0a libreiria-1a libreria-1d eccetera che possono coesistere.
    Purtroppo non è un metodo generalizzato.

    Commento di telperion — ottobre 27, 2008 @ 12:06 pm

  9. @telperion
    probabilmente su quello hai perfettamente ragione…è un buon compromesso.

    Commento di zidagar — ottobre 27, 2008 @ 7:30 pm

  10. Io ho sempre visto di buon occhio soluzioni con pacchetti “pronti all’uso” alla macosx per intenderci, ma da quanto ho capito siamo in pochissimi.
    Ad esempio amsn è stato per anni orrendo a meno che non lo si compilasse con le tk/tcl alpha/betal. E io a un niubbo non consiglio di compilare, e non consiglio nemmeno di usare un software i cui caratteri risultino illegibili. E un pacchetto con dentro tutto il necessario sarebbe stato una figata anche per me!
    Questo è solo un esempio, ci sarebbero tanti altri casi in cui sarebbe utile, anche se mi rendo conto non risolverebbe di certo tutti i problemi di linux sui desktop (la cui situazione io non vedo così nera in ogni caso)

    Commento di Reload — ottobre 27, 2008 @ 7:58 pm

  11. @reload: amsn è distribuito da tempo con autopackage. Che poi autoackage è un disastro, questo è un altro conto.

    Il discorso di telperion è un po’ esagerato (nel senso che non sempre capita come dice lui) comunque a volte accade.
    Il fatto è che l’open source, per usare una definizione coniata proprio dall’autore della definizione di Open Source (Bruce Perens) è “un ubriaco che barcolla guidato dalla selezione darwiniana”.

    Probabilmente globus e compagnia bella, stile mac os x, non frega molto.
    Cioè ad esempio a me darebbe solo fastidio e appesantirebbe il già mastodontico nautilus.
    Sì ok, carino ma poi? Finisce nel dimenticatoio come le lookose ed inutilissime screenlets, diventate il must su kde4 (lì le chiamano plasmoidi).
    Risultato: desktop più pesante, non posso manco mettere le icone sulla scrivania, eccetera eccetera.
    Roba buona per pollycoke, non per chi deve lavorare col computer.

    IMHO.

    Commento di guiodic — novembre 3, 2008 @ 2:24 am

  12. @guiodic
    il tuo “sembrerebbe” un discorso sensato, ma in realtà non lo è, è solo un discorso conservatore e minimalista.
    Se cominciamo a vedere cosa serve e cosa no, buttiamo via mezzo sistema operativo.
    Anche l’occhio vuole la sua parte e onestamente di chi usa gnu-linux la maggioranza assoluta non lo usa certo per lavorare, e se riduciamo il pc di casa a concetti come “produttività e lavoro” allora siamo messi male, per la pesantezza è ora di finirla, core2 da 2GHz o più 2GB ram o più che cavolo li comperiamo a fare?
    La libertà è anche fare il pc “bello”, e come opzione la rivendico, come opzione, non imposizione.

    Per la “produttività e il lavoro” ci sono già i tristi pc dell’ufficio, che nel 98% dei casi non montano gnu/linux.

    Commento di telperion — novembre 3, 2008 @ 10:08 am

  13. @telperion: sarà forse che io con pc ci lavoro…

    Commento di guiodic — novembre 3, 2008 @ 11:04 am

  14. A dimostrazione che gli approcci sono svariati.
    La sfida è un pc che funziona bene e con un bell’aspetto.
    In giro non vedo autovetture “brutte” che comunque funzionano bene, segno che l’estetica pur non fondamentale è una componente tutt’altro che trascurabile.
    Anzi spesso proprio l’estetica accattivante, a parita di funzionalità ci fa scegliere questo anzichè quello.

    Commento di telperion — novembre 3, 2008 @ 11:41 am


RSS feed for comments on this post.

%d blogger hanno fatto clic su Mi Piace per questo: