Il problema del giorno: updates Windows 10 rompono la compatibilità con SAP B1

Se dopo un aggiornamento automatico di Windows 10 il client di SAP B1 (versione <9.2) vi riporta un errore come il seguente,

SAP B1 Error

non disperate! La radice della causa sta in una patch di Windows che ha deprecato una serie di certificati crittografici, considerati tecnologicamente obsoleti.

Sulla SCN di SAP consigliano (ad esempio qui e qui) di disinstallare gli aggiornamenti KB3163018KB3163017, ma potreste trovarvi nella caso in cui queste KB non risultano installate; questo poiché l’aggiornamento vi è stato somministrato tramite un’altra combinazione di patch cumulate, le quali risultano avere altri (vari!) identificativi di riferimento.

In tal caso, disinstallate in ordine anti-cronologico gli aggiornamenti di sicurezza di Windows; dalla mia esperienza, rimuovendo tutto quanto installato dopo Giugno 2016 il client torna a funzionare correttamente.

IPMI, questo sconosciuto; o anche, “Butta dalla finestra il tuo KVM”

Ho sempre amato le descrizioni “funzionali” dei devices.

Se dovessi descrivere un server, il primo requisito che mi verrebbe in mente sarebbe “è un computer completamente gestibile da remoto”; un requisito cardine, che dovrebbe entrare a far parte della stessa definizione di macchina server.

Come si gestisce da remoto una macchina fisica? Vedo già sbrilluccicare gli occhi del vostro vendor di switch KVM…

NO! I moduli KVM sono costosi, richiedono parecchia banda, non sono inclusi di serie (a parte rari casi) nelle vostre macchine server e comunque non fanno tutto quello che fa IPMI. È nato un grosso business attorno ad essi nel settore SMB a causa delle installazioni fisiche di Windows Server, ma… se nel 2016 pensate davvero di installare Windows Server non virtualizzato su un server per uso generalista (esistono casi edge dove la virtualizzazione è problematica), forse avete sbagliato blog.

Cos’è IPMI

Una descrizione generale di IPMI la trovate qui; la mia idea a riguardo, è che si tratti di una delle più misconosciute (sempre in ambito SMB) e utili funzionalità di gestione remota, molto più dei vari DRAC, iLO, IMM.

IPMI permette di controllare accensione/spegnimento della macchina, leggerne qualsiasi sensore, settare diverse impostazioni senza mai adoperare il BIOS (ad esempio, il device di boot), e ancora dialogare con il sistema operativo (o hypervisor di turno) tramite un’interfaccia dedicata out-of-band, seriale.

Come funzionalità OOB, IPMI non dipende dal software installato sulla macchina, né da eventuali agent.

Come si usa IPMI

Dovreste essere in grado di configurare completamente un server appena sballato senza mai collegarvi un monitor; sì, davvero.

Tutto quello di cui ha bisogno un server, oltre all’alimentazione, è una rete. Solitamente, le macchine provviste di IPMI hanno una porta ethernet dedicata al management; collegatela alla vostra rete, ed eseguendo

 ipmitool lan set 1 ipsrc dhcp 

IPMI verrà abilitato; basta rintracciare il lease per cominciare ad utilizzarlo.
Ad esempio, potremmo controllare se la nostra macchina è accesa con

 ipmitool -H ipmi_ip -U user -P password chassis power status 

e magari attivarla con

 ipmitool -H ipmi_ip -U user -P password chassis power on 

. Oppure, decidere di resettarla “elettricamente”:

 ipmitool -H ipmi_ip -U user -P password chassis power reset 

tutto senza mai toccare il tasto di accensione.
Controllare temperatura esterna e delle componenti, funzionamento delle ventole ed altri sensori hardware, è altrettanto semplice:

 ipmitool -H ipmi_ip -U user -P password sensor list 

e ora, una chicca: stufi di attendere il momento topico per premere F2, ESC &co per entrare nel bios dell’ultimo Proliant fiammante?

