Author Archives: spookyh

The old good Linux vs Windows

Leave a reply

Tra la fine degli anni ’90 ed i primi del 2000, sul web e nelle riviste di informatica, erano piuttosto popolari benchmark in cui venivano confrontate le prestazioni tra server Windows e Linux. Inizialmente l’interesse era rivolto soprattutto al trasferimento di file tramite SMB, poi col diffondersi sempre più prepotente delle dot.com, l’attenzione deviò verso i server web.

Spesso i primi test erano direttamente o indirettamente sponsorizzati da Microsoft, fino a quando (circa nel 2001) Linux con Samba iniziò a battere Windows sul suo stesso campo, vale a dire nelle performance sul file sharing via smb [1]. Gli amanti dell’argomento potranno trovare pane per i loro denti a questo indirizzo.

Ma tornando a noi… quando una persona con tratti di personalità ossessiva e paranoide è anche amante del retrocomputing ci sta che dopo un quarto di secolo possa voler controllare se quei test corrispondessero al vero o se fossero stati un mero esercizio di fantasia. Una quindicina di anni fa avevo già dato sfoggio di certe mie discutibili fissazioni in questo test, ma adesso ho deciso di rilanciare con un confronto a 5 tra i sistemi operativi per server più diffusi nel 2001:

  • Windows NT4: $800-$1.200
  • Windows 2000: $999
  • RedHat 7.1: scaricabile gratuitamente, $59.95 versione CD-ROM completa dei manuali cartacei, $79.95-$199 CD-ROM + manuali + vari livelli di supporto tecnico
  • Slackware 8: scaricabile gratuitamente, $39.95 versione CD-ROM, $199 CD-ROM + manuali cartacei
  • SCO Openserver 5.0.6: $695-$1,395

Per pigrizia praticità ho effettuato tutte le prove su una macchina Virtualbox con le seguenti caratteristiche: 1xCPU 2GHz, 512MB RAM, HD IDE PIIX4 da 8 GB, scheda di rete AMD PCNET-FastIII.

Per misurare le performance dei server web ho usato il tool ab effettuando un carico di 100 connessioni simultanee per un totale di 10000 connessioni con un documento da 18,6 KB.

IIS è andato meglio di quanto immaginassi, sia su NT4 che su Windows 2000 ha sopportato molto meglio i maggiori carichi di traffico rispetto ad Apache 1.3.19 e al Netscape FastTrack 2.01. Interessante notare come IIS/3 su NT4 sia andato meglio del suo successore su Windows 2000! Apache è invece riuscito ad essere competitivo solo dalla versione 1.3.20 (rilasciata a maggio 2001), quella presente di serie sulla Slackware 8 uscita a luglio, ma non ancora disponibile per RedHat 7.1 che invece era stata rilasciata a marzo. Ho voluto testare anche l’accoppiata RedHat 7.1 – Apache 1.3.27 dato che nel 2003 questa versione fu rilasciata come aggiornamento ufficiale e (casualmente?) ha dimostrato di essere (anche se non di molto) il web server più veloce tra quelli esaminati.

  1. RedHat 7.1 / Apache 1.3.27: 3.505 secondi
  2. Slackware 8 / Apache/1.3.20: 3.584 secondi
  3. MS Windows NT4-IIS/3.0: 3.616 secondi
  4. MS Windows 2000-IIS/5.0: 4.979 secondi
  5. RedHat 7.1 / Apache 1.3.19: 8.966 secondi
  6. SCO Openserver 5.0.6 / Netscape-FastTrack/2.01: 16.529 secondi

Per quanto riguarda i test di velocità di trasferimento via FTP ho utilizzato il semplice comando time.

  • Prova 1: Upload di un file da 1,35 GB
  1. RedHat 7.1 / Wu-ftpd 2.6.1 (xinetd): 9.75 secondi
  2. MS Windows NT4-IIS/3.0: 10.79 sescondi
  3. MS Windows 2000-IIS/5.0: 14.29 secondi
  4. Slackware 8 / ProFTPD 1.2.2rc3 (inetd): 16.11 secondi
  5. SCO Openserver 5.0.6 / Wu-ftpd 2.4.2: 73.44 secondi
  • Prova 2: download di un file da 1,35 GB
  1. MS Windows NT4-IIS/3.0: 14.49 secondi
  2. RedHat 7.1 / Wu-ftpd 2.6.1 (xinetd): 18.72 secondi
  3. Slackware 8 / ProFTPD 1.2.2rc3 (inetd): 24.26 secondi
  4. MS Windows 2000-IIS/5.0: 33.10 secondi
  5. SCO Openserver 5.0.6 / Wu-ftpd 2.4.2: 55.04 secondi

