Ubuntu fa risparmiare 50 milioni alla polizia francese

[ConteZero]

Originariamente inviato da cdimauro

Dimentichi che rimangono le patch per la sicurezza, che sono le più importanti.

No, sono quelle che Microsoft non si può esimere dal rilasciare perché condizionano l'intero "ecosistema" internet.

Poi è difficile parlere di fiasco per un s.o. che ha venduto più di 140 milioni di copie.

Quante di queste in OEM ?
Quanti downgrade legittimi ?
Quanti downgrade illegittimi ?

Premesso che per scrivere "spesso" bisognerebbe avere delle stime, ciò che hai detto è un vantaggio di queste soluzioni closed, perché... fanno RISPARMIARE soldi.

Non esattamente.
Fanno risparmiare TEMPO, non soldi.
Un SW verticale, magari scritto da zero per quel compito, può essere fatto molto in fretta, il problema si presenta in seguito per mantenerlo aggiornato e per estenderne le funzionalità (specie se è programmato coi piedi).
Nella realtà poi chi vende il software ha tutto da guadagnarci a scrivere codice poco leggibile/difficilmente portabile per rendersi "indispensabile"... se poi riesce a strappare un contratto che non lo obbliga a rilasciare i sorgenti è in una botte di ferro perché una volta che la società adotta il software o continua ad andar dietro a lui o si trova con un mucchio d'istruzioni assembler inutilizzabili.

Poco importa poi se girano soltanto su Windows.

Poco importa se non hai intenzione di migrare fuori da windows... altrimenti (se non vuoi precluderti la possibilità di una migrazione) importa eccome.

Che è come dire: meglio rimanere con Windows, visto che state eseguendo codice Windows a tutti gli effetti.

No, come dire "la società ci metterà un mesetto per adattare il codice a Gentoo... visto che c'è da lavorare intanto usiamo quello windows su Wine.

Quanto al breve termine, è ampiamente opinabile. Portami PhotoShop CS 4.0 "a breve termine", se ci riesci.

Avendo un contratto che obbliga l'Adobe a farlo sarebbero ca**i e penali di Adobe.

E Linux non ne ha?

Ne ha, ma ha anche molti pregi che Windows NON AVRA'MAI (fra questi il prezzo).

Mandrie che continuerebbero a esserci anche passando a Linux, OS X, ecc. ecc.

Relativamente...
La cretinaggine degli utenti dipende in buona parte dal training che gli fai.
E spesso e volentieri la gente viene ammollata davanti ad un PC con Windows senza fargli granché training (sulla base di "è windows, lo sanno usare tutti").

E i costi sarebbero? 50 MILIONI di euro? A me pare che le licenze costino decisamente di meno, e ti ritrovi con un ambiente familiare e per quale esistono tonnellate di software che non ha eguali per nessun s.o. esistente.

Comincia a sommare licenze, costi per i server, costi per la manutenzione (hai presente quando hai un OS server e chiami Microsoft per chiedere assistenza ?) e vedi come lievitano i costi.

Il che, se permetti, è il motivo per cui ancora oggi Windows è il s.o. più diffuso. Perché una piattaforma senza o con poco software può essere bella ed economica quanto vuoi, ma non è produttiva quanto una in cui ci sono valanghe di applicazioni per la qualunque.

Che in un ambito aziendale NON servono visto che in genere in un ambito lavorativo di applicazioni se ne usano pochissime.
Windows è il s.o.più diffuso perché la gente lo usa, non perché le aziende lo preferiscono.
Le aziende lo preferiscono perché la gente lo usa, cosa che lo rende "standard de facto".

Vediamo i piani di rientro allora, con TUTTI i dettagli. Perché a me sembra che, per com'è messa la questione, l'unica variabile in gioco citata è quella della licenza.

Quant'è per chiamata in caso di problemi in ambito server ?
Lessi 700 euro prima ancora di presentare il problema a Microsoft e senza l'assicurazione che venga risolto.

Hai finito di bestemmiare tu? Bene, allora comincia a sviluppare qualche applicazione che non sia il classico "Hello, world!", e poi forse ti renderai conto di cosa significa sviluppare software.

Ad hominem.

Rileggi bene: non ho negato che il sorgente sia comodo. Ho negato i vantaggi della compatibilità in un sistema che RICHIEDE i sorgenti, com'è Linux appunto.

Nulla vieta di distribuire gli eseguibili, su una FAMIGLIA DI OS come GNU/Linux in genere non si fa, ma all'interno della stessa distribuzione non è difficile veder girare gli eseguibili già belli compilati e pronti.

Tanto per fare un esempio: i driver. Su qualunque s.o. che non sia Linux o simile, è sufficiente l'interfaccia BINARIA per realizzarli. Rilasciare o meno i sorgenti è del tutto indifferente, perché so che il mio driver girerà lo stesso, perché è il s.o. che mi garantisce, tramite l'ABI, il suo funzionamento facendosi carico di parametri quali single core, multicore, SMP, ASMP, NUMA, e quant'altro.

Qualcosa di molto simile lo puoi fare su una distribuzione.
Basta compilare i driver come moduli e distribuirli, nel caso facendo il backporting di quelli sviluppati per kernel successivi.
Una volta che li hai come moduli per il kernel comune alla distribuzione lo puoi tranquillamente distribuire in binario.

Per rispodere alla tua ultima domanda: sì, si può fare. E non ci vuole molto per arrivarci.

Come ? con un emulatore x86 per ARM ?

Immaginavo che avresti tirato fuori Java. D'altra parte l'amo di .NET l'ho messo apposta per questo.

No, l'ho detto perché è così.

Sì, Java è disponibile per tanti s.o., ma... non per tutti. Esempio pratico: le JVM per AmigaOS, SkyOS, ecc. Difatti Sun supporta soltanto 4 piattaforme ufficialmente: Windows, Solaris, Mac OS X e Linux. Tutte le altre si devono arrangiare.