Ecco come impostare l’entrata automatica nel bios al successivo riavvio:

 ipmitool -H ipmi_ip -U user -P password chassis bootparam set bootflag force_bios 

Come avrete intuito, è possibile anche impostare qualsiasi dispositivo di boot tramite IPMI; il provisioning automatizzato tramite boot PXE impostato da IPMI è il metodo standard per la preparazione delle macchine utilizzate nelle server farm cloud.

SOL

Tutto molto bello, no? Ma eccoci arrivati alla funzionalità groundbreaking, “the real thing”; Serial-Over-Lan, o SOL per gli amici. In altri termini, redirezione della seriale via ethernet. Per la precisione, una porta seriale virtuale alla quale viene inviato l’output “video” del BIOS, dei vari controllers e del sistema operativo (se configurato opportunamente).

Adesso sapete come vengono fatti quei video in cui la fase di boot della macchina appare in un terminale: ve lo siete sempre chiesti, ammettetelo.

A titolo di esempio, ecco un video del boot di una mia macchina visto tramite SOL, una CentOS che fa da host per la virtualizzazione basato su KVM.

La SOL è uno strumento molto potente: possibile accedere al bios, quindi si può anche reinstallare da zero la macchina, e modificarne qualsiasi impostazione.

Non è tutto: come vedete alla fine del video, dopo il boot del sistema operativo si presenta anche il prompt di login… da questo, possiamo accedere alla macchina come faremmo in locale: costituisce a tutti gli effetti uno strumento di gestione out-of-band del sistema operativo, ovvero utilizzabile anche in caso la configurazione di rete del sistema sia per qualche motivo compromessa; ottimo per sperimentare con il networking, senza correre il rischio di essere tagliati fuori dalla gestione della macchina.

Tutti i principali OS/Hypervisor enterprise supportano pienamente la console seriale:

  • qualsiasi distribuzione di Linux può essere facilmente configurata per esporre una console seriale, basta seguire la documentazione della particolare distribuzione;
  • XenServer (il cui dom0 è Linux, naturalmente) include la voce “XenServer – Serial” nel menù di boot: rendetela default;
  • VMware ESXi può essere anch’esso facilmente configurato per la redirezione della console sulla porta seriale.

E AMT?

La Intel Active Management Technology è una tecnologia pensata per sistemi desktop e workstation, ma presente anche in diversi sistemi server. Alcune delle sue funzionalità si sovrappongono a quelle di IPMI e ne sono una evoluzione (sempre interessante vedere cosa riporta la wiki a riguardo), inoltre sono presenti grandi miglioramenti alla sicurezza, con un enforcing della cifratura TLS per le comunicazioni.
Avendo avuto modo di testare alcune sue caratteristiche, posso dire che la sintassi e le modalità di utilizzo delle funzionalità che mappano quelle classiche di IPMI via commandline (controllo status di alimentazione, ad esempio) sono abbastanza complesse rispetto alla controparte tradizionale.

Di contro, le funzioni per il provisioning automatico sono piuttosto avanzate, cosa che rende questa tecnologia parecchio idonea a deployment massivi nelle grandi enterprise.

AMT è pensato per essere utilizzato con software di management appositi, e il protocollo web-based sottostante è piuttosto complicato rispetto ad IPMI. Su piattaforma Linux vi consiglio amtterm, che fornisce una esperienza SOL-equivalente (notare che AMT include anche il KVM vero e proprio) con modalità molto user-friendly, mentre la tool wsmancli  consente di utilizzare appieno le funzionalità avanzate.

Alcuni produttori pensano di sostituire/affiancare AMT ad IPMI nel prossimo futuro; a mio avviso, come per l’interfaccia seriale (che adesso ha più di 40 anni!), lo zoccolo duro-legacy di IPMI rimarrà con noi ancora per diverso tempo…

Boota o non boota, qvesto è il problema

