Link alla notizia: http://www.hwupgrade.it/news/business/android-non-e-adatto-al-mercato-enterprise_26935.html

È il parere di un partner Microsoft per le soluzioni mobile: Android non offre la sicurezza e le applicazioni che le aziende richiedono

Click sul link per visualizzare la notizia.

onestamente pur essendo un fan di tutto cio' che e' open non posso non essere d'accordo. Non si puo' lasciare un telefono in mano a google per qualsiasi operazione, siamo seri. Certo nulla vieta che symbian e winmobile siano pieni di backdoor ma almeno rubrica e mail (per dire le prime cose) non sono direttamente online... Se vogliono sfondare anche nel settore enterprise (dove secondo me c'e' parecchio spazio di manovra potendo puntare su un parco sw virtualmente illimitato) google e i suoi servizi dovranno essere decisamente meno invasivi

Se vogliamo un vero cambiamento, dovrebbe essere proprio questa la strada. Lasciare fuori Microstroz da tutto quello che riguarda il software open. Non dare supporto ad exchange, se parlassimo con persone intelligenti, porterebbe al totale abbandono di quella piattaforma. E invece, non andra' cosi'. SCHIAVITU'.

Ci sono anche altri motivi per cui potrebbe non essere adatto, come evidenziato su questo articolo:
Linux non è fatto per il mobile (http://www.webnews.it/news/leggi/9177/symbian-linux-non-e-fatto-per-il-mobile/)

In particolare:
Panagrossi, vice presidente di Symbian, mette poi il dito in quella che da molti è considerata una delle più gravi piaghe di Linux, ovvero la frammentazione. Linux è solo un kernel e i costruttori devono andare oltre il cuore del sistema operativo per avere le funzioni necessarie al funzionamento del telefono. Sempre secondo Panagrossi, questo induce ad avere implementazioni anche molto diverse con il risultato che «quando si chiede ad un fornitore di soluzioni Linux che percentuale di software riesce a girare su tutte le loro piattaforme, la risposta è vicino allo zero percento».


Non è una cosa da poco, è molto piu comodo lasciare che MS faccia il SO e trovarselo pronto. Inoltre avendo un'unica piattaforma basta supportare quella per coprire il 100% degli utenti, riducendo i costi e facilitando la produzione di software di terze parti. Con le varie piatatforme basate su Linux è molto piu difficile ottenere la stessa cosa.

Inoltre il presidente di Google non era quello che aveva detto "la privacy non esiste" o qualcosa di simile? Non è proprio un buon biglietto da visita per entrare nell'ambito aziendale...

LOL

Non credo che il supporto ad exchange sia così importante, IMAP e simili sono imho la soluzione migliore. Inoltre: Google non propone un'applicativo per sincronizzare i dati in locale è vero, basano tutto sulla sincronizzazione con gli applicativi web di bigG.

E' anche vero che la piattaforma è opensouce, qualunque azienda può prendere adroid, modificarlo e renderlo compatibile con i servizi di yahoo, microsoft o creare un applicativo per sincronizzare il tutto in locale. Certamente il futuro è la strada intrapresa da Google. i miei dati sincronizzati su pc, notebook, cellulare, dovunque.

@IOCCI
Le dichiarazioni di Panagrossi sono una bella barzelletta!!! Android non è linux. E' basato su kernel linux ma non è linux. Dovremmo avere openoffice così com'è su android? Android ha preso dal mondo opensource il meglio: kernel linux, la VM java, un mare di altre cose e ha creato una piattaforma standard su cui lavorare. C'è un unica strada per creare applicazioni, standard che se rispettati rendono perfetta la compatibilità.

Perchè windows mobile è adatto all'enterprise....

ma mi faccia il piacere ...

E beh, un partner Microsoft che parla bene delll´open source é come un un comunista che adora gli USA...mah...

aspettiamo e vediamo come si comporta e come si sviluppa, poi facciamo le valutazioni su android, non spariamo subito a zero...che MS abbia paura???

Le dichiarazioni di Panagrossi sono una bella barzelletta!!! Android non è linux. E' basato su kernel linux ma non è linux. Dovremmo avere openoffice così com'è su android? Android ha preso dal mondo opensource il meglio: kernel linux, la VM java, un mare di altre cose e ha creato una piattaforma standard su cui lavorare. C'è un unica strada per creare applicazioni, standard che se rispettati rendono perfetta la compatibilità.


Sul discorso della frammentazione ha ragione. Non c'è solo Android, ci sono molte piattaforme basate su Linux per dispositivi mobili, tra cui OpeMoko, LiMo, Maemo e altre.
Ognuna è fatta a modo suo, ha le sue peculiarità, path e directory diverse, servizi diversi, componenti diversi... e tutte queste differenze e le devi gestire a mano quando sviluppi un programma.
Se vuoi vendere un programma a un cliente prima devi certificare che funzioni, e su Linux ti fa perdere molto piu tempo visto che ci sono molte piataforme diverse e supportarle tutte è molto difficile.
Oppure ti specializzi solo su una, e allora viene fuori che il discorso di Panagrossi è vero: "quando si chiede ad un fornitore di soluzioni Linux che percentuale di software riesce a girare su tutte le loro piattaforme, la risposta è vicino allo zero percento".

per quanto riguarda la frammentazione sono completamente d'accordo, è la piaga dell' opensource, ma credo che prima o poi la situazione cambierà.
Se si standardizzasse: una distro desktop, una server e una mobile mi sa che ms ecc.. dovrebbero cominciare a farsela sotto.
invece ora come ora è un puttanaio pieno di tantissime buone idee ma appunto... un puttanaio.

Quindi:

"Non credo che il supporto ad Exchange sia così importante"

è una cavolata.
Se la mia ditta ha Exchange, non comprerò un cell con Android, ma il calssico Balckberry.


"E' anche vero che la piattaforma è opensouce, qualunque azienda può prendere adroid, modificarlo e renderlo compatibile con i servizi di yahoo, microsoft o creare un applicativo per sincronizzare il tutto in locale."

è un'altra cavolta.
Perchè devo usare risorse per fare una cosa che altri dispositivi già fanno ?!

L'utenza business non è certo l'utenza privata.

ByE

leggevo apppena adesso sta discussione che centra in pieno il problema della frammentazione:
le nuove release sono peggiori delle precedenti (http://www.hwupgrade.it/forum/showthread.php?t=1843577)

in particolare sto post:
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.

FUD.
Non c'è supporto ad Exchange? Implementatelo voi, per dio.
Linux non ha standard solidi? Da che pulpito. Svegliatevi, parliamo della Microsoft, la compagnia che pur col monopolio assoluto sul mercato desktop privato non è riuscita a creare protocolli e formati capaci di durare più di un ciclo di release.
C'è frammentazione nelle piattaforme Linux in ambito mobile? Falso, le soluzioni Linux di Motorola e Nokia hanno un mercato così infimo che un singolo cellulare, il G1, sarà senza nessun ragionevole dubbio capace di imporre i suoi standard.

La Microsoft ha avuto successo per il grande supporto agli sviluppatori(e per una marea di altre cose di cui non sarebbe carino parlare qui); ora, nel mercato mobile, è Google ad aver realizzato la piattaforma, ed è bene che la Microsoft si renda conto che il suo Windows ME è ormai sulla via dell' obsolescenza, senza pagare dei partner per diffondere debole FUD.
Svalutare un OS che non ha ancora neppure raggiunto la prima release finale per l' assenza di una feature... Converrete con me che non c'è altra parola per descriverlo se non patetico.

Svegliatevi, parliamo della Microsoft, la compagnia che pur col monopolio assoluto sul mercato desktop privato non è riuscita a creare protocolli e formati capaci di durare più di un ciclo di release.


Di cosa parli? Windows è da una vita che ha delle API stabili e che garantisce la retrocompatibiltà, oggi posso uso ancora programmi compilati nel 1997 mentre su Linux una cosa del genere è impossibile.
Se un programma mi andava su XP 7 anni fa quando è uscito oggi va ancora benissimo, una distro Linux di 7 anni invece fa è del tutto inusabile da quanto è obsoleta. E i programmi che ci girano sopra devono essere costantemente seguiti per adattarli ai continui cambiamenti.
Ho qua CD con programmi gestionali per Linux che mi sono fatto fare tre anni fa e sulle distro di oggi non vanno, perche i componenti e le librerie hanno cambiato API/ABI... dovrei farmelo riscrivere per farlo funzionare (e ovviamente non me lo fanno gratis).

Creare un eseguibile stand alone che gira su tutte le versioni di Windows è semplicissimo, si pu raggiungere il 100% dei propri utenti senza difficolta. Su Linux creare un programma che gira su tutte le distro richiede molto piu lavoro, e so di cosa parlo visto che l'ho fatto.

@eFFeeMMe
Bravissimo quoto tutto quello che dici. Il potere di Microsoft NON sta nelle tecnologie (scarse), ma solo nella forza dell'abitudine degli utenti, che nell'informatica e' un fattore determinante. Se un utente e' abituato a usare un prodotto, per quanto scarso, per lui sara' lo standard si fara' fatica a convincerlo ad abbandonarlo. Tutto qui, il linea di principio non c'e' nulla che non si possa fare (meglio) con l'open source.

Ah beh, se l'ha detto un partner microsoft....:asd:

EDIT: non voglio finire Off Topic. iocci, se ti interessa hai un PM.

"Svegliatevi, parliamo della Microsoft, la compagnia che pur col monopolio assoluto sul mercato desktop privato non è riuscita a creare protocolli e formati capaci di durare più di un ciclo di release. "

ma che stai dicendo ?!?!

màh ....

Non è una cosa da poco, è molto piu comodo lasciare che MS faccia il SO e trovarselo pronto. Inoltre avendo un'unica piattaforma basta supportare quella per coprire il 100% degli utenti, riducendo i costi e facilitando la produzione di software di terze parti. Con le varie piatatforme basate su Linux è molto piu difficile ottenere la stessa cosa.

Sul discorso della frammentazione ha ragione. Non c'è solo Android, ci sono molte piattaforme basate su Linux per dispositivi mobili, tra cui OpeMoko, LiMo, Maemo e altre.

Scusate ma android è una distro linux? NO. punto, fine della questione. non ci si possono compilare gnome, kde ecc. Android usa il kernel linux xchè sarebbe stato stupido crearne tutto da 0. Usa Dalvik come base x far girare tutte gli applicativi. E' una piattaforma che non subirà la frammentazione del mondo linux.


"Non credo che il supporto ad Exchange sia così importante"

è una cavolata.
Se la mia ditta ha Exchange, non comprerò un cell con Android, ma il calssico Balckberry.

Esistono migliaia di aziende che usano domino, tante usano altri sistemi (zimbra, openexchange, o migliaia di altre cose del genere). Il mio E61 non ha un connettore exchange ma nokia l'ha rilasciato come applicativo aggiuntivo. Stessa cosa x il blackberry connector che è disponibile da qualche tempo.


"E' anche vero che la piattaforma è opensouce, qualunque azienda può prendere adroid, modificarlo e renderlo compatibile con i servizi di yahoo, microsoft o creare un applicativo per sincronizzare il tutto in locale."

è un'altra cavolta.
Perchè devo usare risorse per fare una cosa che altri dispositivi già fanno ?!

Pensi che motorola non sia in grado di farlo? Costerebbe meno a fare così o acquistare licenze windows mobile? Ogni licenza costa 15dollari. Fai x un milione di disposivi (numeri che immagino motorola faccia abbastanza facilmente) IMHO i margini x sviluppare quanto manca ci sono. Questa è poi la filosofia alla base della scelta di creare una piattaforma opensource. Motorola fa il connettore x exchange, yahoo integra i suoi applicativi, ecc. Tutto su android market e poi ogni produttore di cellulare fa quello che vuole


Di cosa parli? Windows è da una vita che ha delle API stabili e che garantisce la retrocompatibiltà, oggi posso uso ancora programmi compilati nel 1997 mentre su Linux una cosa del genere è impossibile.

Beh insomma office 97 su vista non fa, il 2000 necessita 200mb di patch e stessa cosa il 2003 se non vuoi crash ogni 2 secondi (sperimentato questa settimana da un mio cliente). La presunta compatibilità binaria è una fantasia! Prendi nero 6 e provalo su vista!

Se un programma mi andava su XP 7 anni fa quando è uscito oggi va ancora benissimo, una distro Linux di 7 anni invece fa è del tutto inusabile da quanto è obsoleta. E i programmi che ci girano sopra devono essere costantemente seguiti per adattarli ai continui cambiamenti.


Una distro di 7 anni fa ha upgrade costanti e gratuiti. Gli applicativi sono di norma ricompilati x queste distro e non ho presenti grosse eccezioni. Se usi un sistema per lavoro ti prendi una distro con un lungo supporto tecnico (hardy 8.04 ha 5 anni di supporto, centos 7) e stai tranquillo che non ci sono cambio di librerie!

Ho qua CD con programmi gestionali per Linux che mi sono fatto fare tre anni fa e sulle distro di oggi non vanno, perche i componenti e le librerie hanno cambiato API/ABI... dovrei farmelo riscrivere per farlo funzionare (e ovviamente non me lo fanno gratis).

Mi è capitato lo stesso mille volte negli ultimi mesi con macchine con vista. Nel settore delle agenzie viaggi ci sono valanghe di software tuttora non compatibili con vista (amadeus lo è diventato da pochi mesi, sipax plus non ancora).

Creare un eseguibile stand alone che gira su tutte le versioni di Windows è semplicissimo, si pu raggiungere il 100% dei propri utenti senza difficolta. Su Linux creare un programma che gira su tutte le distro richiede molto piu lavoro, e so di cosa parlo visto che l'ho fatto.

? sviluppare in python un applicativo e renderlo compatibile con tutte le distro è difficile? mi risulta il contrario..... Per la compatibilità su windows posso farti parlare con vari clienti che hanno gestionali fatti su misura. O sono incapaci quelli che sviluppano software a Modena (e può essere, ho conosciuto un paio di loro e non mi sono sembrati particolarmente svegli) o non è tutto così rose e fiori....

Come al solito girano un sacco di inesattezze. Io non sono un programmattore ma almeno conosco cose minime e basilari dell'informatica.
Su diverse distro Linux, per far andare un programma qualsiasi basta solo ricomplilarlo, e lo stesso vale per i software vecchi che devono girare su distro nuove. Se io faccio un software e voglio che vada su tutte le distro linux presenti e future ho 2 scelte:

1 ricompilare e reimpacchettare il programma ogni volta, e lo può fare anche uno script(provate una vecchissima versione di VMware e vedete se il .run funzione)

2 se non volgio avere rogne COMPILO STATICAMENTE e e metto le librerie nel software.

Il problema che tutti lamentano in windows è proprio quello che si porta dietro la compatibilità ed è vecchio, quella delle distro linux è la soluzione.
Guardate che tutto questo non dipende dal fatto di essere open-source o closed, è una cosa generale dell'informatica la compilazione statica, che ti garantisce che il software funzioni ovunque e sempre, o la compilazione linkando le librerie, che devi fare ogni volta ma la puoi fare con uno script o un qualsiasi sistema automatico.

Vedo che col tempo la cultura informatica scende inesorabilmente anche in certi ambienti.
È stupido stare a parlare di certe cose elementari, le aziende fanno marketing sapendo che tutti i niubbi(sedicenti power-user) ci cascano

Una distro di 7 anni fa ha upgrade costanti e gratuiti. Gli applicativi sono di norma ricompilati x queste distro e non ho presenti grosse eccezioni. Se usi un sistema per lavoro ti prendi una distro con un lungo supporto tecnico (hardy 8.04 ha 5 anni di supporto, centos 7) e stai tranquillo che non ci sono cambio di librerie!

L'unica distro che ha un supporto di 7 anni è REHL/CentOS, ed è un caso limite visto che è l'unica con un supporto cosi lungo.
Ora prova a scaricarti una distro del 2001 e prova ad aggiornarla, a installare qualche programma recente, e vedere cosa riesci a combinare.
Io ce li ho qua CD di distro del 2001 e so che sono del tutto inutilizzabili, mentre XP che è uscito nel 2001 è ancora supportato e lo sara fino al 2014 e i vecchi programmi funzionano benissimo.

Se voglio installare un programma nuovo su una distro con piu di qualche anno di sicuro ho una valanga di problemi dovuti al fatto che nei repository non ci sono le dipendenze necessarie, non è presente una versione sufficientemente aggiornata, vengono usati componenti obsoleti che non sono piu utilizzati nelle distro moderne, usa file di configurazione con sintassi vecchie e altri mille impicci.

Non si tratta che su Windows è piu facile, ma si tratta del fatto che non ti devi preoccupare della distro che ogni 12 mesi in genere diventa obsoleta e non piu aggiornata, non ti devi preoccupare perche l'exe è uno solo e non ci sono diversi pacchetti per ogni distro, e con 1 click hai il pacchetto installato.
Installare un deb nuovo che richiede dipendenza X che la distro non ha succede molto spesso e NON è affatto semplice il proseguimento.

? sviluppare in python un applicativo e renderlo compatibile con tutte le distro è difficile? mi risulta il contrario..... Per la compatibilità su windows posso farti parlare con vari clienti che hanno gestionali fatti su misura. O sono incapaci quelli che sviluppano software a Modena (e può essere, ho conosciuto un paio di loro e non mi sono sembrati particolarmente svegli) o non è tutto così rose e fiori....

Non c'entra il linguaggio, il fatto è che le distro usano path e directory diverse, su alcune distro sono presenti delle librerie e su altre no, oppure le versioni disponibili non sono compatibili, ci sono metodi di autenticazioni diversi, i pacchetti nelle varie distro sono compilati con dipendenze diverse e con flag diversi, i servizi hanno nomi e funzionalita diverse, bisogna creare un pacchetto per ogni distro e tenere aggiornate le dipendenze nel tempo, e molte altre differenze che si devono gestire a mano.
Su Windows tutti questi problemi non ci sono, devo supportare solo un'unica piattaforma che resta stabile e immutata. Le API di Win32 è da una vita che sono quelle...

Beh insomma office 97 su vista non fa, il 2000 necessita 200mb di patch e stessa cosa il 2003 se non vuoi crash ogni 2 secondi (sperimentato questa settimana da un mio cliente). La presunta compatibilità binaria è una fantasia! Prendi nero 6 e provalo su vista!

Un software scritto per Windows XP mi gira tutt'oggi su Windows XP, e Windows XP sara supportato con aggiornamenti di sicurezza fino al 2014.
Nessuna distro Linux offre una durabilita cosi elevata. Se mi faccio fare un programma per Vista adesso so che fra dieci anni Vista sara ancora supportato e la mia applicazione funzionera ancora, mentre con Linux fra tre anni il programma non funzionera piu con le distro che ci saranno fra tre anni e allora o mi tengo una distro che è diventata obsoleta o me lo faccio rifare.

Come al solito girano un sacco di inesattezze. Io non sono un programmattore ma almeno conosco cose minime e basilari dell'informatica.
Su diverse distro Linux, per far andare un programma qualsiasi basta solo ricomplilarlo, e lo stesso vale per i software vecchi che devono girare su distro nuove. Se io faccio un software e voglio che vada su tutte le distro linux presenti e future ho 2 scelte:

1 ricompilare e reimpacchettare il programma ogni volta, e lo può fare anche uno script(provate una vecchissima versione di VMware e vedete se il .run funzione)

2 se non volgio avere rogne COMPILO STATICAMENTE e e metto le librerie nel software.

Il problema che tutti lamentano in windows è proprio quello che si porta dietro la compatibilità ed è vecchio, quella delle distro linux è la soluzione.
Guardate che tutto questo non dipende dal fatto di essere open-source o closed, è una cosa generale dell'informatica la compilazione statica, che ti garantisce che il software funzioni ovunque e sempre, o la compilazione linkando le librerie, che devi fare ogni volta ma la puoi fare con uno script o un qualsiasi sistema automatico.

Vedo che col tempo la cultura informatica scende inesorabilmente anche in certi ambienti.
È stupido stare a parlare di certe cose elementari, le aziende fanno marketing sapendo che tutti i niubbi(sedicenti power-user) ci cascano

Non si tratta solo di linkare tutto staticamente e ricompilare un programma ogni tot anni, intanto perche molti componenti non è assolutamente consigliabile linkarli staticamente (GTK, libc...) e anche eprche il programma deve interagire con altre parti e con servizi offerti dal sistema operativo, e se questi cambiano nel tempo devo anche rimettere mano al mkio programma per adattarlo.
Windows invece ha degli ottimi livelli di astrazione, quello che non cambiano sono le API ma tutto quello che c'è sotto possono migliorarlo e aggiornarlo continuamente tramite update senza che i programmi ne risentano, eprche sono isolati dalle modifiche interne.

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?

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).

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

http://img228.imageshack.us/img228/8568/archwinmg3.jpg

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 (http://www.hwupgrade.it/forum/showthread.php?t=1843577))

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... :asd:
Ho interrotto di leggere la news già dopo la prima riga... :)

L'intero kernel, l'executive e tutte le funzionalità di Windows sono isolate dalle applicazioni tramite un livello di astrazione.


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


Le applicazioni non accedono direttamente alle parti interne ma chiamano le loro funzionalita tramite delle API ben definite che non cambiano mai.


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? :p


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.


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?


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.


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 si vede non è vero che la retrocompatibilità col passato comporta evidenti problemi con la modernità, anzi.


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.


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.


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.


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.


Perchè, in Windows i layer piu' alti si adattano al nuovo codice con la bacchetta magica? :rolleyes: 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?


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.


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... :asd:


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.


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.


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.


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.... :rolleyes:


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?).


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.


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 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.