Ma Java non lo sviluppa solo SUN.
Buona lettura : http://en.wikipedia.org/wiki/List_of...rtual_machines

Secondo, le applicazioni Java in genere te le ritrovi compilate in bytecode. Niente sorgenti quindi, con buona pace di tutti i discorsi che hai fatto finora.

Puoi avere sia i sorgenti java (come puoi avere i sorgenti c# e cacchi vari) sia i bytecode (per VM java o .net), non cambia granché.

Terzo, dovresti dirmi qual è il valore aggiunto di far girare un'applicazione Java su Linux piuttosto che su Windows. Il "risparmio" di cui s'è parlato finora dove starebbe?

Che domani il mio software lo vendo a chiunque e gira dovunque.
Se il cliente ha windows il codice gira su windows, se ha linux gira su linux, se ha freebsd gira su freebsd.

Passiamo a .NET, perché hai riportato delle informazioni inesatte (a voler essere buoni).

Sono tutto orecchi...

Primo: .NET non è limitato a Windows o ai s.o. che MS decide di supportare. E' uno standard completamente aperto, e chiunque può realizzare runtime .NET per le piattaforme più disparate (altrimenti non esisterebbe nemmeno Mono).

Mono non è un implementazione sovrapponibile al 100% al .NET che Microsoft mantiene su Windows, da cui il risultato che quello che scrivi su .NET per Windows potrebbe non girare su Mono (l'ha detto anche il capoprogetto di Mono che c'è una parte di .NET Microsoft che ha a che fare col sistema sottostante e che ovviamente non sarà in Mono).

Secondo: lo stato dei lavori di Mono nulla tange rispetto a quanto detto qui sopra. Se Mono è immaturo, che lo supporti la comunità open source.

Con il piccolo problema che se .NET non è portabile non è che ne soffre la comunità open source, ne soffre .NET.
Se .NET non è portabile ed affidabile semplicemente la gente preferisce qualcosa di portabile ed affidabile, per cui .NET fallisce.

Terzo, la diffusione di Mono riguarda Mono e le piattaforme su cui gira. Per .NET esistono MIRIADI di applicazioni, e ne esisteranno sempre di più, per cui è la comunità open source che dovrebbe pensare alla sua diffusione.

Anche per Cobol esistono MIRIADI di applicazioni.

Bene. Parafrasando quello che si dice nelle comunità open source, FUORI I NUMERI.

Che i conti non tornano.

Prenditela con la polizia francese.

[elect]

Originariamente inviato da cdimauro

Poi è difficile parlere di fiasco per un s.o. che ha venduto più di 140 milioni di copie.

Originariamente inviato da ConteZero

Quante di queste in OEM ?
Quanti downgrade legittimi ?
Quanti downgrade illegittimi ?

[cdimauro]

Originariamente inviato da ConteZero

No, sono quelle che Microsoft non si può esimere dal rilasciare perché condizionano l'intero "ecosistema" internet.

Potrebbe benissimo farne a meno, visto che mantenere un s.o. che si avvia verso i DIECI anni di vita è già tanto.

La mia Fedora Core 2 dopo nemmeno SEI MESI non mi rilasciava più NESSUN aggiornamento.

Quante di queste in OEM ?
Quanti downgrade legittimi ?
Quanti downgrade illegittimi ?

Cosa non ti è chiaro di questo:

un s.o. che ha venduto più di 140 milioni di copie

?

Non esattamente.
Fanno risparmiare TEMPO, non soldi.
Un SW verticale, magari scritto da zero per quel compito, può essere fatto molto in fretta, il problema si presenta in seguito per mantenerlo aggiornato e per estenderne le funzionalità (specie se è programmato coi piedi).

Il software programmato coi piedi esiste per qualunque s.o..

Nella realtà poi chi vende il software ha tutto da guadagnarci a scrivere codice poco leggibile/difficilmente portabile per rendersi "indispensabile"... se poi riesce a strappare un contratto che non lo obbliga a rilasciare i sorgenti è in una botte di ferro perché una volta che la società adotta il software o continua ad andar dietro a lui o si trova con un mucchio d'istruzioni assembler inutilizzabili.

Linguaggio macchina. Comunque sta a chi ha accetta il contratto valutare i pro e i contro. Se compro quell'applicazione e spendo 1000€, ma all'anno ne risparmio 5000€, software fatto male, senza sorgenti o come vuoi, ho comunque un netto risparmio, e il gioco vale la candela.

Poco importa se non hai intenzione di migrare fuori da windows... altrimenti (se non vuoi precluderti la possibilità di una migrazione) importa eccome.

Alle aziende interessano le cifre, non la migrazione. E se c'è risparmio con una soluzione, se ne fregano di queste cose.

No, come dire "la società ci metterà un mesetto per adattare il codice a Gentoo... visto che c'è da lavorare intanto usiamo quello windows su Wine.

Un mese per codice Win32 è pura utopia. I progetti di un certo calibro richiedono PARECCHIO tempo per un eventuale porting su una piattaforma che delle API completamente diversamente.

Wine dovrebbero continuare a utilizzarlo per ANNI, non per mesi...

Avendo un contratto che obbliga l'Adobe a farlo sarebbero ca**i e penali di Adobe.

Adobe non ha questo tipo di contratti, per fortuna. E continua alacremente a lavorare alle sue applicazioni che non hanno eguali in nessun altro sistema, nonostante ci siano progetti open source vecchi di parecchi anni che tentano inutilmente di colmare non un gap, ma una voragine di differenza.

Ne ha, ma ha anche molti pregi che Windows NON AVRA'MAI (fra questi il prezzo).

Comincia a elencarli allora. Tra l'altro il prezzo non è nemmeno un pregio, quando devi PAGARE per una Red Hat Enterprise, come abbiamo fatto in azienda.

Relativamente...
La cretinaggine degli utenti dipende in buona parte dal training che gli fai.
E spesso e volentieri la gente viene ammollata davanti ad un PC con Windows senza fargli granché training (sulla base di "è windows, lo sanno usare tutti").

Che è la prassi, e non cambierà con nessun s.o. gli si metta davanti.

O vuoi forse dirmi che esistono schiere di appassionati Linuxiani che si offrono di fare training gratuito alle casalinghe?

Comincia a sommare licenze, costi per i server, costi per la manutenzione (hai presente quando hai un OS server e chiami Microsoft per chiedere assistenza ?) e vedi come lievitano i costi.

Le licenze rimangono l'unica variabile, e nemmeno sempre.

I costi dei server ci sono anche con Linux, quando c'è da pagare per una Red Hat Enterprise, come dicevo prima.

La manutenzione, poi, ha costi mediamente più elevati rispetto a quella per Windows.

Che in un ambito aziendale NON servono visto che in genere in un ambito lavorativo di applicazioni se ne usano pochissime.

Ma di che ambito stiamo parlando? Prendiamo una banca, ad esempio: secondo te gli bastano OpenOffice, ThunderBird, FireFox, e mettiamoci pure MySQL?

Per me stai generalizzando troppo.

Windows è il s.o.più diffuso perché la gente lo usa, non perché le aziende lo preferiscono.

Certo, perché giustamente i privati che hanno comprato licenze di Windows, Office, SQL Server, Visual Studio, ecc. l'hanno fatto perché MS gli ha puntato la pistola, quando potevano benissimo passare a Linux e altri prodotti open source...

Le aziende lo preferiscono perché la gente lo usa, cosa che lo rende "standard de facto".

Le aziende o la gente? Perché le aziende possono benissimo farne a meno, visto che i documenti di Office li possono leggere e scrivere con altri strumenti.

Quant'è per chiamata in caso di problemi in ambito server ?
Lessi 700 euro prima ancora di presentare il problema a Microsoft e senza l'assicurazione che venga risolto.

Vedi i prezzi che ha Red Hat.

Ad hominem.

Lo era il tuo "non dire bestemmie": io t'ho risposto con la stessa moneta.

Nulla vieta di distribuire gli eseguibili, su una FAMIGLIA DI OS come GNU/Linux in genere non si fa, ma all'interno della stessa distribuzione non è difficile veder girare gli eseguibili già belli compilati e pronti.

Già. E di distribuzioni ce ne sono un putiferio, contribuendo a caos e incompatibilità varie (LSB è soltanto un miraggio).

Almeno con Windows le versioni si contano sulle dite di una mano monca, e generalmente le applicazioni anche vecchie funzionano sui s.o. più moderni.

Qualcosa di molto simile lo puoi fare su una distribuzione.
Basta compilare i driver come moduli e distribuirli, nel caso facendo il backporting di quelli sviluppati per kernel successivi.
Una volta che li hai come moduli per il kernel comune alla distribuzione lo puoi tranquillamente distribuire in binario.

Tanto lavoro che verrà buttato non appena cambierà qualcosa nell'ABI.

Roba che, invece, su s.o. (non soltanto Windows) che offrono un'ABI stabile, non si verifica.

Come ? con un emulatore x86 per ARM ?

Esatto.

No, l'ho detto perché è così.

Ciò non toglie che hai colto al volo il mio invito a nozze.

Ma Java non lo sviluppa solo SUN.
Buona lettura : http://en.wikipedia.org/wiki/List_of...rtual_machines

Mai negato, e l'avevo anche scritto. Ripeto:

Tutte le altre si devono arrangiare.

fammi girare qualunque applicazione Java su AmigaOS, SkyOS, NewOS, ecc., e poi ne riparliamo.

Puoi avere sia i sorgenti java (come puoi avere i sorgenti c# e cacchi vari) sia i bytecode (per VM java o .net), non cambia granché.

Eh, no, perché i sorgenti Java li ha soltanto se vengono rilasciati, esattamente come per qualunque applicazione.

Del bytecode o dell'IML non te ne fai nulla: è come avere un codice eseguibile.

Java e .NET dimostrano, contrariamente a quanto tu richiedevi, che una qualunque applicazione può (potenzialmente, posto che ci sia un'adeguata VM) girare su qualunque piattaforma senza necessariamente avere i sorgenti. E non c'è né x86 né ARM né PowerPC che tenga.

Che domani il mio software lo vendo a chiunque e gira dovunque.
Se il cliente ha windows il codice gira su windows, se ha linux gira su linux, se ha freebsd gira su freebsd.

Falso. Stiamo parlando di applicazioni JAVA, che possono girare indifferentemente su Windows, Linux, ecc. (ovunque ci sia una VM adeguata).

Ripeto ancora: qual è il valore aggiunto di farle girare su Linux piuttosto che su Windows?

Sono tutto orecchi...

L'ho scritto quando ho parlato di STANDARD aperto.

Mono non è un implementazione sovrapponibile al 100% al .NET che Microsoft mantiene su Windows, da cui il risultato che quello che scrivi su .NET per Windows potrebbe non girare su Mono (l'ha detto anche il capoprogetto di Mono che c'è una parte di .NET Microsoft che ha a che fare col sistema sottostante e che ovviamente non sarà in Mono).

Stai cercando di rigirare la frittata. Cosa non ti è chiaro di questo:

.NET non è limitato a Windows o ai s.o. che MS decide di supportare. E' uno standard completamente aperto, e chiunque può realizzare runtime .NET

?

Tu avevi affermato questo invece:

.NET è limitato a Microsoft ed alle piattaforme che Microsoft decide di supportare

che è falso.

Con il piccolo problema che se .NET non è portabile non è che ne soffre la comunità open source, ne soffre .NET.
Se .NET non è portabile ed affidabile semplicemente la gente preferisce qualcosa di portabile ed affidabile, per cui .NET fallisce.

Questo è un non sequitur. Mi ripeto:

.NET non è limitato a Windows o ai s.o. che MS decide di supportare. E' uno standard completamente aperto, e chiunque può realizzare runtime .NET

Se è uno standard può essere portato ovunque. Altrimenti nemmeno OpenDocument, OpenXML, PDF, JPEG, MPEG, MP3, ecc. ecc. ecc. non sarebbero portabili.

Anche per Cobol esistono MIRIADI di applicazioni.

In tal caso non si capisce perché siano così pochi i programmatori COBOL, e così tanti i programmatori Win32, .NET, Java, ecc.

Prenditela con la polizia francese.

No, me la prendo con chi ha riportato una notizia priva di fondamento, con numeri da circo che non dicono proprio nulla.

Un thread che non sarebbe nemmeno dovuto essere aperto.

Originariamente inviato da elect

Cosa non ti è chiaro di quello che ho scritto? Cosa dovrei leggere? Sii chiaro, cortesemente.

[elect]

E' facile dire "ha venduto", quando la quasi totalità delle copie sono state imposte all'acquisto di un nuovo pc

[cdimauro]

Ha venduto. Punto.

Il resto sono soltanto illazioni: MS non obbliga nessuno con la pistola a comprare i suoi prodotti, egli accordi OEM avvantaggiano tutti (MS, OEM e utenti).

[elect]

Originariamente inviato da cdimauro

Ha venduto. Punto.

Il resto sono soltanto illazioni: MS non obbliga nessuno con la pistola a comprare i suoi prodotti, egli accordi OEM avvantaggiano tutti (MS, OEM e utenti).

Certo che ti obbliga

Gli accordi OEM avantaggiano MS, OEM e quelli utenti che vogliono MS


Mi sembra banale questo

[ConteZero]

Originariamente inviato da cdimauro

Potrebbe benissimo farne a meno, visto che mantenere un s.o. che si avvia verso i DIECI anni di vita è già tanto.

La mia Fedora Core 2 dopo nemmeno SEI MESI non mi rilasciava più NESSUN aggiornamento.

Se ti sei messo una Fedora meriti questo ed altro
Per il resto parlavamo di XP, che non mi pare abbia dieci anni.

Cosa non ti è chiaro di questo:

un s.o. che ha venduto più di 140 milioni di copie

?

Che i computer li devi vendere con un OS, e se Microsoft non offre più XP in OEM i produttori sono praticamente costretti a metterci Vista... ma questo non significa che Vista sia un SUCCESSO, significa solo che è SPOON FEED agli utenti finali.

Il software programmato coi piedi esiste per qualunque s.o..

Si, ma un s.o.che per anni ha dipeso dal codice fatto in VBasic parte avvantaggiato

Linguaggio macchina. Comunque sta a chi ha accetta il contratto valutare i pro e i contro. Se compro quell'applicazione e spendo 1000€, ma all'anno ne risparmio 5000€, software fatto male, senza sorgenti o come vuoi, ho comunque un netto risparmio, e il gioco vale la candela.

Questo dipende da chi trovi.
A qualcuno potrebbe anche non piacere il legarsi ad un architettura o ad un particolare programma o considerare la cosa solo nell'ottica di "risparmio €5000"... dipende dai casi.

Alle aziende interessano le cifre, non la migrazione. E se c'è risparmio con una soluzione, se ne fregano di queste cose.

No.
Ad alcune aziende interessano le cifre, ad altre interessa anche l'opportunità di migrazione, ad altre ancora un mix delle due.

Un mese per codice Win32 è pura utopia. I progetti di un certo calibro richiedono PARECCHIO tempo per un eventuale porting su una piattaforma che delle API completamente diversamente.

Wine dovrebbero continuare a utilizzarlo per ANNI, non per mesi...

Dipende dall'applicazione, da com'è stata strutturata, da chi l'ha fatta e da chi si occupa della migrazione.

Adobe non ha questo tipo di contratti, per fortuna. E continua alacremente a lavorare alle sue applicazioni che non hanno eguali in nessun altro sistema, nonostante ci siano progetti open source vecchi di parecchi anni che tentano inutilmente di colmare non un gap, ma una voragine di differenza.

E negli uffici tutti hanno Photoshop...
Invece cosine più discrete come Oracle sono disponibili più o meno ovunque.

Comincia a elencarli allora. Tra l'altro il prezzo non è nemmeno un pregio, quando devi PAGARE per una Red Hat Enterprise, come abbiamo fatto in azienda.

Performances (specie coi database), più flessibilità, nessun costo addizionale per X macchine, sistema completamente adattabile alle necessità del cliente e così via.

Che è la prassi, e non cambierà con nessun s.o. gli si metta davanti.

O vuoi forse dirmi che esistono schiere di appassionati Linuxiani che si offrono di fare training gratuito alle casalinghe?

No, ma se tanto devi fare il training ai dipendenti per spiegargli "linux" almeno alla fine del corso hai davanti gente che un corso in vita sua l'ha fatto

Le licenze rimangono l'unica variabile, e nemmeno sempre.

I costi dei server ci sono anche con Linux, quando c'è da pagare per una Red Hat Enterprise, come dicevo prima.

La manutenzione, poi, ha costi mediamente più elevati rispetto a quella per Windows.

Denuncia la polizia francese alla polizia...

Ma di che ambito stiamo parlando? Prendiamo una banca, ad esempio: secondo te gli bastano OpenOffice, ThunderBird, FireFox, e mettiamoci pure MySQL?

Per me stai generalizzando troppo.

Una banca, ai terminali, ha bisogno di molto meno.

Certo, perché giustamente i privati che hanno comprato licenze di Windows, Office, SQL Server, Visual Studio, ecc. l'hanno fatto perché MS gli ha puntato la pistola, quando potevano benissimo passare a Linux e altri prodotti open source...

No, perché se devi fare un sistema di banking online t'interessa che funzioni al meglio, e stranamente l'OS server che s'incastra meglio con l'OS desktop de facto è uno.
Stessa cosa per moltissimi altri ambiti... è per questo che Microsoft sono anni che combatte per mantenere segreti i dati relativi alla sua implementazione SMB.

Le aziende o la gente? Perché le aziende possono benissimo farne a meno, visto che i documenti di Office li possono leggere e scrivere con altri strumenti.

Le aziende usano windows per una questione di praticità e per una questione di maggior integrazione coi sistemi desktop (dove occorre).

Vedi i prezzi che ha Red Hat.

Nel caso di cui parlavamo sopra (le P.A.) si può anche fare un nucleo interno per queste cose, azzerando i costi.

Lo era il tuo "non dire bestemmie": io t'ho risposto con la stessa moneta.

Non è colpa mia se bestemmi.

Già. E di distribuzioni ce ne sono un putiferio, contribuendo a caos e incompatibilità varie (LSB è soltanto un miraggio).

Ma in un azienda e/o P.A. si usa tutti la stessa distribuzione (possibilmente interna), azzerando questo genere di problemi.
Non penso che lo Stato Italiano avrebbe problemi d'incompatibilità se usasse "ItaLinux" (nome a caso) sviluppato internamente in tutte le sue macchine.

Almeno con Windows le versioni si contano sulle dite di una mano monca, e generalmente le applicazioni anche vecchie funzionano sui s.o. più moderni.

Che è anche l'unico modo per farle funzionare.

Tanto lavoro che verrà buttato non appena cambierà qualcosa nell'ABI.

A meno di non stabilizzarsi su un kernel e mantenere quello, facendo il backporting di quel che serve (come faceva, se non erro, la RedHat che ti piace tanto).

Roba che, invece, su s.o. (non soltanto Windows) che offrono un'ABI stabile, non si verifica.

Infatti i driver per 98 vanno meravigliosamente bene su 2000

Esatto.

Ecco, quindi ho la piena portabilità, basta mettere un emulatore x86 ed installarci sopra un sistema operativo Windows, dopodiché posso fare girare il mio bell'exe win32 su ARM.
Le considerazioni dal punto di vista delle performance non le facciamo eh

Ciò non toglie che hai colto al volo il mio invito a nozze.

Tu parli, io rispondo.

Mai negato, e l'avevo anche scritto. Ripeto:

Tutte le altre si devono arrangiare.

fammi girare qualunque applicazione Java su AmigaOS, SkyOS, NewOS, ecc., e poi ne riparliamo.

Su quegli OS non ci gira manco .NET

Eh, no, perché i sorgenti Java li ha soltanto se vengono rilasciati, esattamente come per qualunque applicazione.

Del bytecode o dell'IML non te ne fai nulla: è come avere un codice eseguibile.

Java e .NET dimostrano, contrariamente a quanto tu richiedevi, che una qualunque applicazione può (potenzialmente, posto che ci sia un'adeguata VM) girare su qualunque piattaforma senza necessariamente avere i sorgenti. E non c'è né x86 né ARM né PowerPC che tenga.

STRONZATE.
Il bytecode è portabile si, ma se non c'è una VM te ne fai assai.
Java ha VM funzionanti al 100% su almeno quattro PIATTAFORME, e VM più o meno efficienti su quasi tutte le altre, .NET ha la VM su UNA piattaforma, ed un implementazione fallace in qualche altra.
La differenza è evidente

Falso. Stiamo parlando di applicazioni JAVA, che possono girare indifferentemente su Windows, Linux, ecc. (ovunque ci sia una VM adeguata).

Tu parlavi di .NET, io parlavo di Java.

Ripeto ancora: qual è il valore aggiunto di farle girare su Linux piuttosto che su Windows?

Di Java nessuno (considerazioni relative alle performance a parte), è portabile.
Di .NET... voglio vedere chi è che si compra un applicazione .NET per Linux... è una piattaforma portatile "per finta"

L'ho scritto quando ho parlato di STANDARD aperto.

Ecchissenefrega che è aperto.
E'nato sotto Windows, è pensato per usare al massimo Windows e le implementazioni "fuori Windows" non possono (ovviamente) fornire quell'extra... il risultato è che nessuno lo vuole "fuori Windows", col risultato che la portabilità "reale" è limitata a Windows, cioè estremamente ridotta.

Stai cercando di rigirare la frittata. Cosa non ti è chiaro di questo:

.NET non è limitato a Windows o ai s.o. che MS decide di supportare. E' uno standard completamente aperto, e chiunque può realizzare runtime .NET

?

Tu avevi affermato questo invece:

.NET è limitato a Microsoft ed alle piattaforme che Microsoft decide di supportare

che è falso.

.NET è implementato perfettamente solo su piattaforme Microsoft, e Microsoft non vuole supportarlo al di fuori di Windows (a differenza di Sun).
Il risultato è che nessuna società s'azzarderebbe ad usare .NET fuori da Windows (e questo anche perché Mono è tutto fuorché completo) mentre Java lo si usa dovunque... segue che .NET nel suo proposito originario (essere un contendente a Java sulla portabilità) ha fallito miseramente.

Questo è un non sequitur. Mi ripeto:

.NET non è limitato a Windows o ai s.o. che MS decide di supportare. E' uno standard completamente aperto, e chiunque può realizzare runtime .NET

Se è uno standard può essere portato ovunque. Altrimenti nemmeno OpenDocument, OpenXML, PDF, JPEG, MPEG, MP3, ecc. ecc. ecc. non sarebbero portabili.

Semplicemente perché non è uno standard credibile, tant'è che nemmeno chi l'ha proposto ha fatto qualcosa per spingere sulla portabilità della sua creazione, anzi.
Chi se lo deve filare uno standard che è supportato solo in casa propria ?

In tal caso non si capisce perché siano così pochi i programmatori COBOL, e così tanti i programmatori Win32, .NET, Java, ecc.

Perché il COBOL fa cagare.
Ed anche .NET, dal punto di vista degli sviluppatori, non è che sia esattamente il massimo.
Per quanto possa essere "fighetto" senza una portabilità seria se domani Windows iniziasse a perdere quote di mercato stramazzerebbe al suolo.

No, me la prendo con chi ha riportato una notizia priva di fondamento, con numeri da circo che non dicono proprio nulla.

Denuncia la polizia!

[cdimauro]

Originariamente inviato da elect

Certo che ti obbliga

In tal caso puoi sempre denunciarla.

Gli accordi OEM avantaggiano MS, OEM e quelli utenti che vogliono MS

Mi sembra banale questo

Ottimo, e non ci vedo nulla di male.

Originariamente inviato da ConteZero

Se ti sei messo una Fedora meriti questo ed altro

Sì, lo so: con Linux quando hai problemi la colpa è sempre della distro sbagliata.

Per il resto parlavamo di XP, che non mi pare abbia dieci anni.

Appunto, ed è ancora supportato. Una distro ben più recente, invece, ha cessato COMPLETAMENTE il supporto dopo pochi mesi.

Che i computer li devi vendere con un OS, e se Microsoft non offre più XP in OEM i produttori sono praticamente costretti a metterci Vista... ma questo non significa che Vista sia un SUCCESSO, significa solo che è SPOON FEED agli utenti finali.

In tal caso dovremmo vedere schiere di utenti effettuare il downgrade a XP. Leggendo in giro, invece, mi sembra ci sia gente soddisfatta di Vista. Dai un'occhiata alla sezione Windows del forum, ad esempio.

Si, ma un s.o.che per anni ha dipeso dal codice fatto in VBasic parte avvantaggiato

Senza ombra di dubbio. Vuoi mettere col codice scritto in C? Non c'è paragone: VB tutta la vita.

Questo dipende da chi trovi.
A qualcuno potrebbe anche non piacere il legarsi ad un architettura o ad un particolare programma o considerare la cosa solo nell'ottica di "risparmio €5000"... dipende dai casi.

No.
Ad alcune aziende interessano le cifre, ad altre interessa anche l'opportunità di migrazione, ad altre ancora un mix delle due.

Devo ancora trovarla un'azienda a cui interessa la migrazione: finora ho sempre visto aziende che si fanno i conti su come abbattere le spese e incrementare i guadagni.

Dipende dall'applicazione, da com'è stata strutturata, da chi l'ha fatta e da chi si occupa della migrazione.

Domanda: hai idea delle differenze che ci sono fra un'applicazione che usa le API Win32 e un'altra che utilizza lo standard POSIX?

Basta prendere un progetto anche piccolo, come ad esempio PSPadPro che è open source: dagli un'occhiata e dimmi quanto ci impiegheresti per portarlo su Linux, BSD, Mac OS X, o altro (posto che dovresti scegliere anche quali librerie usare per svilupparlo).

Questo perché Windows con Linux non c'entra una mazza a livello di API.

E negli uffici tutti hanno Photoshop...

Era un esempio di applicazione professionale abbastanza complessa da rendere particolarmente difficile e oneroso il porting su Linux.

Invece cosine più discrete come Oracle sono disponibili più o meno ovunque.

Indubbiamente, anche per il tipo prodotto, che necessita di poche funzionalità del s.o. per funzionare.

Ma di Oracle non ci sono i sorgenti: se ti leghi a questo prodotto rischi di farti ingabbiare, come disse qualche utente prima.

Performances (specie coi database),

Bisogna vedere le differenze.

più flessibilità,

In cosa?

nessun costo addizionale per X macchine,

Queste sono le licenze, ma ne abbiamo già parlato.

sistema completamente adattabile alle necessità del cliente e così via.

Se per cliente intendi una società che sviluppa il nocciolo di una centrale nucleare, può essere. Ma per la stragrande maggioranza delle applicazioni che interessano ad aziende e privati è del tutto inutile.

No, ma se tanto devi fare il training ai dipendenti per spiegargli "linux" almeno alla fine del corso hai davanti gente che un corso in vita sua l'ha fatto

Ho tenuto corsi del genere per Windows. Quindi non ci sarebbero differenze.

Denuncia la polizia francese alla polizia...

OK, ho capito che non vuoi rispondere.

Una banca, ai terminali, ha bisogno di molto meno.

Ai terminali le banche hanno generalmente software in DOS portato malamente su Windows, giusto per farlo funzionare su questo s.o..

Ma le banche non hanno soltanto terminali.

No, perché se devi fare un sistema di banking online t'interessa che funzioni al meglio, e stranamente l'OS server che s'incastra meglio con l'OS desktop de facto è uno.

Stessa cosa per moltissimi altri ambiti...

Mi stai dicendo che Linux non può essere un'alternativa valida in questi casi?

è per questo che Microsoft sono anni che combatte per mantenere segreti i dati relativi alla sua implementazione SMB.

Non sono segreti: paghi le licenze e ne usufruisci. Non è che MS può svendere il SUO lavoro.

Le aziende usano windows per una questione di praticità e per una questione di maggior integrazione coi sistemi desktop (dove occorre).

Quindi hanno la loro convenienza nel farlo.

Nel caso di cui parlavamo sopra (le P.A.) si può anche fare un nucleo interno per queste cose, azzerando i costi.

I costi non vengono azzerata, ma semplicemente spostati. Il "nucleo" dev'essere retribuito, formato, e aggiornato.

Non è colpa mia se bestemmi.

Siamo in due a farlo: inutile lamentarsi. E non dovrei ricordarti che non ho cominciato io con questa storia.

Ma in un azienda e/o P.A. si usa tutti la stessa distribuzione (possibilmente interna), azzerando questo genere di problemi.
Non penso che lo Stato Italiano avrebbe problemi d'incompatibilità se usasse "ItaLinux" (nome a caso) sviluppato internamente in tutte le sue macchine.

Anch'esso ha un costo, che si aggiunge a quelli di cui sopra.

Che è anche l'unico modo per farle funzionare.

Se Windows è diventato il dominatore del mercato, è perché le cose, nel bene o nel male, hanno funzionato.

Altrimenti sarebbe affondato miseramente.

A meno di non stabilizzarsi su un kernel e mantenere quello, facendo il backporting di quel che serve (come faceva, se non erro, la RedHat che ti piace tanto).

Questo, però, è il "modello" usato da Windows e altri s.o.. Allora che ha senso ha perseguire la compatibilità "by source", come fa Linux?

Infatti i driver per 98 vanno meravigliosamente bene su 2000

I cambi nelle major release capitano per qualunque s.o. che si rispetti. Sono i cambi "intra-release" che creano problemi, e di cui sono affetti "certi" s.o..

Inutile che ti ricordi che persino il ciclo di sviluppo dispari / pari di Linux, che prima offriva una certa stabilità, è andato a farsi benedire da qualche tempo a questa parte, a forza di introdurre modifiche e funzionalità "in corso" d'opera.

Non so tu, ma io come sviluppatore ho bisogno di stabilità. Non di continui aggiornamenti.

Ecco, quindi ho la piena portabilità, basta mettere un emulatore x86 ed installarci sopra un sistema operativo Windows, dopodiché posso fare girare il mio bell'exe win32 su ARM.
Le considerazioni dal punto di vista delle performance non le facciamo eh

Era un requisito? Da quel che avevi scritto non mi pare. Tu avevi posto un dictat assoluto, e mi sono semplicemente premurato di smontartelo subito.

Su quegli OS non ci gira manco .NET

Non è questo il punto, e lo sai bene. Se non ti va di rispondere, non c'è problema: basta che lo dici chiaro e tondo.

STRONZATE.
Il bytecode è portabile si, ma se non c'è una VM te ne fai assai.

Che ho detto io?

Java ha VM funzionanti al 100% su almeno quattro PIATTAFORME, e VM più o meno efficienti su quasi tutte le altre, .NET ha la VM su UNA piattaforma, ed un implementazione fallace in qualche altra.
La differenza è evidente

Sì, e non era questa la materia del contendere. Nello specifico, ti ricordo che hai sempre parlato di valore dei sorgenti in quanto garantiscono la portabilità del codice. Io ti ho fatto un esempio che dimostra che la portabilità del codice può benissimo fare a meno dei sorgenti, e per giunta con una soluzione che tu stesso hai tirato in ballo: Java.

Poi, ripeto, se non ti va di rispondere alle specifiche questioni che man mano stiamo trattando, per me non c'è problema, ma dillo chiaramente e non spostare il discorso verso altri lidi.

Tu parlavi di .NET, io parlavo di Java.

Io ho parlato di .NET. Tu hai risposto parlando prima di Java e POI di .NET. Io ho risposto in maniera precisa alle cose che hai scritto prima su Java e poi su .NET.

Nello specifico, stavamo parlando di Java e non di .NET. Vatti a rileggere lo scambio di messaggi che abbiamo avuto su questa parte. Per comodità ti riporto quello che avevo scritto e la tua risposta su questo specifico punto:

IO: Terzo, dovresti dirmi qual è il valore aggiunto di far girare un'applicazione Java su Linux piuttosto che su Windows. Il "risparmio" di cui s'è parlato finora dove starebbe?

TU: Che domani il mio software lo vendo a chiunque e gira dovunque.
Se il cliente ha windows il codice gira su windows, se ha linux gira su linux, se ha freebsd gira su freebsd.

Anche qui, ripeto, se non vuoi rispondere per me non c'è problema. Ma sii chiaro una buona volta.

Di Java nessuno (considerazioni relative alle performance a parte), è portabile.

Bene. Era quello che m'interessava. Grazie.

Di .NET... voglio vedere chi è che si compra un applicazione .NET per Linux... è una piattaforma portatile "per finta"

Su Linux sì, perché c'è gente che sviluppa runtime .NET "per finta", come dici tu.

Ecchissenefrega che è aperto.

Frega nel momento in cui TU fai una PRECISA affermazione che si scontra contro degli altrettanto precisi FATTI. Nello specifico, che .NET è uno STANDARD.

E'nato sotto Windows, è pensato per usare al massimo Windows e le implementazioni "fuori Windows" non possono (ovviamente) fornire quell'extra...

E altrettanto ovviamente mi spiegherai cos'è questo "extra" e perché non si può fornire su piattaforme diverse da Windows.

il risultato è che nessuno lo vuole "fuori Windows", col risultato che la portabilità "reale" è limitata a Windows, cioè estremamente ridotta.

Questo è un altro discorso, se permetti, e riguarda l'ATTUALE situazione delle IMPLEMENTAZIONI disponibili.

Che non intacca di una virgola il fatto che .NET sia uno standard, e che sia portabile.

.NET è implementato perfettamente solo su piattaforme Microsoft, e Microsoft non vuole supportarlo al di fuori di Windows (a differenza di Sun).
Il risultato è che nessuna società s'azzarderebbe ad usare .NET fuori da Windows (e questo anche perché Mono è tutto fuorché completo) mentre Java lo si usa dovunque...

Eppure i progetti sviluppati con Mono non mancano. Quindi non solo sono fuori da Windows, ma sono fuori di testa quelli che li hanno sviluppati.

Fermo restando che non è in discussione la diffusione delle implementazioni di .NET.

segue che .NET nel suo proposito originario (essere un contendente a Java sulla portabilità) ha fallito miseramente.

Purtroppo noto che sconosci anche la storia di .NET, che non è certo nato per contendere la "portabilità" a .NET.

Anzi, per dirla tutta, la portabilità di .NET è soltanto una conseguenza delle sue specifiche, del motivo per cui è nato. Un valore aggiunto, giusto per essere chiari.

Quindi se mi parli di "fallimento" legato al presunto obiettivo della portabilità, non posso che farmi delle grasse risate.

Semplicemente perché non è uno standard credibile, tant'è che nemmeno chi l'ha proposto ha fatto qualcosa per spingere sulla portabilità della sua creazione, anzi.

Idem come sopra: la portabilità non è mai stato l'obiettivo originale che ha portato alla creazione di .NET. Ma nella maniera più assoluta.

Leggiti le interviste al creatore di .NET e C#, che tra parentesi è lo stesso che in passato ha creato il Turbo Pascal prima e Delphi poi.

Poi sulla "credibilità" dello standard, non vedo cosa ci sarebbe da dire: è uno standard, e tanto basta.

Chi se lo deve filare uno standard che è supportato solo in casa propria ?

Fai una cosa: contatta gli sviluppatori di Mono, e digli che sono semplicemente dei pazzi a perseguire nel loro lavoro.

Oppure accetta il fatto che se c'è gente che s'è impuntata con la creazione di un runtime di .NET alternativo a quello di MS, avrà avuto le sue buone ragioni e vede in ciò un notevole potenziale.

Perché il COBOL fa cagare.

Ed è molto difficile vedere nuovi progetti utilizzare questo linguaggio. E' usato più che altro per mantenere il software già scritto.

Ed anche .NET, dal punto di vista degli sviluppatori, non è che sia esattamente il massimo.

Come sviluppatore ho un'opinione diametralmente opposta alla tua. Anzi, ben venga .NET, e spero che in futuro tutte le applicazioni o quasi vengano scritte per esso.

Per quanto possa essere "fighetto" senza una portabilità seria se domani Windows iniziasse a perdere quote di mercato stramazzerebbe al suolo.

Ripeto: non è questo il suo obiettivo. La portabilità "seria" non riguarda .NET, che è uno standard, ma le sue implementazioni.

Denuncia la polizia!

Per cosa? Per aver riportato un documento pubblicitario?

[entanglement]

Originariamente inviato da elect

Certo che ti obbliga

Gli accordi OEM avantaggiano MS, OEM e quelli utenti che vogliono MS


Mi sembra banale questo

e ha pure preso una bella serie di multe per questo.

[cdimauro]

Le multe le ha prese per pratiche di concorrenza sleale, non per aver siglato accordi con gli OEM, che sono ancora in essere.

[:dissident:]

Originariamente inviato da _BlackTornado_

Bhe... Riguardo alla notizia in questione, non so bene da dove vengano le cifre... Riguardo le pubbliche amministrazioni italiane, però, posso portare qualche esempio...

CUT

Dite che con tutti sti soldi, una distro "SaniLinux" e uno staff di pure 500 persone che la seguono non ci esce???

Questo discorso non ha senso, se la PA volesse fare un software "pubblico" per l'utilizzo in questo ambito lo farebbe cmq anche sotto WIN.

[elect]

Originariamente inviato da cdimauro

In tal caso puoi sempre denunciarla.

Ottimo, e non ci vedo nulla di male.

Non vuoi capire eh?

Vabbè..

[cdimauro]

Evidentemente non ti spieghi bene. Parla chiaro: cosa vorresti dire di preciso?

[elect]

Originariamente inviato da cdimauro

Evidentemente non ti spieghi bene. Parla chiaro: cosa vorresti dire di preciso?

Ogni utente dovrebbe avere la possibilità di rinunciare a comprare anche del software all'acquisto di hardware


Perchè dovrei essere obbligato a prendere anche del software (Microsoft in questo caso, Apple nel caso di mac)?

[:dissident:]

Originariamente inviato da elect

Ogni utente dovrebbe avere la possibilità di rinunciare a comprare anche del software all'acquisto di hardware

e cosi' e' infatti

[elect]

Originariamente inviato da :dissident:

e cosi' e' infatti

Tranne rarissimi casi, no

[:dissident:]

Originariamente inviato da elect

Tranne rarissimi casi, no

Non ne sarei cosi' sicuro

[elect]

Originariamente inviato da :dissident:

Non ne sarei cosi' sicuro

Bè, io ho visto veramente pochi casi e quelli che dove era permesso consisteva semplicemente nel rimandare indietro la licenza con tutta una procedura laboriosa dietro

(a parte i netbook con linux, ovvio)

[:dissident:]

Originariamente inviato da elect

Bè, io ho visto veramente pochi casi e quelli che dove era permesso consisteva semplicemente nel rimandare indietro la licenza con tutta una procedura laboriosa dietro

(a parte i netbook con linux, ovvio)

E' valido per tutti i computer con installato windows che io sappia, e il fatto che sia magari laboriosa come prrocedura non vuol dire che sia impossibile come sostenevi

[elect]

Originariamente inviato da :dissident:

E' valido per tutti i computer con installato windows che io sappia, e il fatto che sia magari laboriosa come prrocedura non vuol dire che sia impossibile come sostenevi

Che io sappia solo Acer prevede una procedura del genere