Artemis

Io non schifo l'utenza desktop. Anzi, spesso faccio un uso desktop di Linux e, se non me lo permettesse ammetto che si, sarebbe parecchio seccante. Il punto è che la stessa utente corporate vuole un Linux desktop. Ok, forse non *così* desktop come Ubuntu, ma comunque il 99% del lavoro per il lato desktop c'è già, e non è stato iniziato nè completato per l'utenza di Ubuntu, ma semplicemente perchè anche i power user vogliono stare comodi ed essere più produttivi. Perdonami, ma sarebbe un po' una morte di pulcinella. Linux sui desktop non è un business, e, va da sè, che se muore non ci rimette nessuno. Se qualcuno vorrà renderlo un business, si adopererà per entrarci e per essere competitivo in quel campo. Un po' quello che avrebbe Ubuntu in target, solo che non lo fa. Non muovendo soldi direi che non ha alcuna importanza. E i milioni di utenti di feedback... su cosa? Su Emenese? sull'utility che installa i driver CLOSED nvidia? La documentazione, il feedback, che Ubuntu ha dato dimostrazione di saper generare con la sua utenza, finora, è al 50% how to su come installare i driver video proprietari. Un 20% su installare "salcazzo programma" con Wine, ed il resto di utenti che perdono tempo per rifare pacchetti più nuovi di quelli uffficiali o patchati alla strana, cosa che crea una frammentazione nel software e nelle risorse che funziona che sembra di cercare la soluzione di un problema su Windows. Tu stesso qualche messaggio fa hai dato il merito ad Ubuntu per un software che ha funzionato con wine grazie ad un repo DI TERZE PARTI. Direi che è una cosa che spiega da sola. Proprio un gran bel feedback, nulla da dire. Utile poi.

Forse non è ancora chiaro il concetto che sono i soldi generati da quelli che litigano su quale bugtracker usare a permettere alle persone di installare ubuntu per guardarsi facebook. Niente soldi, niente codice. niente codice, niente novità. niente novità, niente nuovo prodotto. niente nuovo prodotto, niente nuovi utenti. niente nuovi utenti, niente soldi. A me sembra un principio banale, è il ciclo della vita. Tutto nel mondo funziona con questa semplice ed ovvia logica. E non capisco come mai qui ci si ostini a non volerlo metabolizzare. Si dice invece che per il corporate è "tutto un'altro discorso". Cosa che è palesemente falsa peraltro. Linux esiste, sopravvive e migliora solo ed unicamente grazie al corporate, e tutto il resto è una massa attaccata che non rende assolutamente niente ed influenza il lavoro di tutti. Nessuno vuole contare le righe di codice, nessuno vuole fare a gara a chi contribuisce di più. Ma è il corporate a creare il prodotto che gli utenti usano per vedere facebook, è il corporate a migliorarlo, è il corporate a trovare i soldi perchè questo mese dopo mese sia ancora possibile. Il corporate e l'utente del pc-elettrodomestico non sono 2 mondi separati, ma sono esattamente lo stesso mondo: usano entrambi lo stesso prodotto, ed una realtà sopravvive grazie all'altra. Sono realtà assolutamente legate e sincronizzate, e non si potrà MAI guardare alle nuove features di Ubuntu senza tirare in ballo quello che RedHat, o Novell, o IBM, hanno scritto. E' grazie a loro che l'utenza desktop può installare Linux, è grazie a loro che si può usare il pc come un elettrodomestico senza Windows. Se loro smettessero, nessun utente desktop userebbe più Linux. Il linux "alla ubuntu" non sopravviverebbe un solo giorno in più, perchè non è autosufficiente. Io francamente non riesco a capire cosa ci sia di complicato da capire in tutto questo.

