domenica 9 luglio 2017

FreeBSD upgrade

Premetto che non sono mai stato un grande fan di BSD in nessuna delle sue incarnazioni anche se negli anni ogni tanto ci ho provato ad usarlo in maniera costante come desktop .... ma poi alla fine resto sempre su linux.
Fatta questa premessa mi ritrovo ad avviare una VM con FreeBSD 10.3 che non utilizzavo più chissà da quanto tempo e procedo prima con gli aggiornamenti dei pacchetti con la sequenza di comandi :
pkg update
pkg upgrade
e scarica una montagna di aggiornamenti, preciso che ho anche installato MATE come DE oltre a firefox e altri programmi.
Terminati gli aggiornamenti decido di aggiornare anche il sistema :
freebsd-update fetch
freebsd-update install
anche qui va tutto bene.
Ora non sono un esperto del mondo BSD ma credo che FreeBSD sia l'unico BSD che ha un sistema di aggiornamento e di passaggio ad una versione successiva, non so da quanto ci sia ma sicuramente è un qualcosa in più per renderlo maggiormente accessibile ad un'utenza un pò meno tecnica, o almeno questa è la mia opinione.
Fatti tutti gli aggiornamenti mi sono detto che visto che c'ero potevo anche provare l'upgrade a FreeBSD 11.
freebsd-update -r 11.0-RELEASE fetch
freebsd-update install
quest'ultimo passo lo ho dovuto ripetere più volte, non per via di errori ma perchè così mi istruiva a fare la procedura di installazione.
Aggiornato il sistema operativo alla nuova versione sono passato all'aggiornamento dei package e qui ho avuto un piccolo intoppo, in pratica il comando pkg non veniva eseguito per via della mancanza della libreria libssl.so.7.
Per fortuna sul sistema è presente anche il comando pkg-static che come si intuisce dal nome è la versione compilata con librerie statiche e che quindi non necessità di dipendenze. 
pkg-static update
pkg-static upgrade
anche in questo caso la mole di aggiornamenti scaricati è stata notevole e al termine anche il comando pkg risultava funzionante. 
In conclusione devo dire che le varie procedure di aggiornamento sia a livello di pacchetti che di sistema funzionano molto bene e rendono la gestione/manutenzione di FreeBSD semplice quasi quanto avviene con i gestori di pacchetto presenti nelle varie distribuzioni linux.
Il che è un'ottima cosa.

giovedì 1 giugno 2017

KDE su OpenServer 5.0.7

Continuano i miei esperimenti su questo vecchio sistema operativo Unix.
Ho deciso di provare a installare KDE, che viene fornito pacchettizzato solo in versione 1.1.2, roba antica ma sicuramente meglio dell'ambiente grafico standard di SCO.
Purtroppo anche in questo caso le cose non vanno lisce come dovrebbero, ma procediamo con calma.
Sul sito di SCO, a questo link, è possibile scaricare un buon numero di pacchetti per SCO OpenServer 5.0.7, purtroppo sono quasi tutte vecchi versioni, ma è sempre meglio di nulla.
Per prima cosa bisogna scaricare e installare i seguenti pacchetti :
  1. Glib-1.3-VOLS.tar
  2. Qt-1.44-VOLS.tar
  3. kde-1.22-VOLS.tar
per comodità li salviamo in /tmp e uno ad uno provvediamo a scompattare i file con il classico tar xvf e li installiamo con il comando custom oppure usando scoadmin, più comodo.

Al termine si potrebbe pensare che sia già possibile usare KDE, magari attraverso una scelta in più in fase di login grafico .... ovviamente non è così, e magari fosse solo questo.

Uno dei problemi è che i binari di KDE caricano una serie di librerie da posizione fissa che, ma guarda un pò, non corrisponde per nulla a quella dove sono effettivamente installate le librerie. In pratica sotto /usr/lib ci sono i seguenti files :
  1. libjpeg.so.62
  2. libtiff.so.3
  3. libz.so.1
  4. libpng.so.2