Se avete acquistato di recente una memoria SSD PCIe NVMe, nel leggere documentazione e forum vari vi sarete sicuramente imbattuti nell’interrogativo categorico riguardo questi dispositivi: boota o non boota?

Fuori dall’eden del plug-and-play

Non più nel comodo orticello SATA, molti utenti enthusiast si sono accorti di come i nuovi dispositivi mal supportino, sulla maggior parte delle schede madri, l’avvio diretto del sistema operativo, rendendoli di fatto molto meno appetibili agli appassionati (e non) che non possiedono schede madri dell’ultima generazione e un SSD compatibile.

Ebbene, questo è un problema che riguarda solamente gli utenti Windows. Vi siete mai chiesti perché Linux consigli di utilizzare una partizione segregata per /boot? Un retaggio dei vecchi UNIX, che torna sempre comodo…

Quasi tutte le architetture non-intel difatti, NON supportano (o non supportavano) il boot del sistema operativo dai dispositivi di storage “di lavoro”; il software necessario ai primi stages d’avvio viene invece caricato in speciali partizioni hardware (a mo’ di firmware) e copiato in RAM direttamente dal BIOS o suoi sostituti. Una implementazione di questa idea si può ad esempio trovare nell’Initial Program Load (IPL) delle macchine POWER IBM.

La multiforme bootabilità del pinguino

Torniamo alle nostre macchine x86 con NVMe: partiamo dal presupposto che non appena venga bootato il kernel Linux, il resto del sistema possa stare su qualunque, e dico QUALUNQUE cosa venga riconosciuta dal kernel, fosse anche una cassettina a nastro collegata via rete da una località remota… attualmente, credo proprio che tutte le schede NVMe presenti sul mercato siano supportate dal kernel 3.10 in poi.

Come caricare il kernel (ricordiamolo, sta nella partizione /boot) in memoria allora? Manca solamente un dispositivo che venga riconosciuto come boot device standard e che sia

  • economico: abbiamo già speso i soldi per la nostra NVMe;
  • affidabile: niente riutilizzo di vecchi dischi meccanici!
  • non troppo grande: la partizione di /boot può benissimo essere <1Gb.

Una penna, una penna, il mio regno per una penna!

La soluzione ci giunge da una pratica comune a parecchi setup raid software: bootare da una penna USB! Più precisamente, all’installazione del sistema basterà scegliere di installare MBR e partizione /boot sul succitato pendrive. Pensate che la penna USB sia un SPOF? E allora fate un’immagine della USB e la copiate su un’altro dispositivo, che potreste ad esempio tenere offline.

La stessa immagine potete tenerla da qualche altra parte per poterne sempre fare copie addizionali; dovrete solamente ricordare di aggiornare le copie dopo un aggiornamento del kernel (la cosa avviene abbastanza di rado) per evitare ogni problema di incompatibilità, ma in generale il vostro sistema dovrebbe avviarsi ugualmente anche con una /boot outdated se non cambiate i dispositivi di storage, o se vi riferite ad essi tramite UUID.

Questo disaccoppiamento dello storage potrà sembrarvi curioso, ma è una best practice consolidata nel mondo della virtualizzazione: questa modalità di avvio è comunissima e consigliata con tutti gli hypervisor embedded come ESXi o XenServer (molti server hanno appositi slot USB o SD interni), e comincia ad affermarsi anche per il deployment di container-OS immutabili.

Il trucco sta proprio nella natura principalmente read-only della partizione /boot: viene letta solamente all’avvio e scritta molto sporadicamente (solo per gli aggiornamenti), ed è noto come la vita delle memorie flash sia legata a doppio filo al numero di scritture sul dispositivo, più che alle letture.

Una scelta industry-standard

Come indicazione generale, comprate una chiavetta di buona qualità: trovate buoni devices delle principali marche per una decina di euro. Esistono anche dispositivi certificati per i vari hypervisor, che sono testati ed hanno una endurance pazzesca se utilizzati in sola lettura, ma difficilmente arriverete mai a percepire benefici sull’affidabilità.