Ogni tanto a me sembra di parlare arabo. Sul serio. Ho detto che all'utente deve fregare qualcosa di Launchpad? No. Ho detto che ha una qualche importanza un cosa di questo tipo? No. Ho risposto al "collaboriamo tutti che lavorare separati si perde" facendo notare che chi si fa i cazzi suoi è proprio Ubuntu. Non è un caso se tutti i maggiori business partner nel campo Linux alla Canonical mettero volentieri una bomba in cantina. La sopravvivenza del mercato Linux si basa sul fatto che TUTTI i partner al suo interno sviluppino per tutti, così che ognuno offre servizi e vende soluzioni, ma la base software costa relativamente poco e si evolve rapidamente sul maggior numero di esigenze possibili. Il successo del mercato Linux è questo: velocità a rispondere ai feature request, supporto assolutamente decentrato e concorrenziale, costo del codice infinitesimale a confronto del costo di assistenza o di formazione. E' per questo che il software è libero, e non perchè Stallman ha deciso che il software libero rende uomini migliori. Ubuntu è un difensore che non difende, un attaccante che non attacca. E' una F1 che in griglia scatta il verde e sta ferma. Il mercato Linux ha una sua dinamica, ed Ubuntu è li, bella grande, con una base di utenza notevole (perchè, come dice autodelta giustamente, uno si usa ubuntu a casa e poi al lavoro lo mette sul mail server), ma è completamente estranea alle dinamiche del mercato in cui è inserita. E' estranea perchè non rende un euro a sè stessa, e quindi non vede perchè dovrebbe far rendere un euro a qualcun'altro. Si fa i cazzi suoi, e politicamente fa pure i capricci, introducendo soluzioni sue di punto in bianco e pretendendo che queste siano supportate o che (nel caso di upstart ma non solo) qualcuno spenda tempo e denaro per tappare le cagate fatte. Solo che Ubuntu non è LINUX, Ubuntu è una distribuzione, e sul mercato ci sono competitor più interessati e più capaci. E quindi non si capisce perchè tutti dovrebbero stare dietro ai capricci di una distribuzione che non ha alcun interesse a migliorare Linux. Ti assicuro che dal punto di vista dei servizi Ubuntu è una badilata nei coglioni. Metti che sei una azienda X che vende soluzioni su Linux. Sei business partner storico di RedHat, di Novell, di IBM, di SCO, di Oracle, di Sun Microsystem. Arriva una azienda random e dice "ho bisogno di consulenti per lo sviluppo di un software interno", al che butti su il progetto interno, selezioni i consulenti e li metti dal cliente. E gli dici "ehi cliente, integriamo i nostri ambienti di versioning e di ticketing, così possiamo gestire la cosa in modo flessibile". Ovviamente tu, azienda X, sei business partner di tutta questa gente, e quindi, lavorando con loro, tutto il tuo ambiente aziendale si basa su Git e su Bugzilla. perchè TUTTI usano quelli, perchè sono lo standard, perchè sono una cosa sviluppata DA tutti e PER tutti, che matcha qualsiasi esigenza. Il cliente però ti risponde, "ok dai, noi siamo SVN e Launchpad, sai, abbiamo tutte le infrastrutture Linux su Ubuntu, sai era così facile che abbiamo migrato i client senza problemi e poi a quel punto abbiamo portato anche i server". Ovviamente non c'è UN CAZZO di compatibile con niente di quello che tutti gli altri usano. Cosa gli vuoi dire a sta gente? Oltre a riempirla di bestemmie, ovviamente. PS: it really happened, ma non posso fare nomi.