Prova 3: upload simultaneo di 10 file da 90MB

  1. Slackware 8 / ProFTPD 1.2.2rc3 (inetd): 9.67 secondi
  2. RedHat 7.1 / Wu-ftpd 2.6.1 (xinetd): 12.12 secondi
  3. MS Windows NT4-IIS/3.0: 13.26 secondi
  4. MS Windows 2000-IIS/5.0: 13.29 secondi
  5. SCO Openserver 5.0.6 / Wu-ftpd 2.4.2: 44.65 secondi

Prova 4: download simultaneo di 10 file da 90MB

  1. RedHat 7.1 / Wu-ftpd 2.6.1 (xinetd): 6.30 secondi
  2. MS Windows NT4-IIS/3.0: 11.56 secondi
  3. Slackware 8 / ProFTPD 1.2.2rc3 (inetd): 16.45 secondi
  4. MS Windows 2000-IIS/5.0: 20.12 secondi
  5. SCO Openserver 5.0.6 / Wu-ftpd 2.4.2: 34.75 secondi

SCO Openserver è stata la sorpresa negativa di questa batteria di test. Per chi non lo conoscesse si tratta di un sistema UNIX proprietario per macchine x86 standard basato sul SystemV 3.2 dell’AT&T e rifinito con l’aggiunta di varie applicazioni opensource come Wu-FTPd e proprietarie come appunto Netscape-FastTrack. In tutte le situazioni SCO Openserver 5.0.6 si è dimostrato molto più lento rispetto a tutti gli altri concorrenti, c’è da sperare che l’assistenza tecnica di SCO fosse oltremodo fantastica per giustificarne la preferenza rispetto ad un qualsiasi sistema Linux.
Il 2001 è stato probabilmente l’anno in cui, a livello server, Linux ha raggiunto e probabilmente superato Windows in termini di prestazioni. Mentre il sistema operativo di Redmond non è drasticamente migliorato dal ’96 al 2000, la comunità opensource ha fatto passi da gigante per rendere sempre più competitivi gli applicativi liberi nei settori più strategici di Internet: web server, server ftp, mail server, router-firewall e database service.

Hardware e tempo permettendo in futuro potrebbero uscire retro-recensioni di sistemi della prima metà degli anni ’90, stay tuned!

NixOS

Era la fine del 2005, quando dopo vari pellegrinaggi di distro in distro approdai ad Arch Linux.
Si trattava di una distribuzione relativamente giovane, sviluppata da un programmatore canadese di nome Judd Vinet, il cui primo rilascio ufficiale risale all’11 marzo 2002.
All’epoca si inspirava all’elegante semplicità di Slackware, Crux e dei BSD ed il suo motto era l’acronimo KISS: “Keep It Simple, Stupid”.

Aveva tutto quello che cercavo da una distribuzione Linux:
– AIF (Arch Installation Framework), installer testuale leggero ed intuitivo basato su menù ncurses come quelli di Debian, Slackware o FreeBSD
– pacman, un gestore di pacchetti che installa ed aggiorna software direttamente dalla rete (stile apt)
– boot rapidissimo stile Slackware-BSD
– rc.conf, un file di configurazione unico, come nei BSD con cui gestire tutto il sistema
– abs, l’equivalente dell’albero dei ports dei BSD con cui poter ricompilare e personalizzare il sistema

Verso la fine del 2007 Judd Vinet si ritira dal progetto che passa nelle mani del programmatore statunitense Aaron Griffin e pian piano, nel corso degli anni finisce per perdere tutte le sue caratteristiche originali:

Nel 2012 il passaggio a systemd deprecò l’utilizzo del file di configurazione rc.conf (rete, pacchetti, moduli del kernel).
Tale importante modifica rese inutilizzabile anche il vecchio installer, sarebbe stata necessaria una sua quasi completa riscrittura, cosa che ad oggi non è ancora avvenuta.

Infine, nel 2017, anche “abs” e tutto il sistema di sincronizzazione ed aggiornamento da sorgenti viene dismesso.

Per i nostalgici o per chi non ha idea di cosa stia parlando, questo è un esempio di rc.conf

Stufo e sdegnato per la deriva di questa ottima distribuzione ho cercato conforto altrove.
Il primo pensiero era ricaduto su Slackware, ma per quanto sia affezionato a questo dinosauro mi sono dovuto scontrare con la dura realtà dei fatti: conciliare il vetusto installer di Slack col mio desiderio di organizzare il sistema con partizioni gpt e subvolumi btrfs si è rivelata un’impresa sconcertante.