ma vengono cercati in /usr/local/lib, quindi bisogna creare una serie di link con il seguente comando :
ln -s /usr/lib/libjpeg.so.62 /usr/local/lib/libjpeg.so.62
questo per tutti e quattro i files.
Ma come lo avviamo KDE ? Normalmente si avvia attraverso KDM, ma questo non è presente, bisogna quindi operare diversamente.
Prima però aggiungiamo nel .profile nella nostra home directory queste righe.
PATH=$PATH:/usr/local/bin:/usr/local/kde/bin:.
KDEDIR=/usr/local/kde
export KDEDIR PATH
poi la documentazione ci dice di modificare il file .xinitrc, sempre nella nostra home, aggiungendo la riga startkde, se siete pratici di linux/unix penserete che non fa una grinza .... e, guarda un pò, tanto per cambiare, invece non funziona. 
Infatti scologin, il login grafico di SCO, usa il file .startxrc come file di configurazione a livello utente.
Adesso finalmente facciamo il login ed entriamo in KDE, in tutta la sua gloria ...
o quasi, sfortunatamente alcune applicazioni presenti a menù poi non risultano installate, la sfiga vuole poi che Konsole, l'emulatore di terminale di KDE, si avvia ma non accetta nessun input da tastiera risultando quindi inutilizzabile, l'altra applicazione Kvt invece non è proprio presente.
Con ALT+F2 è possibile digitare il programma da avviare e indicando l'intramontabile xterm è possibile avere un terminale usabile.
In conclusione la pacchettizzazione di KDE per SCO 5.0.7 è proprio fatta molto alla buona, per essere gentili, tanto da farmi dubitare del fatto che possa pensare di usarlo.
KDE 1.1.2, non ricordo più nemmeno sua quale distribuzione linux lo abbia visto, forse Red Hat 6 ?


martedì 18 aprile 2017

Windows 95 e SCO OpenServer 5.0.7 su stesso PC

Per prima cosa devo dire che l'unico modo per usare decentemente SCO OpenServer è quello di installarlo in una macchina virtuale ( VirtualBox o VMWare ).
Io ho avuto la bella idea di installarlo su di un vecchio portatile che non ha nemmeno la scheda di rete, e questo sistema operativo del c.... non supporta nessuna scheda PCMCIA, anche se dovrebbe, ma non riconosce il bus PCMCIA del portatile ( conflitto di indirizzi o qualcosa del genere ), quindi è isolato dal resto del mondo. L'unico modo per copiare file da e per l'esterno è attraverso il floppy disk .... peccato che è l'unico PC con il lettore di floppy che mi è rimasto ormai. 
Quindi ho avuto un'altra delle mie brillanti idee, e ho pensato di formattare tutto e installare Windows 95, sì il PC è vecchio e amo il vintage informatico.
Una partizione di circa 6 giga per Windows 95 bastano e avanzano, ma Windows 95 è in una partizione FAT32 e non c'è da sperare che SCO vi possa accedere, infatti questo Unix supporta solo la FAT16, quindi ho creato una partizione da 1 giga in tale formato e nello spazio restante ho installato SCO, il tutto facendo attenzione che la partizione Unix fosse nel fatidico limite degli 8 giga, perchè c'è poco da farsi illusioni che il boot loader di SCO possa avviarsi oltre tale limite.
Una volta installato SCO al riavvio trovo il boot loader di quest'ultimo e per avviare Windows 95 dovrei usare il comando :
bootos N° partizione di Windows 95
quindi :
bootos 1
che, guarda un pò, ovviamente da errore e si avvia SCO. L'arcano è presto scoperto, avviato SCO eseguo il comando fdisk e visualizzo le partizioni, e scopro che SCO le vede in un ordine tutto suo :
  • partizione 1 SCO Unix
  • partizione 3 FAT16
  • partizione 4 Windows 95