Non siete ancora convinti? Continua a sembrarvi un setup molto strano? Beh è lo stesso (molto affidabile) setup di tutti i NAS consumer: il firmware (di solito una distro Linux) è scritto su una memoria a stato solido, generalmente una SD (ecco perché il firmware è aggiornabile!). Non pensavate mica che un NAS da 100€ avesse avanzati sistemi di mirroring delle ROM o chissà quale altra trovata magica, giusto?

È affidabile? Abbastanza. Se facciamo le copie della /boot altrove? Parecchio. Parecchio più dei NAS consumer ai quali affidate i vostri dati ogni giorno.

Perché usare distro enterprise?

Uno dei consigli più gettonati nei vari forum per principianti riguardati Linux è:

Non ti funziona $nuova_versione_ambiente_grafico?
Prova $distribuzione_misconosciuta!

La multipolarità della comunità OSS ha permesso la nascita e l’evoluzione di progetti importanti, e la loro gestione “poco business-oriented” ha consentito che si sviluppassero in direzioni spesso più interessanti e funzionali rispetto ad equivalenti commerciali. Dando uno sguardo alla situazione attuale dell’ecosistema Linux però, non si può ignorare come sia il kernel, sia l’ambiente GNU, siano essenzialmente mantenuti da una moltitudine di aziende; gli ultimi rapporti a riguardo parlano di come oltre l’80% degli sviluppatori siano pagati per il loro contributo dalle oltre 1200 aziende attivamente coinvolte: fra i top contributors spiccano Intel, Red Hat, Samsung, IBM, SUSE e Google.

È possibile trovare la concretizzazione di questi contributi professionali e di qualità in una terna (anche se ho delle riserve sul nuovo player) di distribuzioni che chiameremo distro enterprise, ovvero distribuzioni di Linux destinate ad ambienti di produzione per le quali viene offerto supporto commerciale e lo sviluppo/QA viene curato internamente; ci stiamo riferendo naturalmente a Red Hat Enterprise Linux (RHEL per gli amici), SUSE Enterprise Linux e Ubuntu Server.

In questo post volevo esplorare alcuni loro punti di forza che secondo me le rendono una scelta irrinunciabile quando si deve lavorare, in senso esteso, con il computer.
Perché le macchine nascono per fare lavoro al posto dell’uomo, right?

Supporto

La possibilità di poter chiamare qualcuno che risolve qualsiasi problema entro le SLA di contratto e che all’occorrenza rilascia anche patch customizzate è im-pa-ga-bi-le. Fesserie bloccanti che a volte tengono fermi progetti per settimane, di solito vengono risolte in poche ore.

Poiché chi fornisce la distribuzione da assistenza e mantiene/sviluppa tutti i pacchetti presenti nella distro, si riceve supporto anche su Apache, mySQL ecc; a differenza del mondo Windows dove viene garantito solamente il sistema operativo, e si gioca molto allo scaricabarile per qualsiasi software di terze parti. In genere, è possibile mettere su un sistema di produzione con discrete garanzie di fattibilità e tempistiche.

Supporto vuol dire anche manutenzione assicurata a lungo termine: la maggior parte delle distribuzioni succitate offre dieci anni di supporto che comprende patch di sicurezza (e non), chiamate di assistenza, nuovo software… insomma, una piattaforma stabile dove poter sviluppare il proprio workflow senza la paura che ci cambi sotto i piedi.

Compatibilità Hardware e Software

Software di modellazione 3D, schede video high-end, praticamente tutto l’hardware enterprise come HBA, controller RAID e interi servers/soluzioni/infrastrutture… devo aggiungere altro?
Sì: RHEL è una delle poche distro ad implementare correttamente e di default gli attributi estesi per il filesystem (ovvero, le ACL di Windows) e SUSE vanta una compatibilità spettacolare con Active Directory.

Possibilità certificazioni / Prospettive lavorative

