On Mon, 7 Nov 2011 11:08:55 +0100, Francesco Paolo Lovergine wrote > Tu m'hai provocato e io me te magno: > > <flame> > > Una inutile perdita di tempo (vedi Grass e non solo) e una > sostanziale zappa sui piedi. > > Ci sono gli standard e devono essere seguiti, punto. > Andare dietro a sistemi operativi che se ne *fottono* degli standard > e si creano le proprie specifiche con il *precisco scopo* di creare > dei lock-in per gli utenti e developer significa perdere un mucchio > di tempo e dare agio a continuare a fare le cose come gli pare a chi > ha interesse a mantenere questi lock-in. > --- cut --- > Sviluppare multi-piattaforma in modalita' nativa oggi e' un massacro > a causa delle bad-practice in tal senso di casa Microsoft ed Apple > (spero che zio Steve stia bruciando all'inferno per questo). >
<add_fuel_to_the_fire> sacrosante parole: e' vero, questi OS proprietari "fanno apposta" ad implementare lock-in artificiosi che servono solo a rendere difficoltose ed onerose le migrazioni cross-platform. anche quando non ve ne sarebbe assolutamente nessuna necessita' tecnica che possa giustificarlo. e non dobbiamo *mai* perdere occasione per ripeterlo, fino allo sfinimento .... </add_fuel_to_the_fire> <reality_check> pero' e' anche vero che poi il kernel di questi OS supporta comunque un layer di compatibilita' POSIX ragionevolmente decoroso; in particolare, il kernel di Mac Os X e' un kernel POSIX a tutti gli effetti (OpenBSD) il kernel di WinOZ ... boh, chissa' come/dove nasce: ma anche lui ha il suo livello POSIX (fatto male, spesso non del tutto conforme, eppure esiste). se chi scrive sw tenesse sempre nella debita considerazione la compatibilita' a livello POSIX le migrazioni non sarebbero necessariamente "sanguinose" (almeno, questo vale per i moduli "core", le librerie etc). spesso i "bagni di sangue" nascono anche grazie a quei developers che per "sentirsi fighi" usano indiscriminatamente a man bassa tutte le features "ultimissimo strillo" possibili ed immaginabili (anche quando non ce n'e' alcun bisogno), mentre si potrebbe facilmente scrivere lo stesso esatto codice in modo assai piu' facilmente "portabile". per quanto riguarda le interfacce grafiche, esistono ottimi moduli realmente cross-platform: Cairo, wxWidgets, Qt. peccato che svariati packages non li usino, e quindi si legano mani e piedi a X11, a Gnome o piuttosto a KDE. con conseguente proliferazione indiscriminata di doppioni e triploni: di cui nessuno sinceramente sente il bisogno, neppure su Linux. idem c.s. per la gestione delle connessioni network: libcurl consente di lavorare in modo assolutamente trasparente su tutte le piattaforme; ancora una volta, peccato che molti moduli non la usano e vanno direttamente sui BSD-sockets idem c.s. per i thread: esiste pthreads, che e' tranquillamente cross-platform. perche' insistere ad usare i thread "native" di Linux ? insomma, diciamocela tutta: per alcuni packages fare un porting cross-platform e' praticamente impossibile perche' sono "scritti apposta" per girare su Linux a volte addirittura, su di unica e ben precisa distro-versione. questo non ha nulla a che fare con il sw libero: questa, per chiamarla col nome che merita, e' semplicemente sciatteria professionale. </reality_check> > Usare Cygwin e' una mezza soluzione perche' questo tipo di layer > dovrebbero essere nativamente disponibili e *pienamente* supportati > nei sistemi proprietari. > Che guarda caso non hanno alcun interesse a farlo, anzi hanno > interesse a rendere la cosa piu' difficoltosa possibile. > <reality_check> Cygwin direi che ormai e' decisamente superato: oggi abbiamo MinGW + MSYS che supportano un piu' che decente dev-env standard su WinOZ [gcc, make, configure, tar, vim, nm ...] ed esiste anche MinGW64; entrambi funzionano perfettamente, anche come cross-compilers. per capirsi, non serve neppure avere un PC Win; si puo' ottenere un eseguibile Win anche direttamente su Linux ;-) dei due "nemici storici" direi che sotto questo profilo e' decisamente peggiore Mac: dove esiste solo X-Code, che in pratica e' un gcc standard, ma tutto infarcito di robazza Apple. il dramma di X-Code e' che l'unico modo per averlo e' di registrarsi sul sito Apple (macchinoso), e poi fare un download pesantissimo di oltre 1GB. perfettamente inutile, perche' quello che serve realmente e' il solo gcc: tutto il resto sono robazze GUI ed IDE Apple-only. (ovviamente da *non* toccare, neppure con le pinze, tutta roba tossico-nociva che ammazza qualsiasi portabilita') BTW non capisco neppure come questo sia possibile, visto che gcc e' free; eppure Apple e' riuscita perfettamente a "sequestrarlo" all'interno di X-Code, che piu' chiuso e proprietario di cosi' non esiste nulla al mondo. </reality_check> <anti_flame> io personalmente non ho nulla contro chi cerca di sviluppare sw free in modo facilmente portabile e cross-platform (btw ho il piacere di appartenere personalmente a questa categoria). IMHO sono ottime iniziative, che facilitano di gran lunga la penetrazione di massa del sw libero, e che in ultima analisi servono anche a rendere meno traumatica una eventuale transizione "liberatoria" su Linux. Ormai la lista dei packages tranquillamente "anfibi" e' molto lunga (e spesso di gran successo): da FireFox ad OpenOffice, senza trascurare Gimp, Apache, PHP, PostgreSQL, MySQL (e magari anche SpatiaLite); girano tutti indifferentemente su qualsiasi piattaforma. certo, spesso su Linux "girano meglio" :-D verosimilmente ha contribuito piu' il solo FireFox alla diffusione di massa del sw libero di tutti gli altri messi assieme (seguito a ruota da OpenOffice). rilancio un elemento assai interessante presente nel post iniziale che ha scatenato tutto il thread: Gnumeric e' probabilmente lo spreadsheet migliore, piu' accurato e piu' professionale che oggi ci sia in circolazione. ma gira solo sotto Linux: e questo lo relega in una posizione assolutamente marginale in termini di diffusione. e' stata una scelta strategica veramente saggia ? o sul lungo temine e' stato piuttosto un regalo insperato fatto ad M$ Excell e che ha finito col favorirne ulteriormente la diffusione di massa ? </anti_flame> <final_flame> io personalmente invece focalizzerei decisamente l'attenzione su due fenomeni che giudico malcostume: a) perche' mai un numero sempre maggiore di progetti OsGeo quando occorre un porting su WinOZ usa il compilatore proprietario M$ MSVC ? [vedi OsGeo4W) intendiamoci, non c'e' nulla di male: anche splite rilascia i makefile.vc per nmake, costa ben poca fatica, e magari a qualcuno serve. ma quello che invece trovo poco accettabile e' che un'organizzazione che (almeno in teoria) dovrebbe impegnarsi in prima linea per la diffusione del sw libero poi va di corsa ad utilizzare di preferenza strumenti "closed" e proprietari, quando invece esistono strumenti genuinamente free (ed assolutamente standard) come MinGW che possono fare egregiamente lo stesso identico lavoro. evidentemente, qua si che siamo di fronte ad un brutto segnale di "subalternita' culturale". b) vedo un gran proliferare di sw GPLv3 (oh yes), che pero' gira solo sotto .NET a me pare decisamente una brutta contraddizione in termini: che senso ha fare sw libero che pero' per girare richiede necessariamente una (ed una sola) piattaforma proprietaria ? </final_flame> ciao Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 540 iscritti al 4.11.2011