Scettico, ma spinto dalla curiosità e dalla noia dell’isolamento domestico da COVID-19 ho quindi deciso di dedicarmi allo studio di NixOS.
Si tratta di una distribuzione Linux completamente rivoluzionaria, basata sull’innovativo gestore di pacchetti Nix.

L’approccio di Nix è unico nel suo genere, permette di installare, aggiornare e rimuovere software senza che ci si debba preoccupare delle dipendenze. Il path d’installazione di ogni pacchetto corrisponde al suo hash così da permettere la contemporanea convivenza anche di più versioni dello stesso programma. Gli aggiornamenti sono “atomici”, non vengono scaricati interi pacchetti deb, rpm o tgz, ma solo i file necessari. È inoltre possibile tornare indietro alla configurazione precedente all’installazione di un dato software in maniera semplice ed automatica.

L’aspetto che più entusiasma di questa distribuzione è la possibilità di tornare a gestire in maniera centralizzata tutti gli aspetti attraverso un unico file di configurazione (/etc/nixos/configuration.nix). Diventa semplicissimo replicare un’installazione su più macchine, fare cache dei pacchetti, gestire installazioni su sistemi virtualizzati o creare un supporto d’installazione personalizzato.
Si ha la sensazione di trovarsi di fronte ad un vero e proprio sistema operativo più che ad un assembramento di software, lo scotto da pagare per sfruttare tale potenza è il dover familiarizzare col suo linguaggio. Su NixOS le cose NON si fanno come sugli altri sistemi Linux.

Howto

Applicazioni Linux universali

app

Sarebbe bello se tutte le distribuzioni usassero lo stesso formato di pacchetti… probabilmente non accadrà a breve, ma in questa direzione si stanno affermando dei nuovi gestori di pacchetti che promettono di rivoluzionare (in positivo si spera) il modo di sviluppare e distribuire software su Linux.

Snappy

Ideato da Canonical ed adottato da Ubuntu (in parallelo ai pacchetti .deb a partire dalla versione 16.04) e da Ubuntu Touch.
Nel giugno di quest’anno è stato effettuato il port per svariate distribuzioni (Arch, Debian, Fedora/Red Hat, Gentoo, SUSE e Red Hat)
In linea teorica un pacchetto snap può quindi essere utilizzato praticamente da qualsiasi distribuzione Linux.

Com’è possibile tutto questo?
Di fatto si tratta di un’immagine di filesystem compressa contenente tutto il necessario per far girare un programma, questo viene automaticamente montato in loop dal demone snapd ed i suoi eseguibili vengono linkati in /usr/snap/bin.

PRO
– Semplice da utilizzare, ha un tool da riga di comando stile apt-get (snap find, snap install, snap remove…)

CONTRO
– Sembra il tentativo di Canonical di creare un Google Play per rifilare a tutti gli utenti Linux software a pagamento.
– Al momento sono pochi i programmi disponibili in questo formato

Flatpak (aka xdg-app)

Progetto nato circa un anno fa con lo scopo di creare un’alternativa libera dello Snappy di Ubuntu.
Non ha un repository principale come Snappy, è necessario configurarlo inserendo manualmente quelli che ci interessano:
es.: per installare GNOME
curl -O https://sdk.gnome.org/keys/gnome-sdk.gpg
flatpak remote-add --gpg-import=gnome-sdk.gpg gnome https://sdk.gnome.org/repo/
flatpak install gnome org.gnome.Platform 3.20
flatpak install gnome org.gnome.Sdk 3.20

PRO
– Permette di installare molto più software rispetto a snapd: es. Libreoffice, Firefox…
– Non ha un repository principale contenente anche programmi a pagamento
– Permette di creare pacchetti flat a partire

CONTRO
– Sintassi leggermente più complicata di snap

AppImage (aka Klik)

I pacchetti .AppImage sono concettualmente simili ai programmi per MacOSX.

Sono anch’essi file immagine compressi contenenti l’applicazione e tutte le librerie necessarie al suo utilizzo.
Basta scaricare il file, eseguirlo o cliccarci sopra ed il programma si installerà. Per cancellarlo è sufficiente cestinare l’icona del file.

PRO
– Installare un programma su Linux non è mai stato così facile. Finalmente un formato click’n’run stile MacOS per Linux.
– Elevata disponibilità di programmi https://bintray.com/probono/AppImages

