[MontelLUG] Vista funziona! E anche bene!

Mar 21 Ago 2007 09:54:17 CEST

> >
> > Questo l'ho notato anche io, ma sarei piuttosto restio a pensare che
> > un gestionale sia una killer app per Linux.
> Non dico che sia un'applicazione fondamentale per linux, quanto il fatto che
> nelle aziende proliferano tutta una serie di programmi più o meno
> personalizzati che vanno dal controllo di produzione alla contabilità
> passando per il magazzino. Nelle aziende che conosco la maggior parte di
> essi è sviluppata sotto win. L'utente se al lavoro è abituato ad usare win,
> a casa non vorrà vedersi linux. Tieni conto che la maggior parte degli
> utenti di pc, ad esclusione di quelli usciti dalle scuole negli ultimi anni,
> ha avuto il primo approccio con il pc sul posto di lavoro.
>
La risposta è colossale già così, quindi cerco di essere breve e
taglio a manetta.
Il problema, come dici tu stesso qui che quasi tutti usano Windows,
quindi è ovvio che le software house usino Windows. Se Linux fosse
installato sul 95% dei PC e i PC venissero venduti quasi tutti con
Linux preinstallato, sono quasi pronto a scommettere grosse cifre che
quasi tutti i programmi (sì, anche i gestionali :-) ) sarebbero
scritti per Linux. 1 mese di flame per scoprire l'acqua calda?

>
> > Non ho mai sviluppato un gestionale, ma limitare l'usi del C/C++ a
> > cose di basso livello è sinceramente un pregiudizio che si sente
> > spesso, ma a mio parere del tutto ingiustificato. La gestione della
> > memoria è una rogna, è vero, ma quando mio fratello mi ha spiegato
> > per sommi capi come ad esempio Java gestisce certe cose, ti giuro che
> > ho rimpianto i puntatori.
>
> Io conosco bene il C, al C++ ho dato solo un'occhiata quando ero infognato
> nei programmi C e cercavo un'alternativa. In seguito ho chiesto
> delucidazioni a chi diceva di conoscerlo riguardo ad alcuni aspetti critici
> che avevo con il C e mi è stato confermato che continuano ad esistere in
> C++.

Beh, C++ è un tantino diverso da C. Ma ha di bello la
retrocompatibilità, che non è affatto poco.
In verità non è proprio che i problemi siano stati ereditati, è che se
vuoi puoi programmare "C style", e ovviamente il compilatore si
comporta in quel caso come quello C. Ma dovendo usare una stringa di
lunghezza variabile non mi metterei mai a fare a mano, includo
"string.h".
Comunque non ho mai detto che il C++ sia facile come un linguaggio di
alto livello, ma tu avevi detto che andava bene solo per i driver, che
non è esattamente vero.