Mi verrebbe da dire che la faccia ce la mette solo il buon Mark perchè in effetti gli altri nel frattempo stanno lavorando per permettergli di mettercela. Quanto al divisi su tutto, mi trovi abbastanza d'accordo. Non bisogna essere divisi, altrimenti è uno spreco di risorse. Ma chi sono veramente quelli divisi? Chi ha buttato nel cesso uno dei progetti più promettenti degli ultimi 6 anni, init-ng, per sviluppare il suo proprio cessoso sistema, upstart, progettandolo in modo da non essere minimamente retrocompatibile con sysvinit? E chi ha dovuto invece praticamente riscrivere upstart per permettere a tutte le distribuzioni di usarlo, ubuntu compresa? Meglio che non lo dico, va, sarei ridondante. Chi, in un mondo in cui esiste bugzilla, sviluppato e patchato da tutto il mondo, ha sviluppato il proprio di sistema di bug tracking, launchpad, che non va bene praticamente a nessuno? Chi, ha il record assoluto mondiale di patch di gnome respinte perchè non conformi alle linee guida gnome, e comunque implementate solo nella propria distribuzione? Chi ha esteso il formato deb con dei check sulle dipendenze che funzionano solo con una versione patchata internamente di aptitude, ed ovviamente è una cosa che non interessa ad un accidente di nessuno, dato che serve solo per salvare gli anelli di dipendenze dal fatto che i pacchetti di tale distribuzione sono fatti col culo? Chi ha buttato nel cesso il backend deb di PackageKit, per svilupparne uno proprio, sempre per il suddetto motivo? Potrei andare avanti altre 4 pagine sto forum con esempi del genere, e non li conosco nemmeno tutti, ma solo i più famosi. Perdonami, ma te la dico io la verità. Su cosa campa lo sviluppo e l'innovazione di un sistema? Sugli utenti? No. Definitivamente no. Campa sui SOLDI. Se generi soldi puoi spenderli per migliorare il prodotto. Funziona così la Microsoft, la Apple, la Fiat e anche TUTTO il mondo Linux. La differenza è che mentre per Apple e la Microsoft l'utenza desktop è un aspetto business-critical (che significa che se viene meno loro vanno gambe all'aria più rapidamente del tempo che impiego io a finire questa frase), per Linux e per le aziende ad esso legate è un aspetto completamente accessorio. Il sistema Linux nel suo complesso si autoalimenta, investe, paga, si migliora, innova e si diffonde, anche, SENZA il settore desktop. Se facciamo il conto delle cose che se non ci fosse stata l'utenza desktop, il target di Ubuntu, non sarebbero state come sono ora forse riusciamo ad usare entrambe le mani. Forse non avremmo Wine, forse non avremmo i giochi sviluppati sul motore di Quake 3, forse non avremmo 140 client di messanger che promettono tutti di supportare la webcam entro la prossima release. Ma è tutto qui. Cinelerra era pensato per l'utenza professionale, come Gimp, come perfino Compiz, pensato per introdurre nuove regole di usability e rilasciato inizialmente su una distro per enterprise workstation, che era NLD. Ergo, per dirla proprio alla buona, e per quanto sia dura ammetterlo e scomodo da accettare, l'utenza desktop non serve ad un beneamato cazzo. Non rende un fottuto euro neanche per sbaglio. E la realtà è soltanto questa e nessun'altra. Non è una questione di opinioni, è una questione di bilanci di esercizio. Però è anche vero che in un business ci entri con prodotto VALIDO e COMPLETO. Cosa che Ubuntu non è e che, evidentemente, non ha alcuna intenzione di essere. Va bene metterci il faccione, ma bisogna metterci anche i soldi e, soprattutto, il prodotto, perchè senza quello non si va da nessuna parte. Ubuntu usa i soldi per fare del marketing su un prodotto non suo, e non usa i suoi stessi soldi per rendere il suo stesso prodotto più valido. Ubuntu vuole essere il Linux per il desktop, quello vero, quello per tutti? Per intenderci, anche Fedora è una distribuzione "desktop", ma poi in realtà ci sono più datacenter che pc al mondo che stanno su con Fedora. Se Ubuntu non vuole questo ma vuole essere l'alternativa VERA a Windows e Apple, DEVE rimboccarsi le mani ed usare i suoi soldi ed i suoi sviluppatori per MIGLIORARE il suo prodotto, per innovare nel suo campo, e non cambiare un file di configurazione o un tema grafico e poi fare del marketing. Questo è un forum di automobili, e quindi mi aspetto che i suoi utenti lo sappiano particolarmente bene: puoi fare tutto il marketing del mondo, ma se il tuo prodotto fa cagare non va da nessuna parte. Come ha fatto Fiat a migliorare la sua condizione e ad uscire dalla crisi? Ha fatto del marketing? No. Ha fatto delle macchine migliori. Poi, quando aveva le macchine migliori, ha fatto del marketing. Ubuntu si comporta così? No. Quindi Ubuntu brucia soldi, quindi Ubuntu è dannosa per la comunità, per il sistema Linux ed è LEI la vera voce fuori dal coro, quella che vuole essere separati e farsi ognuno i cazzi propri come i bambini dell'asilo. Perchè alla fine è lei, storicamente, che si è sempre fatta i cazzi suoi. E non si capisce perchè chi con Linux ci sfama la famiglia debba stare dietro ai capricci di una distribuzione che non rende un euro a nessuno. Seriamente, i moralismi sul "lavoriamo tutti insieme basta darsi sempre contro tutti contro tutti" detti da un utente Ubuntu, francamente sono cose che non voglio sentire.