Un conto è “so installare Linux, beh, sì“, un altro è poter affermare “sono certificato come system architect per quell’architettura e blablabla“; può fare la differenza.
È costoso, è una mezza mafia, ma può fare la differenza.
Sicuramente conoscere una distribuzione affermata nel panorama enterprise da un marcia in più a parità di curriculum: in generale CentOS è praticamente obbligatoria, ultimamente anche una conoscenza Debian-ish non guasta.

Stabilità

Inutile negarlo, i bugs bastardi esistono anche su Linux, e spesso le soluzioni non sono né triviali né facilmente attuabili at all.
Un ciclo di sviluppo più lento e orientato alla produzione, nonché QA sul codice documentato e funzionalità davvero funzionanti sono il miglior biglietto da visita.

Un esempio? Provate a configurare SELINUX o i pacchetti per l’HA su una distro rolling release.
E poi ditemi.
Ogni pacchetto è generalmente testato-integrato per funzionare bene con tutti gli altri, la distribuzione è un unicum più che essere un’accozzaglia di pacchetti in un calderone, con alcuni presenti solo perché “fa community”, “dobbiamo averli tutti”.
Di contro, il parco software è in genere limitato rispetto ad altre distro; il prezzo del rigore.

Interoperabilità fra versione commerciale e non

La user base delle versioni gratuite (e non solo FLOSS!) di Linux è immensamente più grande di quella delle versioni a pagamento/supportate.

Una dei grandi vantaggi di RHEL e Ubuntu però, è la possibilità di passare in modo assolutamente indolore dalla versione commerciale e supportata a quella community. Ubuntu vende solo il supporto, ergo il problema non esiste. In CentOS/RHEL basta cambiare i repo, le due hanno compatibilità binaria (cambiano loghi e RHN). SUSE/openSUSE pecca un po’ a riguardo, non esiste difatti un equivalente 1:1 di SUSE enterprise.

È possibile scaricare la versione binaria (oltre ai sorgenti, chiaramente) di SUSE e utilizzarla con i corrispondenti repo community, ma la procedura non è esattamente lineare né “caldeggiata”; tutto il contrario di Ubuntu e CentOS, che hanno guadagnato una gran fetta del loro market share proprio grazie all’ecosistema cantinaro e comunitario che si è creato attorno a loro.
SUSE, quando ci svegliamo?
La spinta all’integrazione con prodotti Microsoft ha curiosi riflessi sulle strategie aziendali…

Documentazione

Questo è probabilmente il punto più importante della rassegna, il maggiore selling point; la documentazione di queste distribuzioni, in generale è OTTIMA.
Non parlo di “link al forum, link al tutorial, come ha fatto l’utente XY, prova Z”: ogni funzionalità è completamente documentata e la documentazione è fornita insieme alla distro.

Non mi riferisco al sempreverde man, ma ad interi portali dedicati solamente a spiegare, fornire esempi, aiutare a costruire configurazioni funzionanti.
Aggiornati, corretti, utilizzabili in ogni momento come reference quando ci si trova in difficoltà. Devo dire che sono anche utili per scoprire funzionalità e pacchetti dei quali non si sospettava l’esistenza, semplicemente confrontando “come lo fa SUSE” vs “come lo fa RHEL”.

Un consiglio?

Per lavorare, fintantoché potete e non sorgono delle difficoltà insormontabili, usate CentOS. La maggior parte delle soluzioni enterprise sono sviluppate sopra di essa, dai firmware delle SAN; è bene farsi le ossa sugli ambienti realmente utilizzati in produzione. Se si resta sui repo standard, fatta salvo ovviamente una configurazione corretta, è incredibilmente stabile: la uso correntemente sia come hypervisor (KVM) che come host.

OpenSUSE/SUSE ha molto senso come ambiente desktop: ottima con KDE4, grande integrazione di default con eventuali sistemi Microsoft o altre terze parti. Inoltre, ultimamente sta prendendo molto piede come piattaforma di storage grazie al supporto per CEPH. La suite di High Availability e supercalcolo dicono funzioni molto bene, ma generalmente sono campi dove si customizza parecchio.