mentre da Windows 95 il comando fdisk visualizza :
  • partizione 1 Windows 95
  • partizione 2 estesa
  • partizione 3 sconosciuta ( SCO Unix )
quindi il comando per avviare Windows 95 dal prompt di boot è :
bootos 4
in realtà dalla documentazione si evince che ci sono dei nomi di default che sono gestiti in automatico per l'avvio di altri sistemi operativi, senza quindi dover sapere in quale partizione sono installati.
Per semplicità io ho aggiunto al file /etc/default/boot la seguente voce :
win95=bootos 4
in questo modo al prompt basta digitare :
win95
ma probabilmente andrò a installare un boot manager alternativo, più flessibile e amichevole.

Come ho detto all'inizio ho creato una partizione FAT16 da usare per lo scambio di file, anche se ovviamente non è una soluzione ottimale in quanto necessità di riavviare il PC per usare uno o l'altro dei sistemi operativi, ma visto che Windows 95 può usare la scheda di rete PCMCIA userò questo OS per scaricare i files nella partizione di scambio, poi riavvio e faccio il boot in SCO e copio i files, stessa cosa se devo portare fuori dei files.
Per montare la partizione FAT16 il comando da eseguire è questo :
mount -f DOS /dev/dsk/0sD /mnt
da dove arriva /dev/dsk/0sD ? Da qui ..... ma non fidatevi, perchè questo link indica /dev/dsk/0sC come disco C ma sul mio PC da errore, non solo perchè essendo FAT32 non sia possibile montarlo ma proprio perchè non risulta come device.
Onestamente non mi è chiara la logica con cui sono  identificate le partizioni ma riassumendo sul mio sistema :
  • /dev/dsk/0s4 partizione FAT32 con Windows 95
  • /dev/dsk/0sD partizione FAT16 di scambio
Senza montare la partizione si possono usare i comandi doscmd dopo aver configurato in maniera corretta il file /etc/default/msdos impostando la device per la partizione D:
D=/dev/dsk/0sD
 ora si può copiare un file con :
doscp /unix/path/to/file.txt D:
oppure :
doscp D:archivio.dat /tmp
c'è da considerare che i files copiati da UNIX a DOS verranno troncati se non in formato 8+3.
Sul sito SCO, e comunque sul CD Skunkware, c'è anche il pacchetto MTOOLS che dovrebbe fare le stesse cose di doscmd ma con il supporto per FAT32, purtroppo dalle mie prove supporta solo i nomi di file lunghi, tipici di FAT32, ma non mi permette di accedere al disco C: di Windows 95.
Dopo questa disamina ribadisco che la soluzione migliore per usare SCO OpenServer è una macchina virtuale, dove il supporto per la scheda di rete è gestito, almeno con una banale AMD PCNet.



 

mercoledì 8 marzo 2017

GCC su SCO OpenServer 5.0.7