E' una giusta obiezione. E' chiaro che spostandosi la visione strategica di un progetto da "la tecnologia usata" a "il tempo che tale tecnologia mi fa risparmiare", diventa strategica la scelta della tecnologia su cui migrare. Oggi la scelta di migrare ad una tecnologia inadeguata si paga molto più di, per esempio, un palese errore delle specifiche di un software.

Facevo un po' di filosofia. World of warcraft nello specifico usa una complessa struttura di db, che ormai è più o meno simile in tutti i vari emulatori. Tuttavia quelle nel db non sono le uniche informazioni di cui tenere conto. Strano, a me sembrava che usare tecnologie inadeguate fosse una cosa che non porta a nulla. Ripeto, ed ormai avendo perso buona parte del buon umore e dello spirito costruttivo che avevo qualche messaggio fa: una tecnologia è un mezzo, non un fine. Se imparare una nuova tecnologia mi permette di risparmiare anche solo 5 minuti (ma 5 minuti sul serio, non in senso figurato) rispetto ad usarne una già consolidata, non ho più ALCUN motivo per usare quella vecchia. Ergo, non devo più farlo. punto. Così è, ed è ciò che il mondo dell'informatica sta chiaramente dimostrando. Qualsiasi opinione contraria a questo è legittima, ma finirà necessariamente nelle ortiche con il tempo. E questo non è un discorso che non porta a nulla ma, anzi, l'unico discorso sensato su questo argomento. Il resto sono solo seghe mentali, con tutto il rispetto.

Guarda, non posso parlare di dettagli di quello che sto sviluppando, non ancora perlomeno, anche se poi diventerà software libero a sviluppo completo. Però posso dirti che le persone con cui lavoro sono dei maghi del non reinventare la ruota. Gli ho visto fare dei copia/incolla veramente estremi. Il punto del prodotto che stiamo sviluppando, quindi, è che non esiste veramente nulla di simile. Lo stesso principio di ciò che era stato richiesto dal cliente, ovvero un cms che fosse amministrabile direttamente mettendo e togliendo file dalle sue directory, non c'era in commercio. Partendo quindi dall'idea del cliente abbiamo deciso di "generalizzare" la sua idea e trarne fuori un prodotto che potesse anche sopravvivere autonomamente. Non so dirti riguardo al successo o meno dell'applicazione, dato che sicuramente non è un applicazione per un target utente (non è un joomla o un drupal, o phpbb, con cui ti fai il tuo sito, non c'entra niente), ma adatta ad un ambiente enterprise, ma quello che volevo semplicemente dire era portarlo come esempio di qualcosa che viene realizzato scegliendo la tecnologia più comoda per ogni aspetto, senza rimanere necessariamente ancorati ad una con cui si vuole fare tutto a tutti i costi. Si chiama programmazione agile proprio per quello, alla fine. Perchè è agile

Che io sappia non esistono librerie xml per c++ che mi permettano di scrivere e leggere in un xml con la sintassi usabile per una mappa. Si parla sempre di cose molto più complicate. Poi per carità, magari hanno sviluppato una libreria che con def variabile = nomeOggetto?.key?.subkey mi permette di leggere un marker xml come una value di un json come un index sql, facendomi il safe navigation nella struttura e tornandomi un null al primo notFound anzichè spararmi un eccezione. Ma se c'è, io non la conosco. E se non c'è, userò un linguaggio più adatto per fare quella cosa, perchè con il C++ perdo tempo e cervello facendo in modo più complicato una cosa che potrei fare in modo più semplice.

