Android non è adatto al mercato enterprise?

Ma allora decidete cosa volete? la compatibilità col passato che comporta evidenti problemi o la modernità? e poi si possono seguire molte strade una è quella di tecnologie tipo apple con rosetta, o si possono utilizzare cose non compilate(vasta scelta), comunque in genere se io faccio un applicativo o scelgo di farne uno alla windows XP o pianifico fin da subito che quell'applicativo in futuro deve girare su diverse versioni dello stesso os. Se un applicativo non è pesante si può scegliere la strada del non compilato(java, python ecc) o si pacchettizza una versione che gira con il suo windows coetaneo in una immagine bella e pronta per VMware-Player e simili.
Se un software è vecchio di solito richiede una frazione della potenza di un a macchina moderna e la virtualizzazione va a pennello, se è un software che richiede molta potenza allora è un sw impotante e allora solitamente viene aggiornato .
Io non vorrei mai avere un sistema che si porta dietro tutta la compatibilità per far girare 2 gestionali e simili(che sul lavoro sono tanti e contano), ma preferisco un OS moderno e veloce, perchè non si porta compatibilità con la preistoria dietro, e il gestionale(o quelllo che è lo faccio girare dentro una macchina virtuale con win98 o dos(parlando di desktop altrimenti si prospettano altre situazioni).

EDIT

Voi cosa preferite?

Il discorso della retrocompatibilità non funziona cosi. Guarda bene questa immagine:

Link ad immagine (click per visualizzarla)

L'intero kernel, l'executive e tutte le funzionalità di Windows sono isolate dalle applicazioni tramite un livello di astrazione.
Le applicazioni non accedono direttamente alle parti interne ma chiamano le loro funzionalita tramite delle API ben definite che non cambiano mai.
Questo significa che alla Microsoft possono cambiare quando vogliono il codice interno di Windows, possono migliorarlo, renderlo piu veloce, possono cancellare e riscrivere tutto e alle applicazioni non cambia niente.
Questo permette di poter evolvere il sistema velocemente ogni volta che si desidare, in quanto la modifica di un componente interno non costringe ad aggiornare tutte le applicazioni che usano quel componente. L'astrazione e l'isolamento tra i vari moduli di un programma è una cosa essenziale.

Da XP a Vista hanno fatto un lavoro imponente e importantissimo: hanno riscritto milioni di righe di codice da C a C#, rendendo il sistema piu mantenibile e piu sicuro, e potenzialmente piu veloce grazie alla possibilita di implementare piu facilmente algoritmi piu efficenti, senza che questo intaccasse il funzionamento delle applicazioni.
Come si vede non è vero che la retrocompatibilità col passato comporta evidenti problemi con la modernità, anzi.

Su Linux invece non è cosi, il fatto che non c'è un'unica interfaccia di programmazione stabile e fissa che comprende non solo il kernel ma tutte le funzionalita di base che un OS deve offrire fa in modo che ogni cambiamento si ripercuote anche sulle applicazioni. Se uno vuole fare una modifica che non è trasparente alle applicaziioni deve modificare anche le applicazioni che dipendono dal componente che viene modificato, e puo essere anche un grosso lavoro e di sicuro rallenta lo sviluppo. Mentre su windows il problema non si pone visto che le modifiche interne sono trasparenti alle applicazioni e quindi possono evolvere e modificare quello che vogliono molto piu rapidamente con meno lavoro e meno camplicazioni.

Inoltre l'uso di linguaggi managed come Python o Java non risolve il problema, perche non basta che il codice venga eseguito ma dipende anche cosa fa e come interagisce col sistema.
Se faccio un programma in Python gira su tutte le distro, ma se quando l'ho scritto le impostazioni venivano memorizzate in un posto e dopo mesi vengono messe in un altro il programma non funziona, tanto per fare un esempio semplice. E queste cose capitano spesso, il post che ho incollato prima rende l'idea:

Noto la tendenza ultimamente di scaricare su chi rilascia le distribuzioni il compito di "far andare le cose". Versione del kernel stabile? Non serve, tanto ci pensa la distro a sceglierne una "abbastanza vecchia" e a mettere le patch che servono. Una qualche versione di alsa che funzioni out of the box senza smadonnamenti? Non serve tanto basta che la distro sistemi tutte le rogne. E cosi' via. Naturale che qualcosa poi scappi.
Non che per l'utente ci siano meno rogne, soprattutto quando si parla di configurarsi le cose. Non solo non si sa piu' dove vengono salvate le impostazioni (in un dotfile, in un misterioso file xml in una qualche sottocartella o in una abominevole copia del registro di Windows), ma applicazioni diverse le salvano in posti diversi (perche' se imposto il wifi dal dall'applet di gnome non e' lo stesso che farlo da linea di comando?). La lista di componenti che si comporta cosi' e' lunga e questo causa problemi anche a chi deve preparare la distribuzione, perche' diventa difficile, se non impossibile, usare applicazioni che vanno a cercarsi la stessa configurazione in posti diversi.
(le nuove distro sono peggiori delle precedenti)

stiamo andando un po' offtopic, quello che dici sicuramente è corretto, ma quello che voglio dire è che le parole di mr Rosenthal, sono solo pubblicità, marketing o FUD e non sono un giudizio tecnico, e che sulla piattaforma android certe cose si possono implementare.

Poi nemmeno a me piace l'invasività delle applicazioni google, io da questo punto di vista sono all'antica: i dati stanno sulla mia macchinae devo essere io a preoccuparmi di sincronizzare i miei vari dispositivi come desktop, portatile, cellulare, palmare anche con un'applicazione user-friendly immediata e semplicissima.(non tanto mi sta simpatico android anche se sono un simpatizzante e utente del FOSS)

E comunque riprendendo il tuo discorso Android è un sistema completo, e per quanto riguarda Linux, ci si dimentica che il sistema è GNU, e poi ci sono le specifiche LSB(linux standard base) che sono quelle che usano ANCHE E SOPRATTUTTO software come skype, opera, mathlab insomma i closed source che per loro necessità devono fare così. Per esempio in debian basta installare il pacchetto LSB e si ha la compatibilità con tutti i software binari che rispettano quello standard.
Poi essendo open-source nulla vieta di creare distro che hanno come centro linux invece di GNU, ovvero partono da un kernel e non da un sistema e qui il discorso è diverso, per esempio esistono cose di tutti i colori come bsd/GNU opensolaris/GNU e chi + ne ha + ne metta. Ma la maggior parte delle distro diffuse supporta LSB (magari qualcuno in versione + recente, e su freeBSD c'è una compatibilità al 70% di LSB che permette di far girare mathlab e compagni) e cmq android è un sistema e le parole di mr Rosenthal fanno parte del mondo della pubblicità, marketing, FUD infatti è un CEO non un ingegnere(se lo e dice il falso essendo di parte o no?)
Con android non ci saranno di questi problemi, giusto, se così non è informatemi e sarò contento di ascoltare le vostre spiegazioni(imparando qualcosa di nuovo grazie a voi come spesso avviene in questo forum da anni)

oddio.. va be va.. apparte che mi fa ridere vedere che passando dal c al csharp il sistema va più veloce..

in ogni caso.. pensate un'attimo.. l'evoluzione di windows e di linux sono su due mondi diversi.

linux.. escono aggiornamenti con una rapidità disarmante.. ubuntu ne fa uscire qualcosa come 10-15 al giorno minimo.. che fanno EVOLVERE tutto il sistema, non si parla solo di patch di sicurezza..

windows.. é xp e basta.. il kernel, le api, tutti RESTA COSì comé per 7-8 anni... non ce evoluzione, non ce miglioramento... ci credo che i programmi continuano a girare per 7-8 anni!

se vuoi che il tuo programma per linux facciamo come windows.. beh... allora BASTA AGGIORNARE E NON CAMBIARE DISTRO!

in più tutti a nominare ubuntu.. mentre una distro gentoo(ma li bisogna saperci mettere le mani) ha nei repository di portage librerie dell'anno del cucco, se servono é sufficente richiamare nome e versione e le installi...

se pensate che come kernel linux é più che raddoppiato in funzionalità dal passaggio dal 2,4 al 2,6(che é equivalente al passaggio da XP a vista)(e deve dare funzionalità sulle macchine più disparate- sparc, powerpc, alpha, cose che windows si sogna) e la pesantezza é rimasta uguale(Windows manager principali non hanno proprio fatto altrettanto, si é visto qualcosa con kde4 ma é presto..) la dice lunga sulla finezza e cura con cui viene evoluto e scritto il kernel..

X iocci

tanto per restare OT

Nel 1969 la potenza di due commodore 64 ha portato l'uomo sulla luna, oggi un processore a 3 ghz serve a far girare windows xp...Qualcosa è andato storto!!!

Avevo scritto una risposta lunga un km ma poi l'ho cancellata. Riassumo brevemente:

Quoto Leptone quando dice che la situazione non è affatto così drammatica. Google ad esempio x evitare casini con gli update di wine ha pacchettizzato picasa (facendo tecnicamente una porcata indicibile x il mondo linux ma è la norma x gli ambienti MS) con wine e tutte le dipendenze necessarie. Questo se dal punto di vista tecnico è un vantaggio e una semplificazione porta cmq grossi svantaggi: esce una qualche patch che impedisce al computer di trasformarsi in un terminator a causa di un bug di wine. I google boys devono correre ad aggiornare altrimenti gli utilizzatori di picasa saranno terminati dai loro pc. Su windows questo modus operandi è la norma. Chi fa un applicativo lo fa con determinate librerie e tutto muore li. La soluzione linux-like è decisamente + intelligente. 1 unico sistema di gestione che aggiorna tutto. Questo comporta (o meglio così può sembrare) + lavoro x i piccoli sviluppatori. Però la sicurezza del sistema ne giova. Attualmente la maggior parte dei crash e dei casini di windows non dipendono da windows ma da elementi di 3e parti non correttamente installati, aggiornati, mantenuti dai produttori. Questo è imho uno dei limiti maggior di windows. Vedere che aggiornado il mio intrepid alla rc1 mi vengono aggiornati pulseaudio, driver video, cups (il sistema di gestione della stampa), librerie di vario tipo è bello. Significa che tutti si lavora x la stabilità. Se poi devo (come infatti ho fatto) ricompilare vmware non è un gran danno. Tanto + che x merito di dell la cosa la faccio ora e non la farò mai + visto che è stato introdotto in intrepid (non so se è già operativo e non so se vale x qualunque modulo) un applicativo che ricompila i moduli aggiuntivi del kernel a seguito di update dello stesso (x semplificare la vita gli utonti).

CMQ i casini che può avere linux non centrano una mazza con Android che NON È UN SISTEMA LINUX. E' un kernel + altra roba. Esattamente come il software di un qualunque lettore divx economico, qualunque router adsl (con qualche rara eccezione), come qualunque decoder iptv in commercio (SKY, tiscali, alicetv). Certamente non è un sistema completo quanto windows mobile (che ha anni di vita alle spalle). Ma già ora è una spanna sopra a iphone x quanto riguarda le funzionalità (questo nonostante l'interfaccia di iphone mi piaccia molto). Dategli 1 annetto poi vedrete se non avremo connettori x exchange, applicativi x la sincronizzazione senza passare da bigG.

Ah quindi le considerazioni le fa proprio uno indipendente e neutrale...
Ho interrotto di leggere la news già dopo la prima riga...

Non è forse cosi in tutti i SO? O meglio, non è forse questo uno dei compiti di un so?



Il "cambiano mai" è un po forte, come affermazione (voglio essere gentile e non dire che hai detto una grossa cagata), comunque, non è forse cosi in tutti i SO? O forse negli altri SO le applicazioni si programmano facendo chiamate kernel?



Quindi se io quel codice lo cancello, le mie applicazioni continueranno a girare... Scherzi a parte, fin quando rispetti le interfacce è normale... Ma ancora, non è forse cosi in tutti i SO o API?



Che è il semplice concetto di API, comune a qualsiasi software di questo mondo. E di certo non è un'evoluzione che si può fare cosi facilmente come vuoi far credere. Modificare anche solo un'interfaccia di astrazione (perchè evolversi significa anche fare questo) comporta i problemi che invece vuoi far credere non esistano.



Come no. Per mantenere la compatibilità col passato ci portiamo dietro ancora API vecchie e completamente duplicate con quelle nuove.
O peggio ancora un numero di layer eccessivo, con nuove API basate su API vecchie.



Ma quando mai. Se mi parli di "interfaccia di programmazione" mi parli di API, che per concetto, è un'astrazione piu' alta di un livello piu' basso e quindi "immutabile" rispetto alle system call mutabili (parliamo di interfacce). E i problemi ce li hanno solo i driver, non le applicazioni. Driver che vengono mantenuti in concomitanza con il kernel, il che quindi è pure relativo. E soprattutto nemmeno Windows ne è esente, non crederai forse che i driver di Windows Vista oggi funzioneranno con Windows del 2018... Windows poi non evolve incrementalmente ma sta sul mercato almeno 4 o 5 anni con un'API fissa... Paragonare Linux e Windows in questo non ha senso.
Secondo, fai una grande confusione fra api del kernel (livello modulo o livello driver) e api di esposizione del kernel (livello applicazione). In Linux, l'API immutabile che fa da interfaccia fra kernel e applicazioni si chiama glibc. E sono vent'anni che funziona e in linea di massima presenta le stesse chiamate di sempre. Ed è uno standard POSIX, non è che se lo inventano i programmatori mentre scrivono il kernel. Terzo, il 99.99% delle applicazioni non deve mai andare a un livello piu' basso della glibc e il restante 0.01% che lo deve fare sono tool di sistema, non proprio software applicativo.



Perchè, in Windows i layer piu' alti si adattano al nuovo codice con la bacchetta magica? Ti ripeto, fin quando si modifica il codice nel rispetto delle interfacce è cosi per tutti i SO, non solo per Windows (e gli SO in questo non c'entrano nulla, è cosi proprio per il codice in generale). Ma stiamo parlando di evoluzione, e quindi anche la possibilità che queste interfacce debbano cambiare. O no?



Quindi se io in Windows con una modifica "interna" rimuovo un metodo di classe, tutta la gerarchia di ereditarietà fa refactoring in automatico con la sfera del mago silvan...



Ma questo non è mica un'esempio rappresentativo del discorso che si faceva, cosa c'entra un linguaggio e i problemi di portabilità e retrocompatibilità con il modo con cui uno scrive delle applicazioni.



Veramente è proprio il contrario, sono proprio le distribuzioni che invece non aspettano le release stabili e includono le branch ancora in sviluppo e testing, facendo addirittura backporting su release considerate stabili di features che stanno presenti sono in trunk e sono ancora in sviluppo attivo... Cognizione di causa saltami addosso....



Il discorso è semplicemente tecnico: utilizzando una GUI molto spesso non puoi avere lo stesso ventaglio di parametri. Di conseguenza il front-end gui fa prima a crearsi un file di configurazione differente nel quale leggere i parametri da passare all'applicazione console. Questo è lo svantaggio del modello applicazione / frontend rispetto al modello applicazione GUI pura. Ma il vantaggio rispetto allo svantaggio, almeno a quelli piu' esperti, è evidente. E di certo non è un concetto che investe Linux in quanto SO ma è proprio un paradigma di scelta nel codificare un'applicazione. E' una scelta progettuale delle applicazioni, non ha nulla a che vedere con Linux in se. Puoi scrivere un'applicazione GUI nativa senza riga di comando e non avere di questi problemi. Nemmeno da Visual Studio puoi accedere a tutto quello che supporta il compilatore da riga di comando, tanto per farti un esempio. E i file di una soluzione visual studio non sono certo uguali ai makefile di un build system completamente da riga di comando...
Altro esempio, vuoi forse dirmi che MS ha introdotto PowerShell su Vista perchè la riga di comando è obsoleta? Una riga di comando è considerata obsoleta solo da chi con un computer oltre 3 checkbox di un'utility del menga non va. Fortunatamente l'utenza non è tutta uguale.



Le applicazioni sono fatte per gli utenti, non per i creatori di distribuzioni. Quello di far funzionare pacchetti in un sistema completo è il loro lavoro. Nessuno ha mai detto che sia facile. Quanto agli utenti, l'approccio applicazione console basata su frontend GUI è una scelta che favorisce gli utenti esperti. I lamer, i noob e tutto il resto dovrebbero usare Ubuntu e configurare il tutto mediante gli strumenti forniti. Se tutto ciò non fosse ancora sufficiente, possono tornare a Windows tranquillamente. Nessuno ha mai detto o preteso che Linux sia lo strumento ideale per tutti.Ognuno deve scegliere ciò è piu' consono per le proprie esigenze. Solo che se uno ha esigenze da noob e pretende simili modifiche da un sistema Unix, come direbbe abatantuono, sta pisciando fuori dal seminato. Io personalmente un'apache o un mysql la cui configurazione sia esclusivamente GUI non li chiederei nemmeno come punizione se dovessi andare a finire all'inferno.