>
> Dalla mia esperienza in 3 software house diverse, sviluppare un gestionale
> significa:
> a) partire con lo sviluppo una settimana dopo la data di consegna;
> b) in alcuni casi ti trovi un'analisi di 110 ore contenuta su una pagina A4
> scritta con Arial 12;
> c) quando consegni il programma al cliente di norma c'è sempre qualcosa che
> chi ha fatto l'analisi non si è capito con il cliente ed è da rifare, a
> volte anche con modifiche pesanti. Quando va bene manca solo qualche
> funzionalità;
> d) il cliente dopo qualche giorno di utilizzo ha subito in mente nuove
> implementazioni, il fatto che queste a volte implichino il ribaltare la
> logica del programma ha poca importanza;
> e) "Questo programma ha eseguito un'operazione non valida e sarà terminato.
> Se il problema persiste contattare il fornitore del programma." non è un bel
> messaggio che compare a video dopo che uno ha caricato un centinaio di righe
> di bolla e preme il pulsante per registrarla;
> f) ultimo ma molto importante: i dati che vengono scritti sul database sono
> SACRI, quindi una stampa che mentre stampa i dati li cancella anche
> dall'archivio a causa di un buffer overflow non è cosa carina.
>
> La mia esperienza personale di lavoro ad un gestionale in C Ansi (no C++ in
> quanto doveva essere retrocompatibile con alcuni dinosauri UNIX) è stata
> decisamente traumatica. In quei 14 mesi ho visto più clienti incazzati,
> casini e perdite di dati che in 7 anni dove lavoro adesso (qui nessuno
> finora ha mai perso un dato per colpa del programma).
> Lo so che se un programma ha un problema è colpa del programmatore, però
> devi anche ammettere che dopo 8/9 ore passate davanti ad un monitor,
> alternando 10 minuti di sviluppo a mezz'ora di assistenza telefonica, ad un
> certo punto il cervello va anche a quel paese, quindi dimenticarti un &
> oppure qualche sostituzione di variabile in un copia incolla di massa può
> succedere.
> Quindi avere un compilatore che non fa un minimo di controllo sui tipi di
> dati nel passaggio di parametri a funzioni oppure in caso di assegnazioni in
> pezzi di codice dove usi un puntatore a stringa ogni volta di dimensioni
> diverse ogni tre righe di codice, non è di aiuto.
> Se poi ci aggiungi il fatto che devi sviluppare il più rapidamente
> possibile, che non appena il programma supera un minimo di test è già
> consegnato al cliente e che a volte devi fare copia e incolla di massa per
> ribaltare la logica, penso tu possa capire quanti casini vengono fuori in
> quei programmi.
> Per me il successo di programmi come COBOL, Clipper/dbIV, Vb e Delphi è
> dovuto al fatto che una volta compilato sei sicuro che il programma esegue
> quello che hai scritto. Se il programma non fa quello che ti aspetti è
> perché c'è un errore di logica e non perché un'assegnazione a una variabile
> ha modificato il valore della variabile adiacente in memoria, oppure
> un'azzeramento di stringa è andato a sovrascrivere una parte di memoria dove
> c'è il codice eseguibile e quindi l'eccezione ti viene sollevata da un'altra
> parte del programma che non ha niente a che fare.
> Ti dico, in quei 14 mesi ne ho viste di tutti i colori e non mi sono
> scottato, ma ho riportato ustioni di 3° grado.
> Senza contare le opzioni di ottimizzazione del compilatore. Mi avevano detto
> che quando dovevo consegnare il programma al cliente era bene compilarlo in
> modalità release (più veloce e compatto). Poi dopo che al cliente si blocca
> il programma in fase di fatturazione e questo chiama diretto il tuo capo, il
> quale si mette a strillarti dientro (con tutte le porte degli altri uffici
> del piano che magicamente si chiudono sincronizzate) senza sentire ragioni,
> poi scopri che mentre la versione compilata in debug funziona, mentre quella
> in release va in eccezione e non si capisce il punto, stai certo che dopo la
> prima volta non ho più consegnato programmi compilati in release, ma in con
> tutte le informazioni di debug incluse, e se il programma è troppo pesante
> che il cliente si prenda un pc più potente.
>
> Poi se uno si può permettere di scrivere il programma in un ambiente dove
> chi è addetto allo sviluppo fa solo quello, le date di consegna sono umane,
> oltre a te ci sono anche altre persone che fanno i test, il codice è scritto
> secondo sani principi di programmazione strutturata e non da profondi
> estimatori dei goto, allora ti posso anche credere se dici che il C può
> andare bene anche per altri tipi di applicazioni.
> Alla fin fine, un gestionale lo puoi anche scrivere in assembler, nessuno te
> lo vieta, ma vienne fuori poi.

Beh, tutta questa cosa è una ironica descrizione di quanto capita
sempre nelle aziende quando si parla di progetti software, in
qualsiasi linguaggio siano scritti, non capisco cosa abbia a che fare
con la diffusione di Linux.  E se devo fare un confronto fra gcc/g++ e
Visual C++, 1000 volte gcc!

Compilare in debug la versione da consegnare! LoL!

>
> Purtroppo almeno nel compilatore di visual studio 5 che usavo oppure sul cc
> di Sco Unix 5.x non mi risultava ci fosse un'opzione per fare il range
> checking delle variabili e altri controlli simili.
>
> > Ah, conosci wxWidgets? In caso negativo, preparati al mio talk per le
> > conferenze autunnali :-)
>
> No, ho usato solo librerie proprietarie vecchie più del cucco.

Ecco, forse qui sta il problema, ma non è colpa dei
linguaggi/compilatori per Linux. Anzi, in questo caso l'Open Source è
la soluzione del tuo problema.

>
> >
> > La portabilità è una bella gatta da pelare: in pratica si hanno poche
> > alternative se si vuole mantenerla:
>
> Concordo.
> L'ideale sarebbe wine.

Non concordo: wine è molto utile, ma non credo possa essere la
soluzione definitiva. L'unica via è un programmatore intelligente che
ne tiene conto in fase di design.
> >> Sinceramente, sotto linux che ci sia il desktop con il cubo oppure
> >> che le finestre abbiano le trasparenze per me lascia il tempo che
> >> trova.
> >
> > Invece conta, anche l'occhio vuole la sua parte e non tutti gli
> > utenti sono sviuppatori o sysadmin.
> >
> Ok, anche l'occhio vuole la sua parte, ma se vado dal cliente e gli mostro
> guarda che bello che è il cubo, ma non ha i programmi che gli servono, tira
> fuori il cubo dallo schermo e me lo da giù per la testa.

In tutte le tue argomentazioni vedo un filo conduttore che dice:
"Linux non va bene per quello che sto facendo ora al lavoro" e che
generalizza questo a "Linux non va bene". Il passaggio logico non mi
pare davvero corretto: la bellezza e la potenza dell'Open Source si
sono dimostrate invece proprio nel "non mi piace questa cosa/ non
trovo nessuno che abbia fatto quello che mi serve / vorrei fare una
cosa nuova o diversa: mi arrangio". Sfrugugliando tra i repository di
una qualsiasi Debian mi rendo conto che ci sono tantissime app. di cui
non esiste l'equivalente nel mondo Win, non è solo il contrario.
Il cubo rotante non sarà necessario in ambito lavorativo, ma ha delle
ripercussioni davvero interessanti, e per come la vedo io, tra non
molto il progetto compiz ci mostrerà come saranno le interfacce del
futuro. Quando sono uscite le GUI sicuramente molti hanno storto il
naso.