Ubuntu… sta guadagnando molta popolarità in installazione di OpenStack. Per il resto, la documentazione è poco affidabile/aggiornata/completa rispetto agli altri contenders, e la selezione del software spesso è fatta in modo scellerato, solamente per includere features consumer a scapito della stabilità; come si può includere un kernel NON lts in una release lts?! Di contro, è molto aggiornata e alcuni progetti proposti da Canonical sono interessanti (penso a LXD), ma la consiglierei solamente se è impossibile raggiungere il vostro scopo utilizzando le altre due alternative.

La grande O nel cielo

Francamente? Io un’idea a riguardo cel’avrei.

Con quello che è rimasto dell’azienda, assumete una trentina di programmatori/sistemisti/hardwaristi Linux; si trovano abbastanza facilmente, basta fare screening fra i certificati Red Hat. Fategli sviluppare un sistema centralizzato “All inclusive” per le PMI, dalla ricezione mail alla bolla da appiccicare sul pacco, che giri tutto su un server (o due, DRBD + clustering applicativo), basato su Linux/KVM; lo stack è già tutto esistente, dall’hypervisor alle applicaizioni client, basta integrarlo e farne un prodotto fico.

Sfruttate quel cazzo di nome, fate le porte dell’armadio con un grande O verde a triangolini, scrivetegli sotto POWERED BY LINUX e pubblicizzatelo con delle rassicuranti schermate che non dicano “Cloud, 2.0, IoT”, ma che facciano vedere un sistema con le finestre e i menù come dio comanda, ché la gente si è rotta delle ultime schizofrenie tablet-style Microsoft (infatti compra Apple) e nella “flessibilità degli applicativi pensati anche per il mobile” ed altra fuffa mediatica crede sempre meno.

Cosa mettiamo stasera nel minestrone.

Virtualizzato, potente, veloce (già quattro HDD e una buona cache sanno il fatto loro, per 20 dipendenti), che può crescere insieme all’azienda; ci vuol nulla, deployando tutto come VM. Dentro mettetegli un fileserver, un mailserver, un proxy squid che lavora in whitelisting per alcuni e in blacklisting per altri (ah, già vedo i sorrisi del CEO!), ammenicoli per la VPN/firewall, un sistema ERP come OpenBravo. Fateli testare ed integrare bene almeno un annetto… con tutto l’hardware che venderete al corredo, sopratutto il sottosistema di stampa e i POS; lì, avete tonnellate di know-how.

Validate le ultime incarnazioni di LibreOffice, magari anche con plugin proprietari per la conversione da ooXML (esistono eccome, e funzionano bene!), al resto pensa il motore LaTeX che gestisce l’output dall’ERP; niente rocket science, si tratta di scrivere un paio di parser da applicare a dei modelli, eventualmente personalizzabili. Assomiglia molto al lavoro di integration che spesso viene demandato ai sysadmin o ai dbadmin.

E il coccodrillo?

Riguardo i clients, fornite della roba ARM o MIPS che utilizza X over ethernet verso delle VM sul server; X11 funziona egregiamente in LAN, non molto in WAN. Qualora si dovesse scalare, SPICE ha fatto passi da gigante ed è abbastanza utilizzabile. Macchinette da 20 euro al pezzo, da rivendere a 150 con la grande O verde, stando ancora molto sotto quanto viene chiesto oggi per un thin client.

Per i servers: i dual socket commodity x86 con le features RAS vanno già benissimo per poter sostenere la “responsabilità operativa” di un’intera azienda di queste dimensioni, senza far casini con storage di rete e quant’altro, che su questa fascia di prezzo minerebbero l’affidabilità dell’insieme (lo spiegavo qualche post fa). Nel settore c’è fermento nonostante la commoditization, sono parecchi i vendors che sgomitano: Huawei, dice nulla?. Volendo, se la cosa dovesse scalare diversamente, si potrebbe portare tutto già oggi su ARM o POWER senza salti mortali.