Suvvia, non è un discorso di "potere economico". E' qualche riga di codice, un paio di plugin. E' chiaro che canonical non può influenzare adobe a creare programmi per Linux, ma sviluppare un plugin per firefox che implementi un api estrena per i menu quello si, può farlo. Ripeto, mi sembra che pecchi un po' di elasticità. Ci sono molte sfumature, e c'è modo e modo di fare del proprio meglio a molti livelli diversi. Il fatto è che Ubuntu non lo fa. Guarda, uso fedora per sviluppare, e sto facendo andare con Wine tutti i test che mi servono per provare il softwae su windows. Internet Explorer per esempio, o il pacchetto .NET. Roba proprio microsoft, roba che prima di andare su Wine può calare la madonna dal cielo. Quale è stata la mia immane procedura da power user? www.microsoft.com -> download pacchetto redistribuibile -> doppio click -> enjoy. Quella che piuttosto mi sembra si spacci per facile e friendly e "tutto out-of-the-box", quando in realtà usa la stessa identica merda che usano tutti gli altri è Ubuntu. Con ogni probabilità i tuoi problemi di wine dipendevano da una diversa versione di Wine tra ubuntu e fedora, e decisamente non da una chissà quale magggica implementazione di wine in Ubuntu. Anche perchè non c'è nessuna magggica implementazione. Sono gli stessi fottuti file di configurazione, commentati anche nello stesso modo, che stanno nella stessa /usr/qualcosa e che si copiano nello stesso modo in .wine la prima volta che clicchi su un exe.

Vedi la cosa senza la dovuta elasticità. Non ho detto che Ubuntu dovrebbe investire 400 sviluppatori per un anno e rifare il kernel. Non mi sogno nemmeno di pensarlo. Ho semplicemente raccolto un esempio di una feature (quella del menu nel pannello di gnome) che è stata scelta, implementata, la si paventa come novità, ma in realtà non ci si è curati di farla funzionare davvero bene, perchè ovviamente non tutte le applicazioni ci stanno. Si poteva sviluppare qualche riga di codice per rendere la soluzione veramente coerente? Si. E' stato fatto? No. Ubuntu mi ricorda quelle distribuzioni dello staff di staminchia di ragazzi universitari che vogliono la loro distribuzione linux. "Cavolo ho visto una soluzione fikissima ma funziona nel 50% dei casi. Vabbè sticazzi la mettiamo lo stesso perchè è fika." Ubuntu non sviluppa un cazzo per la comunità, e fa male. Ma vabbè, ci si è fatto il callo. Ma ubuntu sviluppa poco e male anche per sè stessa, e non è la prima volta che capita. Se ubuntu vuole ciuppare utenti da MS ed Apple non può fare come fa. Perchè Windows e MacOS sono *perfetti*. Perfettamente coerenti nello stile, nelle funzionalità, ed in tutte le caratteristiche di usabilità. le loro features visive scalano correttamente con le applicazioni rilasciate con loro e per loro, e se non è così fanno il culo a chi produce software finchè non si adegua. Perchè se decidi che c'è un aspetto che conta più degli altri (l'usability, il rapporto con l'utente, che poi è la base necessaria per un largo utilizzo) usi le risorse per rendere questo aspetto assolutamente esente da critiche, ed ottenere la massima funzionalità. Ubuntu lo fa? No. neanche per il cazzo, neanche per sbaglio. Potrebbe farlo? Si. Non sono 4 ragazzi, hanno tutte le risorse, in termini di soldi e persone. C'è chi fa di più con Meno. Ricordo Novell Linux Desktop, la versione di SuSE per il mercato professionale, che aveva praticamente rifatto l'80 dell'interfaccia pur di dare una coerenza di funzionalità a TUTTE le applicazioni che erano nel suo target. Ecco perchè Ubuntu è una distro dilettantistica. Ed è ecco perchè non va presa in considerazione: non perchè spinga a prendere utenti dagli altri sistemi e quindi punti tutto sulla facciata, ma perchè, anche questa cosa, la fa poco e male.