E' passato un pò di tempo dall'ultima volta che ho scritto qualche programma in C su questo sistema operativo, abbastanza da non ricordarmi che non compilavo di certo con il GCC.
Infatti al primo tentativo di compilazione di un semplice programma ottengo un errore di undefined symbol per la funzione _fini in /usr/ccs/lib/ctr1.o, e la cosa mi ha mandato in panico perchè ero certo di avere già compilato programmi scritti in C in precedenza.
Per riepilogare il sistema operativo è aggiornato con il maintenance pack 5, l'ultimo disponibile, e il compilatore GCC arriva dal CD Skunkware del 2000, una vecchia versione 2.95.2. Ma sul sistema ho anche installato il compilatore C nativo di SCO ed è quello con cui ho compilato i vecchi programmi, lo si vede dal fatto che gli eseguibili sono in formato COFF mentre il GCC gli genera in formato ELF.
Quindi problema risolto ? No, perchè ora volevo compilare i sorgenti della vecchia e mitica libreria Turbo Vision, quella usata dagli IDE Borland in ambiente DOS. Questi sorgenti sono compilabili anche su linux e bsd quindi probabilmente anche sotto SCO con il GCC dovrei avere più probabilità di successo che non con il compilatore nativo.
Fortunatamente sul sito FTP di SCO si trova una cartella con i files del pacchetto GNU Tools 5.0.7 che dovrebbero fare al caso mio.
Sono una serie di files in formato VOL, il formato dei pacchetti specifico per SCO OpenServer, ma tentando di installare il pacchetto il sistema si lamenta che devo avere precedentemente installato il maintenance pack 1, che non ho visto che ho il 5 che ingloba tutti i precedenti.
Anche in questo caso c'è una soluzione piuttosto semplice, basta creare un certo file prima di installare attraverso scoadmin software :
touch /tmp/gnutools.nocheck
in questo modo non viene eseguito il controllo di eventuali dipendenze software e il pacchetto si installa, ovviamente il nome gnutools vale per questo specifico pacchetto non in senso generale.
Adesso ho il compilatore GNU C in versione 2.95.3, quindi non molto più recente dell'altro, ma almeno compila senza errori.
Questo pacchetto, poi si installa in /usr/gnu/bin a differenza di quello installato dal CD Skunkware che si trova in /usr/local/bin e che comunque non serve a nulla e andrò a rimuovere.
Adesso che ho il compilatore GNU C ( e C++ ) funzionanti su SCO, anche se in una versione molto vecchia, vediamo di compilare questa libreria Turbo Vision. Ma ve la ricordate ? Non è meravigliosa ? Che nostalgia, che tempi !!!



venerdì 3 marzo 2017

SheevaPlug e chiavette USB

Il mio SheevaPlug ha ormai parecchi anni sul groppone e resta accesso 24 ore al giorno tutti i giorni e negli anni ha avuto più di un problema.
Una volta è saltato l'alimentatore e lo ho dovuto sostituire, poi la memoria flash interna ha cominciato a dare problemi per cui non era più possibile usarla come sistema di avvio e quindi ho installato e configurato Debian da chiavetta USB.
All'inizio era una chiavetta Kingston da 32GB, una di quelle "nano", ma dopo un annetto tutto d'un tratto non riesco più a collegarmi allo Sheeva e scopro che il problema è la chiavetta, completamente andata, non è stato più possibile nemmeno formattarla ... da buttare.
Ho sostituito la chiavetta con una identica ma da 16GB, reinstallato tutto e oggi mi ritrovo nelle stesse identiche condizioni, forse non è nemmeno passato un anno e all'improvviso non funziona più il collegamento .... il motivo sempre lo stesso la chiavetta è inutilizzabile.
E' vero che il server(ino) è sempre acceso ma è anche vero che lo uso solo per ftp/torrent e poco altro .... insomma non è che lo stresso poi molto per cui che si siano sputt.... due chiavette USB in pochi anni mi secca un pò, ora non voglio rischiare nuovamente con un altra chiavetta, ma usare un disco IDE da collegare via USB non mi sembra una grande soluzione, anche se fattibile.
Il dubbio è che l'alimentatore non regga bene, un disco meccanico IDE poco o tanto consuma e sempre di più che una chiavetta USB.
Ecco cosa ho fatto, ho un adattatore da Compact Flash a IDE e ho installato una schedina CF da 16GB sulla quale ho ripristinato una copia di backup di Debian dell'ultima chiavetta USB, giusto per non reinstallare tutto da zero.
Ho messo il tutto un un case USB per dischi da 2,5 pollici e lo ho attaccato allo SheevaPlug, quindi adesso il server si avvia sempre da USB ma sfruttando una CF che spero duri di più delle chiavette USB.
In questo modo ho recuperato dei "pezzi" di hardware che avevo senza fare ulteriori spese .... anche perchè non sono molto ottimista riguardo alla durata e affidabilità di questa soluzione.
Forse si sta avvicinando il momento di dismettere lo SheevaPlug e passare ad un RaspBerry.

martedì 28 febbraio 2017

Manjaro, aggiornamenti kernel e driver ATI catalyst