CONTRO
– Anche se praticissimo per distribuire grossi pacchetti stile VLC, LibreOffice, Firefox o Chromium, questo tipo di formato difficilmente potrà essere utilizzato per pacchettizzare il sistema di base.
– Non esiste un tool stile apt-get per cercare ed installare “AppImmagini”
– Non possiede un tool per creare pacchetti a partire da un tarball.
– I file non vengono linkati in una directory di sistema (es. /usr/bin) per cui in caso di sistemi multiutenti ogni utente dovrà scaricarsi nella sua home il suo pacchetti .AppImage

Acer Altos EasyStore

1 Reply

altos_acer_easystorePrima della diffusione di massa di Ubuntu era sufficiente usare Linux per rientrare nella categoria degli “smanettoni” di computer, oggi per definirsi tali c’è bisogno come minimo di avere in casa un serverino ARM 🙂

Raspberry Pi, OLinuXino, CubieBoard sono solo alcuni dei progetti basati su chip ARM Allwinner che da qualche anno infestano le nostre scrivanie.

Non appagato dall’OLinuXino installato tempo fa per il GOLEM, ho deciso di attrezzarmi anche a casa.

Pur trattandosi di un investimento contenuto, prima di spendere qualche decina di Euro per una scheda nuova, faccio visita alla mia seconda discarica di hardware dismesso preferita: lo scantinato dell’ufficio dove lavora mio padre.
Abbandonato in un angolo trovo un Acer Altos Easystore, un NAS di circa 7 o 8 anni fa che si accende e sembra in eccellenti condizioni, così decido di portarlo a casa per testarlo in maniera più approfondita.

È dotato di 4 hard disk hotswap SATA da 500 GB configurabili in RAID 5, processore ARM XScale-80219, il software è una versione embedded di Linux realizzata dalla FalconStor dove per fortuna è possibile abilitare SSH dall’interfaccia html https://…easystore-name-or-IP…/ssh_controlF.cgi (user: root; password: storage).

Mi piacerebbe compilare qualche nuovo programma per questo sistema, provo con Buildroot, i tentativi vanno a buon fine, ma gli eseguibili prodotti non girano. Dopo qualche ricerca scopro che esistono vari port per ARM, a quanto pare avevo tra le mani un ARM OABI a cui stavo tentando di propinare eseguibili EABI.

Ecco come Debian distingue i port per ARM
– ArmPort: primo port, usa il vecchio ed ora obsoleto ABI (OABI). Primo rilascio Debian 2.2 (Potato), ultimo Debian 5.0 (Lenny).
GNU Triplet: arm-linux-gnu

– ArmEabiPort: nuovo port, usa il nuovo ABI (EABI), supporta ARM v4t e superiori. Primo rilascio con Debian 5.0 (Lenny).
GNU Triplet: arm-linux-gnueabi

– ArmHardFloatPort: l’ultimo port a 32-bit, usa la versione hard-float del nuovo ABI (EABI), supporta ARM v7 e superiori. Primo rilascio con Debian 7.0 (Wheezy).
GNU Triplet: arm-linux-gnueabihf

– Arm64Port: ultimissimo port per ARMv8 a 64-bit. Sarà rilasciato con Debian 8.0 (Jessie).
GNU Triplet: aarch64-linux-gnu

Port non ufficiali
– Raspbian: usa la versione hard-float del nuovo ABI (EABI) come armhf, ma per ARM v6. Disponibile su Debian Wheezy e Jessie. Primariamente, ma non esclusivamente, sviluppata per il Raspberry Pi.
GNU Triplet: arm-linux-gnueabihf

– armeb: port Big-endian OABI per linksys NSLU2 e simili, adesso abbandonato.

Provo a compilare rsync su una vecchia versione di buildroot supportante la modalità OABI e funziona!
Per fare prima, per altri programmi, spacchetto direttamente file deb attinti dai repositori ARM di Debian Lenny (facendo attenzione a portarmi dietro anche le eventuali librerie).
Ottengo un sistema discretamente funzionante, ma non riesco però a farci funzionare un server DLNA. Piuttosto che rinunciare a collegare il NAS al lettore DVD decido di spulciare la rete alla ricerca di qualche firmware customizzato per questo trabiccolo.

Dopo qualche GIORNO di ricerca scopro che l’Acer Altos Easystore, come il LaCie 301161U, risultano essere cloni dell’Intel SS4000-E, piattaforma supportata da Debian!

Altri NAS supportati, basati su scheda madre Intel EM7210 e CPU Intel 80219, sono:
Newisys NA-1400, Thecus N2100, GLAN Tank.

Sul WIKI la guida all’installazione.