A dire il vero è un progetto dalla struttura *estremamente* pulita, e completamente modulare. E' manutenibilissimo, sviluppabilissimo, e io stesso l'ho conosciuto con il framework già finito al 99%, e con pochissimo adattamento mi sono sincronizato con i miei colleghi e sono andato avanti. Ogni parte, a seconda di quello che fa, è realizzata con la tecnologia migliore. Lo sviluppo in locale e compila e deploya su jetty in pochi secondi, ma lo sto testando su jBoss con un paio di centinaia di utenti fittizzi che eseguono operazioni cotemporaneamente su istanze di cms diverse e scala perfettamente. La macchina su cui gira? una Centos virtuale con 512mb di ram ed una cpu sola. Fossero fatti tutti così, i software, il mondo sarebbe un posto migliore. Invece l'altro giorno volevo mettere le mani a Trinity Project, che è un emulatore per World of Warcraft, per dare una mano ad un amico che ha uno shard privato. Ebbene, vagonate e vagonate di file in C++, codice scritto con 5 stili diversi (per il C++, lo ricordo, lo permette. altri linguaggi, come il python o il roby, no.) e quindi completamente incomprensibili. Nessuna modularità, con le formule, posizioni assolute degli elementi, punti di spawn e chi più ne ha più ne metta schiantate nel codice. La prima cose che volevo fare era tirare fuori tutte le formule e i campi di match delle spell in file XML. Però poi mi son detto: no wait, questo è C++, come cazzo me lo gestisco l'XML in maniera furba? Risposta ovvia: non me lo gestisco. Motivo per cui lascerò quella porcheria immane al suo destino

Ci sono un delirio di cose autoctone. Molte più cose autoctone prese dal libero ed importate nei sistemi commerciali che il contrario. Ma con un rapporto oserei dire imbarazzante. Tuttavia non sono cose che riguardano l'usability (o almeno, molto raramente) e quindi non sono cose su cui spingere con il marketing, specie di ubuntu, visto il target a cui si rivolge. Certo è che poi si potrebbe anche spingere ed innovare, e c'è chi lo fa. Ma non è Ubuntu.

Evidente. il menu sul pannello superiore è una funzione di gnome, ed è ovviamente supportata da tutte le applicazioni gnome-compliant. Essendo che non tutte le applicazioni lo sono, e anzi, alla fine non sono nemmeno molte, tale scelta si rivela essere un epic fail. Aggiungo: non parliamo di qualche strana interfaccia grafica di Oracle, ma di applicazioni perfettamente libere e passibili (almeno chrome, firefox e openoffice) di motori di plugin piuttosto potenti. A sviluppare degli addon che cambiassero la gestione del menu ed integrarli nell'installazione di default non dico che non ci voleva un cazzo, ma quasi. Anzi, se non sbaglio qualcosa del genere per firefox esiste già, senza considerare che il codice della versione per Mac di Firefox è li disponibile. Invece no: come al solito Ubuntu mette gli sfondi belli, i pulsantini fighi, le barre con il chiudi a sinistra, ma poi non impiega 3 sviluppatori per 4 giorni per sviluppare un paio di plugin che non facciano sembrare tutto una cagata spruzzo-atomica. Passano le versioni, ma Ubuntu non cambia, alla faccia dell'Ubuntu Music Store (ma sviluppare un supporto ad Apple Music Store per i vari banchee/exaile/rhythmbox no? tra l'altro parte dell'infrastruttura già esiste...) continua ad essere una distribuzione VERAMENTE DILETTANTISTICA. Una distribuzione con soldi e risorse che butta in release soluzioni grottesche invece che investire in un miglioramento delle funzionalità del software libero imho non è nemmeno da prendere in considerazione.

