Newsgroup: it.comp.os.linux.development
Titolo: Siamo una banda di disgraziati Gatesiani...

pero' ho in mano un progettino simpatico e la tentazione da amante di
linux e' forte. sto cercando informazioni per poter controbattere a vari
livelli.
il progetto prevede una banale procedura client/server, diciamo per
semplificare che e' come se vendessero, stampando due righe ed
aggiornando il magazzino centralizzato (poche informazioni comunque)
il prodotto da vendere puo' essere prenotato da internet (probabile
hosting) e ci deve essere continuo aggiornamento tra prenotazioni,
venduto e disponibilita'
inoltre ho delle informazioni da visualizzare su dei monitor. ogni
monitor e' dedicato ad una sola "informazione".
fatto con windows la tentazione prima e' un VB per la parte
client/server, qualcosa in ASP al limite appaltato al provider, sql
server, MSMQ eventuale per i msg.
per i monitor un pc dedicato a monitor (che sono tanti), brutto ma
efficace
essendo tutto ex-novo secondo me ci sono gli spazi per il pinguino, ma
mi preoccupa lo skill. come diavolo lo programmiamo? Java direi per
compatibilita, ma sai che palle rispetto a VB :(
Se non vi rompe troppo sono pronto ad analizzare qualunque idea e vi
ringrazio gia' adesso
Paolo

 efficace
Io userei python per la parte di gestione del magazzino, php per il sito
web, xml per l'interscambio dei dati, un server grosso con Linux e dei
terminali X per visualizzare sui vari monitor le info.
Puoi impostare l'autologin sulle connessioni X, e far partire
automaticamente l'applicazione che mostra le informazioni, in modo da
non dover digitare niente...
Bye.

 terminali X per visualizzare sui vari monitor le info.
in pratica sul server avresti un lavoro per ogni monitor? non mi e'
chiaro tieni presente che non c'e' interazione, i monitor sono puramente
visualizzazione aggiornata di tanto in tanto... tipo quelli che si
vedono nelle banche con la borsa.
Mi preoccupa anche l'usare due linguaggi (di cui per altro non abbiamo
skill) :( Pero' siamo Delphisti, Kylix non potrebbe coprire il tutto?
Non lo conosco, gestisce anche la parte web?
grazie e buona serata


Temo di no.
Se volete usare un linguaggio unico allora si ricade su java (anche se forse
python e ruby a quanto ho sentito potrebbero essere delle alternative).
Alessandro.

 In questo caso allora l'uso di terminali X e' un po' eccessivo.
beh, ma che diavolo puoi usare allora? (tenendo presente che i cavi di
segnale possono essere anche lunghetti

 segnale possono essere anche lunghetti
Appunto per questo suggerivo dei terminali X, perche` il tutto viaggia
via Ethernet (lunghezza max 100 metri tra hub e scheda, allungabile con
dei ripetitori).
In pratica ti basterebbero dei 486 con una scheda video decente e 16-32
Mb di RAM che non hanno altro che X installato che si collega
direttamente al server.
Sul server ci sara` xdm (o simile) con auto-login e, al posto del window
manager, in .xinitrc o in .xsession metti l'applicazione per mostrare i
dati sui monitor.
In pratica fai tutto sul server: avrai il db e l'applicazione. Ricorda
che l'applicazione, se e` la stessa ma lavora su dati diversi, occupa in
memoria solo la sua dimensione (anche se viene lanciata piu` volte), e
la memoria in piu` occupata e` solo quella dei dati.
In pratica, se l'applicazione occupa 1 Mb e usa 1 Mb di dati,
lanciandone 30 istante occuperari circa 30 (dati) + 1 (applicazione) =
31 Mb e non 60 come si penserebbe.
Sul server, un biprocessore 1200 o un monoprocessore 1800-2000 con 512
Mb di RAM credo possa gestire tranquillamente anche grossi database (che
sara` l'applicazione piu` critica), soprattutto se ha dischi veloci,
meglio un paio di SCSI in RAID 0 (striping), o meglio 4 in 0+1
(striping+mirroring) se sono (come penso) dati importanti.
Per quanto riguarda i linguaggi, non conosco Kylix, ma probabilmente, se
lo conoscete bene, e` la scelta migliore per voi per quanto riguarda il
db e l'applicazione in locale.
Per quanto riguarda la parte web invece vi consiglierei (tempo
permettendo) di usare php, che e` molto piu` supportato e adatto a
questo tipo di lavoro.
Bye.
 


Per un'interfaccia a caratteri avresti potuto usare dei terminali seriali
(ammesso che ne esistano ancora) ma se ci sono problemi di distanza e'
meglio evitarli (a meno di non usare ripetitori...)
Comunque X e' pesante e consuma molta banda, sebbene effettivamente  nel
tuo caso aggiornamenti siano abbastanza rari e quindi il secondo problema
e' limitato.
La mia idea sarebbe stata quella di un applicazione su ciascun terminale
non dipendente da X che riceve via rete gli aggiornamenti e li visualizza.
Questa applicazione implementata su teminale a caratteri o sulle svgalib
potrebbe addirittura girare su un 386 con un floppy e 4mb di ram.
Alessandro
e le sue smanie minimaliste...
P.S.: Come linguaggi di programmazione c'e' anche il vecchio C, un po'
svalutato ma sempre valido :-)

 potrebbe addirittura girare su un 386 con un floppy e 4mb di ram.
Si`, sarebbe una buona idea, ma visto anche che avbrebbero difficolta` anche a
usare python e php al posto di kylix, credo che la complicazione di
usare svgalib o framebuffer sia eccessiva.
Bye.

 direttamente al server.
quindi controlli ogni singolo monitor con un pc... ma non si riesce ad
evitarlo?
come potrei controllare tutti i monitor da un unico PC?
(I monitor visualizzano informaziona grafiche)


Il problema e' come generare il segnale dall'unico PC (ci vorrebbero n schede
video) e come distribuire il segnale a tutti i monitor sulla lunga distanza.
Ma le informazioni sono le stesse per tutti i monitor? Se fossero le
stesse si potbbe pensare di generare il segnale TV e distribuirlo su ciascun
monitor con qualch accrocchi elettronico.
Alessandro.

 Il problema e' come generare il segnale dall'unico PC
e si :( pero' l'uso di un pc a monitor mi sembra veramente uno spreco di
risorse!
purtroppo le info sono specifiche monitor x monitor
ciao e grazie

 (I monitor visualizzano informaziona grafiche)
Chiedilo su it.comp.hardware
Alessandro.


Ma mi pare che le complicazioni se le stiano cercando comunque...
Alessandro.

 Ma mi pare che le complicazioni se le stiano cercando comunque...
;)
La via semplice e' .NET
non so perche' preferirei di no!

 purtroppo le info sono specifiche monitor x monitor
Ma per ogni 'terminale' c'è anche un PC?
Se così fosse potresti mettere due schede video sul pc e sul
secondo monitor far girare un terminale X.
--
Valerio Granato
http://www.musicoff.com
 - Music Online For Free
La Grande Comunità Online per Musicisti

 aggiornando il magazzino centralizzato (poche informazioni comunque)
[..]
Io realizzerei tutto via WEB.
La società in cui lavoro ha realizzato (su commisssione) un mini-ERP
utilizzando Apache+PHP4+Postgresql+Perl (e un po' di C) che sta
funzionando alla perfezione da oltre 1 anno. Ti parlo di un commitente
che fattura 60 milioni (!) di Euro /anno e tutta (ma proprio tutta)
l'azienda è gestita da questo sistema.
Tra l'altro il sistema, oltre alla parte puramente gestionale
(magazzini, logistica, qualità, gestione personale, etc.), si
interfaccia anche con produzione (PLC, lettori barcode, rilevatori di
traguardo, etc.) per controllare l'avanzamento e generare tutte le
reportistiche del caso. 
Come distribuzione abbiamo usato una Debian (prima Potato, ora migrata a
Woody) su un cluster di 2 macchine Compaq Proliant (non ricordo il
modello), mentre tutti i client sono banali PC con un browser minimale
(niente Java, e Javascript ridotto all'essenziale). Usiamo anche un
30ina di terminali VT320 riciclati dal vecchio sistema (che girava su
OpenVMS), collegati ad un paio di terminal server, su cui si effettuano
transazioni molto semplici (front-end scritto in perl+curses).
Per la reportistica usiamo stampanti laser collegate a dei print server
di rete (ci sono circa 30 stampanti di produzione e altrettante code
definite sul server). Quasi tutta la reportistica è generata in HTML con
php e poi convertita con html2ps. La parte di stampa è stata la più
critica: per ogni linea di produzione il sistema stampa diverse
centinaia di tagliandi ogni ora con numerosi barcode e grafica di vario
tipo, oltre ovviamente a tutta la reportistica gestionale.
Il database attualmente ha una dimensione di circa 3GB, con tabelle che
superano tranquillamente i 4 mln di record, ed è in produzione 24h/24
7/7.
Tra l'altro il sistema offre delle funzionalità che vanno ben oltre le
specifiche iniziali del committente. Merito di sviluppatori un po'
troppo coinvolti che spesso, presi dalle enormi possibilità offerte
dagli strumenti usati, hanno voluto esagerare. Il tempo stimato per lo
sviluppo era di 1 anno, dopo 4 mesi, invece, il sistema era già pronto
nelle sue funzioni di base, infatti è stato messo in produzione con 2
mesi di anticipo (mai successo!).
P.S. confesso che la scelta di usare Postgresql l'ho reputata un po'
azzardata, anche perchè tutto lo skill aziendale era su Oracle. Mentre
il gruppo di analisi andava avanti, abbiamo stressato per 2 mesi un
database di laboratorio, e tutto è andato bene. In produzione, invece,
qualche problema lo abbiamo avuto, specie nella versione in Potato (6.5)
che, p. es., tendeva a corrompere gli indici allo shutdown (pulito!) del
postmaster, e abbiamo dovuto mettere su un job notturno per la
ricreazione degli stessi. Altro problema, alcune INSERT INTO ...  SELECT
...  mandavano in crash la sessione, ed una volta la tabella di
destinazione è addirittura sparita! (nel senso quando la si interrogava
risultava inesistente, ma se la si voleva ricreare risultava invece
esistente :(). Con la 7.2 le cose sembrano andare meglio, anche se ogni
tanto qualche scherzo lo fa (p. es. oggi in laboratorio non riuscivo a
fare il cast ad INTEGER di un OID _solo_ su un record!).
-- 
s/invalid.invalid/
libero.it/
spam -> 
da...@tin.it

 database di laboratorio, e tutto è andato bene.
Mi sembri ferrato su postgresql e ne approfitto. :)
Ho notato che una delle mancanze di questo db e` che non ha
funzionalita` nel caso si voglia cambiare un tipo di campo.
Ad esempio:
ho un campo "descrizione" nella tabella "articoli" con tipo char(20) e
voglio cambiarlo con char(30).
L'unico modo con cui sono riuscito a farlo e` un dump su file,
modificare il file come necessario (anche con script e quindi non
necessariamente a mano) e poi ricreare il db dal dump.
Per db di prova minimali si puo` anche fare, ma per db piu` grandi,
tipo quello da te citato, non puo` essere una soluzione valida.
Di sicuro non e` una soluzione elegante.
Tu hai consigli in merito?
Ho letto che la prossima versione la 7.3 dovrebbe avere qualcosa a
riguardo, ma chissa` quando uscira`.
Te la sentiresti di consigliare questo db nonostante i problemi che
hai riscontrato?
-- 
Massimo  ;-)  | EMail: 
q-con...@iol.it
 * ICQ: 37930285
--------------> 
http://digilander.iol.it/MaQ
  BABYLON5  --> 
http://digilander.iol.it/babylon5
  *TRIBOL*  --> 
http://digilander.iol.it/usstribolo

 hai riscontrato?
Se dovessi consigliare un db senza badare a spese, non esito a dire
Oracle, se la spesa diventa un problema sceglo Postgresql senza ombra di
dubbio ;-)