Tutto E/O niente

Bisogna fornire il rack completo, già precablato e labelizzato (mezzo rack dovrebbe bastare per la maggior parte delle PMI), includendo il poco networking, un NAS per i backup in situ (più un altro in remoto, o comunque altrove, che replica gli snapshots delle VM); un paio di UPS correttamente dimensionati, magari anche filtrati; la soluzione è pensata per aziende che non hanno un comparto IT, non vogliamo che il primo ingegnere elettronico di turno ci metta le mani, no?

Qualcosa che altri hanno già pensato di fare, ad esempio Dell con vStart e la stessa VMware con VCE, solamente a prezzi di un ordine di grandezza superiore. La differenza con questi giganti è la facilità di gestione per la PMI, che sarà molto scoraggiata dal mettere le mani su QEMU e combinar casini, piuttosto che farlo su HyperV o l’interfaccia web di vSphere; già, il minimalismo come baluardo, e contraltare degli infiniti databases, API e framework immensi che oggi si devono usare anche per gestire installazioni su piccola scala.

Otteniamo così un sistema centralizzatISSIMO, sul quale si può fornire assistenza top-down, che consuma poco ed usa le risorse (storage locale, sistema scale UP) in modo intelligente (containers, VMs che condividono la stessa golden image, networking quasi tutto interno al singolo nodo), e può soddisfare il 99% delle esigenze delle PMI che partono da zero, o quasi. Nessun casino con malware &co. (SELINUX è tuo amico), nessun aggiornamento idiota che blocca l’operatività.

Qualora una VM client dovesse avere un problema, con le funzionalità standard di qualsiasi distro enterprise odierna è già possibile ricreare la macchina da un template (scriptato con Puppet ovviamente) in pochi SECONDI, da remoto con Mosh o SSH + DynDNS. Così, si può fornire assistenza remota senza mandare i sistemisti in situ anche sulla più misera delle ADSL (ho fatto esperienza pure sul 3G). Alla bisogna, si fornisce anche la possibilità di collegarsi a delle VM Windows, e ci si può anche sobbarcare la conversione dei vecchi documenti da formato “Office” a ODF.

Ok, ma…

Fornire tutto ciò in comodato d’uso, un TOT al mese, gestendo l’hardware usato (che così si può riutilizzare fino a “fine vita”) non è una banalità, ma mi sembra raggiungibile con le cifre lette nell’articolo, in due-tre anni. Sempre meglio che morire di fame rimarchiando tablet.

È antiquato, sembra un ritorno ai vecchi AS400? Sì, esatto. CHE DIFATTI, FUNZIONAVANO. Vedo ovunque un grande bisogno di ritorno a soluzioni più “commensurabili”, comprensibili, architetturalmente meno articolate, e che nascondano meno la loro complessità; in una parola: semplici anche se non necessariamente facili… dove facile che è un concetto relativo: vi sembra “facile” utilizzare Metro per task avanzati o metter su un cluster di active directory perché il database potrebbe corrompersi random in qualsiasi momento? Ma, sopratutto dover dialogare con sistemi che dipendono in modo assolutamente vincolante dal buon funzionamento di DNS&co. (cosa abbastanza fragile), la cui gestione viene spesso affidata al primo santone di tutto che “sa installare Windows”, e questo anche per installazioni da una decina di postazioni?

Non credo che ci sia mai stato un momento più propizio per l’ingresso di una soluzione di questo tipo (Linux desktop e server, tutto virtualizzato a la “mainframe x86”), dati i pesanti colpi accusati da Microsoft ed un drammatico calo dei costi di storage e server di bassa gamma, insieme alla sostanziale scomparsa delle soluzioni prima denominate midrange da questa fascia di mercato (ex system P, system i, AS400 ecc.); manca solamente un’azienda agile, che abbia voglia di fare il primo passo.

Ah, mi dicono che il logo sia diventato rosso, adesso.