Più che altro ci ditta ci abbiamo già dato un'occhiata, ed è opinione comune (non mia eh, ma di chi gira con iphone e macbook pro) che è un sdk praticamente demenziale, e che tantissime cose potevano essere semplificate. Infatti il primo obiettivo quando entreremo in quel business sarà sviluppare internamente una serie di "librerie d'appoggio" che possano operare da framework per poi mettersi a sviluppare piangendo un po' meno. Non abbiamo ancora chiaro *quanto* l'sdk di Apple ci permetta di farlo, ma l'idea è quella. L'idea è che le tecnologie cambiano e si evolvono così rapidamente che ormai dire "conosco quella tecnologia" ha perso completamente significato. Nell'ambiente dove lavoro (che essenzialmente è fornitura di servizi su linux, quindi formazione, sviluppo di applicazioni, soprattutto in ambente distribuito, per internet o datacenter, sistemistica in generale a livello enterprise, tipo xen o puppet) ormai non ci si pone nemmeno il problema di "conoscere" una tecnologia che ci si appresta ad usare. Praticamente all'approccio di un nuovo progetto si vedono un po' i requisiti di massima e si guarda la documentazione delle varie tecnologie disponibili quella più agile per quei requisiti, e poi via di extreme programming. Non è infrequente cambiare tecnologia in corsa o mergiarne più di una per ogni particolare parte del progetti. Ti faccio un esempio: su 4 progetti che su cui ho messo le mani ci sono 4 container per il deploy diversi. In 3 casi sono application server, jBoss, Jetty e WebSphere, ed il 4° è deployato direttamente su apache+tomcat. Di questi, uno è tutto java puro, uno è java+GWT, uno è in python e l'ultimo, che su cui sto mettendo le mani proprio in questi giorni, ha 3 livelli. un backend in java che implementa un framework e la security, un middle-end (o come vuoi chiamarlo) fatto essenzialmente tutto in groovy, fatto da script che fanno classloading a vicenda, completamente stateless, che, usando il framework, gestisce una o più webapplication che stanno su a xhtml+jQuery. L'obiettivo del framework java è di fungere da "generatore" di cms (oggetti tipo drupal o joomla), permettendo ai cms progettati sopra di lui di astrarre completamente il livello del filesystem. Praticamente il cms progettato sopra dovrebbe gestire la comunicazione e l'accesso con i dati tramite la definizione di una serie di metadati in formato JSON, senza accorgersi di scrivere su filesystem, o su database, che siano entrambi locali o remoti. Io personalmente sto sviluppando al momento un particolare cms per il cliente e lo sviluppo va di pari passo con il framework, li stiamo facendo crescere insieme: sviluppando l'applicazione lato web capiamo che "facility" ci deve fornire il framework, e le implementiamo. Perdona la lunghezza, e magari non te ne fregava nulla, ma capisci che ragionare a "ah che bello il c++" lavorando a questi livelli di astrazione vuol dire che ti esplode la testa istantaneamente XD Ed ecco perchè l'sdk di apple mi sembra (e, francamente, è) esageratamente a basso per il tipo di applicativo che deve realizzare

Ma anche si. Ovviamente è una questione di obiettivi. Se voglio inizializzare una connessione ad un database, fare la query di una colonna su una tabella, scegliere tutte le occorrenze univoche dal result set ed operare una sorta di operazione su ogni elemento di esso, che so, il replace di un carattere, con groovy lo faccio in UNA riga di codice. Prova a farlo in C++. Certo è però il giorno in cui dovrò rilocare un'area di memoria non andrò certo ad usare groovy. Userò C++. Il punto quale è quindi? E' chiaro che i linguaggi "alla vecchia" non possono morire, perchè ci sarà sempre da fare qualcosa *a così basso livello* da richiederli, dato che l'hardware è sempre hardware. Ma, onestamente, quante volte capita nella propria vita di fare una query su un db ed elaborare il result? e quante volte di rilocare a mano una pagina di memoria? La prima tipo 20 volte al giorno, la seconda mai, visto che nei sistemi operativi moderni la memoria è protetta rispetto ai processi in userspace. Quindi, a meno di non essere parte del 2% dei programmatori al mondo che pilotano direttamente hardware, direi che mettersi a sviluppare, al giorno d'oggi, un progetto di alto livello facendo uso di un linguaggio che non ha nemmeno un metodo per estrarre direttamente le occorrenze esclusive da una lista, è semplicemente una cosa da fuori di testa. Bisogna veramente volersi del male per farlo. Ho sviluppato con tecnologie ad alto e a basso livello, ho usato ide da VIM a IntellJ Idea. Ho un lungo passato da flamer su argomenti like "sesso degli angeli" dell'informatica, tipo design di kernel, ambienti di sviluppo o linguaggi e framework. Sai che ti dico? Che i megaespertoni si azzuffino su questi argomenti è una cosa che ormai mi diverte. Queste persone sono *affettivamente* legate alla loro tecnologia preferita, e per questo argomentano il loro sentimento con disquisizione tecniche. Lo ero anche io. Il punto però, è che non c'è sentimento: parliamo di informatica, cioè, alla fine matematica. La matematica non ha sentimenti. Ha requisiti, obiettivi, approssimazioni, risultati. La realtà è che io preferisco la tecnologia che mi permette di realizzare più facilmente quello che devo realizzare. Devo realizzare applicazioni per un ambiente di cloud computing? Userò python, o groovy, o qualsiasi altro strumento mi permetta una programmazione agile senza distinzione tra locale e remoto. Devo programmare un kernel? userò il C o il C++. Devo programmare un kernel ma qualcuno ha inventato un framework che se scrivo list.sort() lui mi scrive il codice C per un bubblesort? userò questo framework senza pensarci 2 volte. Ma qui si parlava di Apple iPad, e di un ambiente in cui si sviluppano applicazioni che devono mostrare icone, colori ed effetti di fade. Ergo, francamente, la Apple la sua specie di C++ o Objective-C o come minchia vuole chiamarlo (e tra un paio di mesi mi toccherà svilupparci, lo so già), se lo può mettere in quel posto, perchè evidentemente a pensare un SDK in questo modo bisogna avere qualche problema mentale.