Ovvero uno dei peggiori connubi del mondo linux.
Onestamente ogni volta mi chiedo perchè non abbandono definitivamente i driver proprietari ATI a favore di quelli opensource, infatti una volta su due dopo un aggiornamento del kernel al primo riavvio si blocca sempre tutto e bisogna avviare in single user per ripristinare il tutto.
Solo che stavolta la situazione è persino peggiorata, infatti una volta avviato in single user ho provato a rimuovere i driver con il solito comando :
mhwd -r pci video-catalyst
che gentilmente mi ha mandato a fare in c... dicendomi che non andava a buon termine per il mancato soddisfacimento di alcune dipendenze.
Allora ho deciso di operare in maniera brutale forzando la rimozione di alcuni pacchetti ignorando il controllo delle dipendenze.
pacman -R -dd catalyst-video
pacman -R -dd catalyst-server
mhwd -r pci video-catalyst
poi ho riavviato ma il server Xorg non si è avviato e sono rimasto solo con la console a carattere, poco male, eseguo il login e installo nuovamente.
mhwd -i pci video-catalyst
a questo punto lo schermo è diventato nero, e forse si è anche bloccato tutto, il passaggio da una console all'altra con CONTROL+F1 ecc non ha dato nessun esito, quindi ho spento di brutto.
Fortunatamente al riavvio è andato tutto bene, ma che agonia tutte le volte .... devo eliminare questi driver proprietari e tenermi quelli opensource .... una volta per tutte.

giovedì 23 febbraio 2017

Antivirus per linux

Sono passati quasi 4 anni dall'ultima volta che ho provato dei programmi antivirus per linux, è ho deciso di darci nuovamente un'occhiata.
Resta sempre il presupposto di allora, per quanto mi riguarda, e cioè che in linux non c'è grande bisogno di un antivirus anche perchè fino ad oggi mi pare che di virus per linux ce ne siano ben pochi.
C'è da dire che negli ultimi anni i virus hanno cambiato "aspetto" e si sono diffusi molto i ransomware come il tristemente famoso CryptoLocker che vanno a criptare i file del proprio PC rendendoli inutilizzabili. In teoria credo che ciò potrebbe essere fatto anche su linux, con un virus adhoc, in quanto anche se si limita a criptare i documenti dell'utente, quindi senza rendere inutilizzabile il PC, ma una volta persi documenti importanti, di cui dovrebbe esserci sempre una copia, il danno basta e avanza.
Ma al di la di queste mie ipotesi, se il ns. PC linux è in una rete con altri computer Windows e magari fa pure da server SAMBA per la condivisione dei dati, oppure fa da downloader per file torrent, ecco che un antivirus che funzioni direttamente sul lato linux può essere anche utile.

Ho effettuato le prove con un paio di distribuzioni linux, Debian sia Jessie che Stretch, Centos 7 e Fedora 25, quest'ultima l'unica a 32 bit.
Per testare gli antivirus ho scaricato alcuni file di test da qui e alcuni keygen che ho, non che usi software piratato per l'amor del cielo ......


Il primo testato è il più famoso, e forse l'unico, antivirus opensource e disponibile con qualsiasi distribuzione linux. Testato su Fedora 25 si è comportato bene rilevando i file infetti senza però segnalare nulla in merito ai keygen. Questo programma è solo a linea di comando quindi va bene per essere usato all'interno di script, quindi anche in crontab. Su Fedora esiste anche un pacchetto clamtk per avere un'interfaccia grafica, ma è talmente spartana e poco funzionale che è meglio lasciarla perdere. Dico solo una cosa in fase di selezione della cartella da scansionare il programma non da la possibilità di eseguire una scansione ricorsiva delle eventuali sottodirectory e non lo fa nemmeno di default, quindi, a non saperlo, uno magari pensa anche di aver scansionato tutta la cartella e invece il programma si è limitato solo ai file in essa contenuti. Esiste anche un'interfaccia per KDE, che non ho testato, mi auguro sia più funzionale.
Questo antivirus non prevede la scansione realtime, che come vedremo in linux è praticamente inesistente.


