Olivetti Olibook

[nucarote]

....

Ora ben vengano queste iniziative per cercare di rialzarsi, però mi auguro che non siano le solite mosse fatte per ingrassare gli azionisti con i soldi della pubblica amministrazione (visto che verosimilmente rappresenterà la stragrande maggioranza delle vendite, come è già successo in passato) ma che dietro ci sia un serio piano di rilancio che possa far fruttare queste entrate....

Non credo che vendendo HW rimarchiato, voglia dire un operazione di rilancio per Olivetti, ma più che altro un modo per far guadagnare qualche spicciolo extra a Telecom con la vendita del suddetto HW tramite bolletta.

Modificato 18 Marzo 2010 da nucarote

[alettone75]

Non credo che vendendo HW rimarchiato, voglia dire un operazione di rilancio per Olivetti, ma più che altro un modo per far guadagnare qualche spicciolo extra a Telecom con la vendita del suddetto HW tramite bolletta.

anche io ho le stesse perplessità purtroppo... di per se partire rimarchiando, visto che necessita tempo e grossi investimenti entrare in un settore in cui non si è presenti, potrebbe anche essere considerato un peccato veniale... ma conoscendo cos'è Olivetti oggi...

[nucarote]

Olivetti è dell'informatica quello che è Lancia per le auto, ossia un marchietto da appiccicare su della roba onesta un tanto al kg per venderla con un certo sovraprezzo in Italia, nulla di più nulla di meno, per cui scordatevi ogni ipotesi di risorgimento del marchio di Ivrea a quello che era nel periodo degli M24 (che come già sottolineato era già piuttosto cadente, rispetto a quello che Olivetti era stata negli anni 60/70).

[Net Flier]

Attento che la lobby dei programmatori Cobol presediuta dagli accenturiani (praticamente una bel pezzo della facoltà di informatica di Salerno) vi manometteranno i vostri cagafumi.

"dovete portare quest'affare da cobol a c#"

"ma cosa fa esattamente questa routine? non si capisce niente di questo codice.."

"uhm..non lo so..eppure quando l'avevo fatta QUINDICI ANNI FA, qualcosa faceva..beh tu ricopiala, poi vediamo"

due mesi dopo

"allora questa routine?"

"sono fermo alle prime venti routine richiamate nelle prime due variabili ricorsive..."

"va bene, fai quello che riesci..mi è venuto in mente che forse non è mai stata usata..bravo continua così"

[nucarote]

"dovete portare quest'affare da cobol a c#"

"ma cosa fa esattamente questa routine? non si capisce niente di questo codice.."

"uhm..non lo so..eppure quando l'avevo fatta QUINDICI ANNI FA, qualcosa faceva..beh tu ricopiala, poi vediamo"

due mesi dopo

"allora questa routine?"

"sono fermo alle prime venti routine richiamate nelle prime due variabili ricorsive..."

"va bene, fai quello che riesci..mi è venuto in mente che forse non è mai stata usata..bravo continua così"

Sembra proprio uno spot dell'Accenture. :lol:

[Artemis]

difatti la migrazione consisteva nella parte dei conti..poi hard real time con assembler e parti grafiche:lol:

lolllissimo

Lollissimo stocavolo.

1) assembler è effettivamente il best in action per l'hard realtime. E' che non conviene svilupparci se non su piattaforme particolarissime.

2) lo dico perchè ci ho lavorato. in feature request la maggiorparte delle infrastrutture bancarie richiedono l'hard realtime. Aggiungo: spesso sono sistemi a lotti.

[Net Flier]

Lollissimo stocavolo.

1) assembler è effettivamente il best in action per l'hard realtime. E' che non conviene svilupparci se non su piattaforme particolarissime.

2) lo dico perchè ci ho lavorato. in feature request la maggiorparte delle infrastrutture bancarie richiedono l'hard realtime. Aggiungo: spesso sono sistemi a lotti.

leggi bene..assembler e parti grafiche..no assembler da riga di comando..

quelli erano ina ssembler da riga di comando pura, mentre si doveva migrare con assembler eseguito in finestra del programma che emulava il sistema operativo all'interno di win (praticamente avvi il programma ed al suo interno si emulava il sistema su cui poi girava il vero programma)

poi l'hard realtime non so dove stia in banca (non è sarcastico, meglio precisare), se non sulle operazioni allo sportello..anche perché di notte si salva/aggiorna/integra tutto..

[Artemis]

leggi bene..assembler e parti grafiche..no assembler da riga di comando..

quelli erano ina ssembler da riga di comando pura, mentre si doveva migrare con assembler eseguito in finestra del programma che emulava il sistema operativo all'interno di win (praticamente avvi il programma ed al suo interno si emulava il sistema su cui poi girava il vero programma)

Non capisco che intendi.

L'assembler è un linguaggio di traduzione binaria diretta della cpu.

A meno che si tratti di processori che disegnano finestre con direttive di registro non ho seriamente capito cosa intendi per "parti grafiche".

poi l'hard realtime non so dove stia in banca (non è sarcastico, meglio precisare), se non sulle operazioni allo sportello..anche perché di notte si salva/aggiorna/integra tutto..

Per hard realtime si intende semplicemente che una volta lanciata un operazione di cpu questa deve assolutamente terminare entro un tempo preciso stabilito a priori.

E' un requisito piuttosto ovvio se pensiamo alle transazioni: un timeout, un interrupt che blocca la preemptio dell'operazione, e questa potrebbe slittare, andare in timeout per indisponibilità della risorsa di destinazione e quindi si perderebbero dei soldi nel nulla.

Poi ovviamente tutto si integra e si aggiorna di notte perchè la ridondanza di tutto è essenziale

[Autodelta85]

Scusate eh...che centrano gli OS real-time con l'Olivetti/Gigabyte ?

[spiderland]

siamo nella sezione OFF TOPIC....