> Ricorda che un pc sicuro, è un pc con il cavo di rete staccato :-)
> Che metodo usi per l'invio via mail?

Un PC con il cavo di rete staccato nel 2007 non è sicuro, è inutile.
> L'msdn ammetto che in alcuni casi è un po' ostica, ma penso che sia un
> problema in generale di tutta la documentazione. Documentare tutti i
> possibili problemi penso sia impossibile.
> Poi per l'aiuto che puoi trovare su internet, penso molto non dipenda tanto
> dal prodotto quanto da chi ti trovi dall'altra parte in quel momento, se ha
> il tempo e voglia di darti una mano.

Dissento. In MSDN si deve invocare vari dei anche di religioni antiche
per trovare (forse) qualcosa. Se cerchi nella documentazione dei
programmi Open Source o nei forum di programmazione in ambiente Linux,
difficilmente non troverai qualche indicazione utile.
>
> Diego Rondini wrote:
>
>
> > Prendi il pallottoliere che poi ti faccio tre domandine:
> > 1) fai il rapporto tra numero di computer desktop e computer server
> > con Linux?
> > 2) fai lo stesso rapporto desktop/server per Windows?
> > 3) è più diffuso Linux o Windows?
> > Ora scrivi un tema sulle conclusione che ne trai. :-)
>
> In generale nelle ditte dove gironzolo, contando i clienti più grossi almeno
> 200 client totali win, 20ina di server windows, 3 server di posta linux.
> L'unica cosa che vedo e che sapevo già senza fare tanti conti è che win è
> più diffuso.
> Il mio discorso non si basava tanto sulla diffusione, quanto sul fatto di
> che possibilità ho per farlo entrare in uso anche in un certo tipo di
> ambiente lavorativo/produttivo.

Le possibilità ci sono eccome. Nessuno dice che sia facile, ma siam
qua come LUG proprio per far vedere che è possibile.
>
>
> > Appunto, è quello di cui senti la necessità tu. Ognuno ha le sue
> > necessità, chi vuole una piattaforma di sviluppo, chi un CAD, chi un
> > gestionale, chi server, ecc. Certo è che chi sceglie Linux non lo fa
> > per semplificarsi la vita!

Io sì: Linux mi semplifica la vita lavorativa tutti i giorni! :-D
>
> Intanto io non sto prentendendo niente da nessuno. Ho semplicemente detto
> che mi piacerebbe se in linux ci fossero certe cose, in modo da potermi
> permettere di scrivere programmi e così aumentare la diffusione.
> Questo alla fine è sempre il solito discorso, si sente tanto invocare i vari
> pregi, ma appena uno fa un appunto viene prontamente freddato e in modo più
> o meno gentile gli viene detto "Questo el xe. se nol te comoda fatte ti queo
> che te serve".

Quello che mi lascia perplesso è che non vedo questa carenza di
linguaggi/compilatori/ide per tutte le esigenze che denunci tu. A me
pare che tool di sviluppo ci sia solo l'imbarazzo della scelta. Se ci
stai invece dicendo che vorresti portare il codice che hai fatto sotto
Win fino a oggi senza colpo ferire, beh, questa sinceramente è una
richiesta legittima, ma un po' eccessiva, soprattutto se il codice è
nelle condizioni che hai descritto qua e là nella mail.

> Adesso, spero di riuscire con quattro parole a riassumere il succo del mio
> discorso:
> "Se la diffusione di un sistema operativo passa per il numero di software
> che ci possono girare e dal numero di sviluppatori che ci stanno dietro,
> dovrebbe essere un obiettivo di chi "gestisce" il sistema operativo fornire
> gli strumenti per poter creare il software.
> Il compilatore c è indispensabile, ma non lo vedo sufficiente. Invece di
> avere n diversi progetti che portano avanti ambienti di sviluppo, con il
> rischio di vari fork, non sarebbe bello se la gnu (o chi coordina un po'
> tutta la baracca) dicesse creiamo anche degli altri compilatori "standard"
> che possano essere utilizzati per altri tipi di applicazioni? Ad esempio nel
> campo delle pagine web si è affermato con successo php."
> Non sono riuscito ancora a rendere il concetto. Spero si sia capito.

Più o meno. Purtroppo questo è uno dei limiti, ma al tempo stesso dei
punti di forza dell'Open Source: nessuno comanda la baracca! Il che
ovviamente si porta dietro il problema della dispersività. Ma a volte
dai fork (Firefox, per es) viene fuori il meglio.

Ciao
CD