Questo antivirus lo avevo testato anche la volta precedente, è ancora in circolazione ed è disponibile in formato DEB e RPM sia a 32 che a 64 bit. E' gratuito e ha una bella, questione di gusti, interfaccia grafica ma anche i tools da linea di comando, quindi utile sia per l'automazione di lavori via script che per l'utente desktop. Il programma una volta installato segnala subito di procedere con l'aggiornamento del database delle firme, e segnala anche di fare una scansione completa del sistema.
Sarebbe, a mio avviso, da 10 e lode se non fosse per un fastidioso problema, e cioè questo programma prevede la scansione realtime attraverso il modulo del kernel redirfs. Peccato che i sorgenti da compilare forniti con il pacchetto siano vecchi e funzioni solo con i kernel 2.6, da qui è possibile scaricare delle versioni aggiornate che mi hanno permesso di compilare il modulo su Jessie, che usa un kernel 3.16 .... ma con il kernel 4.9 di Fedora non vanno già più bene.
Ora la scansione realtime è quella che ti segnala che un file è infetto nel momento in cui lo scarichi sul PC o accedi ad una chiavetta USB dove è presente un file infetto .... quindi senza dover fare una scansione manuale.
Ma se anche non funziona non è proprio una tragedia, ma allora visto che il driver non è più mantenuto/aggiornato non è meglio togliere questa opzione ... o almeno disabilitarla in modo da non vedere ogni volta la segnalazione di errore che indica che il modulo redirfs non è stato caricato. 
Ripeto è proprio un'inezia secondo me, ma mi da l'impressione di poca cura verso un prodotto che, anche se gratuito, meriterebbe un pò di più attenzione.
Detto questo la scansione rileva in maniera efficace i virus di test e segnala anche i keygen come minacce, anche se in realtà si tratta di falsi positivi.


Questo antivirus mi ha deluso lasciandomi perplesso riguardo al reale interesse che l'azienda produttrice possa avere su questo prodotto, perchè dico questo, semplicemente perchè terminata l'installazione il programma non funziona.
Dopo aver aggiornato le definizioni del database dei virus un qualsiasi tentativo di scansione riporta un laconico messaggio che indica che il "motore non è stato caricato" o "engines not loaded" in versione inglese.
Sul loro forum c'è un post del 2011 che discute di questo problema, con una serie di comandi che dovrebbe risolverlo.
Sfortunatamente quelle istruzioni non risolvono il problema sui sistemi che usano RPM, io su Centos 7 a 64 bit e Fedora 25 a 32 bit con quelle istruzioni non ho risolto nulla .... su Debian Stretch a 64 bit invece hanno funzionato.
Onestamente mi domando come sia possibile che un problema già noto nel 2011 si ripresenti e non si risolva nel 2017 ..... ecco perchè dubito che ci sia un reale interesse verso questo prodotto. Ed è un peccato perchè sarebbe disponibile sia a 32 che a 64 bit, sia in formato DEB che RPM, ha sia l'interfaccia grafica che quella a linea di comando, quindi in grado di coprire le diverse esigenze degli utenti. Inoltre, su Debian Strecth, dopo aver risolto la scansione si comporta bene rilevando i file infetti e anche i keygen. 

SOPHOS

Dopo aver scaricato il file in formato tgz e averlo scompattato andrà eseguito il classico script di installazione, install.sh, che procederà a farci alcune domande per poi installare il programma con le definzioni aggiornate.
In fase di installazione possiamo abilitare la scansione realtime, on-access scanning come la chiama lui.
La scansione avviene solo da linea di comando in quanto anche questo antivirus non prevede interfaccia grafica, i risultati sono in linea con gli altri antivirus, anche questo non rileva nulla sui keygen.
La scansione on-access funziona a dovere intercettando al volo e segnalando i file infetti.
Un neo è che la cartella del programma, creata per default sotto /opt è accessibile solo all'utente root per cui bisogna usare sudo anche solo per vederne il contenuto, e quindi capire quali comandi sono disponibili.