Ma saltasse per aria quel catramone del C++ Ormai, vista la potenza di calcolo delle odierne macchine, linguaggi tipo groovy o python (ed i loro binding, ed i loro web toolkit), offrono gli strumenti più agili e flessibili in circolazione. Altro che C++... si ottiene software molto più pulito, più sintetico nella stesura, e, di conseguenza, più facilmente manutenibile e debuggabile

All hail to Tommitel. Sto andazzo di "Alonso sempre e comunque" mi sta iniziando a rompere i coglioni.

Mica tanto chissenefrega. Megasoldoni per un dispositivo che, oltre ad avere le funzionalità di un lettore mp3 ha anche l'hardware di un lettore mp3. In più la consapevolezza che è un dispositivo senza alcuna aria sopra la testa. E' un dispositivo embedded, non un pc nè un netbook, e pertanto non salerà minimamente verso l'alto.

Uh caspita, il campionato per le macchine che non si riesce a far andare forte

Boh, io il NAG-5 ce l'ho sul classe E 270cdi, e secondo me è un cambio davvero schifoso.

E sappi che si può indentare ancora in di più... possiamo fare l'offtopic dell'offtopic dell'offtopic

Piove, governo ladro?

Non capisco che intendi. L'assembler è un linguaggio di traduzione binaria diretta della cpu. A meno che si tratti di processori che disegnano finestre con direttive di registro non ho seriamente capito cosa intendi per "parti grafiche". Per hard realtime si intende semplicemente che una volta lanciata un operazione di cpu questa deve assolutamente terminare entro un tempo preciso stabilito a priori. E' un requisito piuttosto ovvio se pensiamo alle transazioni: un timeout, un interrupt che blocca la preemptio dell'operazione, e questa potrebbe slittare, andare in timeout per indisponibilità della risorsa di destinazione e quindi si perderebbero dei soldi nel nulla. Poi ovviamente tutto si integra e si aggiorna di notte perchè la ridondanza di tutto è essenziale

Lollissimo stocavolo. 1) assembler è effettivamente il best in action per l'hard realtime. E' che non conviene svilupparci se non su piattaforme particolarissime. 2) lo dico perchè ci ho lavorato. in feature request la maggiorparte delle infrastrutture bancarie richiedono l'hard realtime. Aggiungo: spesso sono sistemi a lotti.

Non è che sia poi così intelligente come sistema... hai idea dell'overhead che ci si trova in fase di passaggio da un servizio emulato ad uno nativo sviluppato per la migrazione? I sistemi bancari sono per la maggiorparte hard-realtime. Posso solo immaginare cosa vuol dire emularli, e poi posso solo immaginare cosa vuol sviluppare quelli nativi con il tempo (che tra l'altro sfruttino la stessa base di dati, perchè quella non puoi sostituirla emulandola) e sostituirli a quelli emulati in un tale ambiente.