F-PROT

L'installazione non è proprio per l'utente medio, il file è fornito in formato tar.gz e va scompattato, poi da bravi bambini bisogna leggere il file README e seguire le istruzioni, un paio di comandi da eseguire da shell per lanciare poi lo script di installazione vero e proprio.
Lo script di installazione al termine chiede se si vuole venga modificato il crontab per l'aggiornamento automatico, poi per l'uso del software ci sono solo due comandi, da shell, fpscan e fpupdate .... lascio a voi immaginare cosa facciano ;-)
Le prove di scansione hanno dato esito positivo evidenziando i file infetti usati per il test, anche in questo caso nessuna segnalazione per i keygen.
Sicuramente un buon antivirus per gli utenti che non hanno problemi a muoversi nella shell ma la mancanza di un'installazione standard, basata su pacchetti DEB o RPM o un installer grafico dedicato e di una gestione grafica dell'antivirus non lo rendono adatto ad un uso desktop, che magari non è nemmeno stato preso in considerazione.

ESET NOD32

Questo antivirus può essere scaricato e usato in modalità trial, e poi va eventualmente acquistato perchè non esiste una versione gratuita.
L'installazione è semplice ed avviene in modalità grafica, al termine va riavviato il PC, fa tutto da solo se glielo lasciate fare, al primo avvio viene chiesta la propria mail per attivare la licenza di prova.
Senza la licenza di prova non sarà possibile aggiornare il database delle firme ma il software risulta funzionante quindi lo si può testare fin da subito.
Anche questo programma prevede la possibilità di essere eseguito sia da linea di comando che dalla propria interfaccia GUI, che risulta semplice ed efficace. La scansione ha rilevato i file di test dei virus ma non ha segnalato anomalie sui keygen, il software prevede la scansione in realtime, che può essere anche disabilitata se dovesse impattare negativamente sulle performance del PC. Scaricando da internet alcuni file infetti questi sono stati subito intercettati ed eliminati.
Il programma si avvia in automatico ed è visibile e richiamabile dall'icona nella taskbar.
Una nota per quanto riguarda la licenza di prova, dopo aver impostato la mia mail in fase di installazione non ho ricevuto nulla nelle ore successive quindi ho trovato questa pagina da dove ho scaricato una username/password per avere i 30 giorni di prova e quindi procedere con l'aggiornamento delle firme.

Aggiornamento del 24 febbraio 2017.

L'interfaccia grafica del programma non si avvia più ... anche eseguendo il comando manualmente questo si blocca senza nessun messaggio di errore, il problema sembra essere nel "demone" esets_daemon che riporta sempre il messaggio :
error[24210000]: Impossibile inizializzare scanner: Module init
Nessuna notizia in rete, o meglio una sola che non mi ha aiutato, probabilmente una volta disinstallato il programma e poi reinstallato il problema si sistema ..... ma mi sono limitato solo alla rimozione del software.

A conclusione di questa mia breve, e sicuramente insufficiente, panoramica devo dire che per gli utenti che hanno una certa familiarità con la shell le possibilità non mancano e quindi la possibilità di usare i comandi di scansione o manualmente o in script, o in crontab possono servire per aumentare il controllo in ambienti dove ci siano altri PC Windows e risorse condivise. A livello di utenza desktop mi pare che le cose non vadano proprio bene, a meno di non spendere qualche decina di euro e acquistare ESET NOD32 che rispetto ai due diretti concorrenti, COMODO e BitDefender, si installa in maniera molto semplice e senza nessun problema.

Diciamo che al momento, come utenti linux, possiamo ancora vivere tranquillamente senza un antivirus .... poi se abbiamo PC Windows in casa e questi dovessero venire brutalmente distrutti da un virus .... beh forse non tutti i mali vengono per nuocere.