Index of UNOFFICIAL Circumvesuviana Home Page La mia tesi di laurea main index Brevissimamente: da quando ho scoperto Linux, per i miei computer esiste solo Linux. Qui sotto una breve antologia di messaggi che ho scritto negli scorsi anni (1996-1999), man mano che scoprivo qualcosa.

Se invece cerchi software, clicca qui. Se cercavi invece di configurare un notebook, clicca qui.

Here are some notes regarding Linux (and Unix) world.
Since when I discovered Linux... in my computers there has been only Linux!! The title of this page says "...so, they always say that I like Linux..."
Software: click here; notebooks and Linux: click here.
Musica suggerita durante la visione di queste pagine: Chopin, Preludio op.28 n.15.

Devo anche premettere, di tutto il materiale qui sotto, che è mio originale, comprese le sviste, gli errori di valutazione, le fosche previsioni, l'ironia beffarda, le descrizioni fantozziane dei guai e tutto il resto.

Tragicamente, nel mondo del lavoro ancora non si era affermato Linux. Specialmente dove lavoravo io. E così, tra un guaio di Windows e l'altro, avevo anche tempo di arrabbiarmi e scrivere in rete che Linux è meglio di Windows. A distanza di un po' di tempo posso ancora confermarlo, anche se i toni di oggi sono molto meno drammatici di qualche annetto fa...!


Sommario delle chicche più gustose:

CLAMOROSO! L'ebbrezza del CP/M-86 - Linux significa AFFIDABILE - riciclato un floppy con la testina rovinata! - una Ethernet col FIL DI FERRO! - DELIRIO! ho provato il linguaggio Modula-3 - Linux in ufficio ci salva dai guai di Windows! - campionare audio oppure programmarlo.


Sono stato io, nella primavera del 1994, a far arrivare Linux nell'Università di Salerno. Lo avevo scoperto per caso; avevo già visto da qualche parte quel nome, ma non me ne ero interessato perché tutto ciò che non si chiamava "Unix" per me non era di grande interesse.

Poi ho scoperto che Linux aveva a che fare con Unix. Anzi, era proprio Unix. Anzi: meglio di Unix, non soltanto in senso "tecnico".

Dunque...


hellou, tis is linus turvalds, end ai prenauns linucs as "linucs" :-)


Il seguente programmino:

char buf[160][64];
main() {... }

una volta compilato, era un bombardone di 20k (!!!). Cambiando la dichiarazione di cui sopra:

static char buf[160][64];
main() {... }

diventa un bombardino di 10k (buf è stato spostato dal segmento "data" al segmento "bss"!!! per cui non viene allocato nell'eseguibile!).

Altra cosa che può dare filo da torcere: le stringhe, diversamente dalle nostre abitudini DOS, sono in un segmento di memoria read only :-). Cioè:

char *p="turzland";
sprintf(p, "%d", getpid()); // SIGSEGV: segment violation!!!

Parentesi: da parecchie versioni del gcc questo problema non esiste più; peraltro, "strippando" i simboli, si riduce a due kappa scarsi:
strip -s -R .comment -R .note bombardino ; ls -al bombardino

Ho trovato sui CD del Linux Toolkit una vecchia versione di Andrew (3.1).

Sono secoli che parliamo di nuovo standard per i messaggi per le BBS, e questo è semplicemente allucinante.

Permette font diversi, titoli, paragrafi, etc; prevede icone che "esplodono" in animazioni, disegni, equazioni, tabelle, finestre, audio, postscript, etc. Per non parlare di tutti i programmi a corredo, che ancora non ho provato...

Ho scritto un messaggio di prova contenente testo formattato e con un paio di note inizialmente non visibili, e al centro della pagina un'immagine GIF. Scusate la bava...

E questa è una versione del '93; ora ci smanetto un po' di più e vi faccio sapere... nel frattempo se avete una versione più recente, provatela!!!


Ho visto alcuni demo del Modula-3 che da tempo avevo tralasciato perché avevo dimenticato di fare i link delle librerie in /lib. Clicca qui per le immagini FS

Sono qualcosa di *realmente* spaventoso. Prova un po' Mentor e FishEye (anche se dichiarano che il primo dei due contiene qualche bug) e dimmi se hai _mai_visto_ sotto Winzozz cose simili. Specie su un 486 con VGA ISA (!!!) e con "soli" 20 Mb RAM (anche se con soli 20 Mb RAM per alcune cose Mentor non ce la fa).

Per non parlare degli allucinanti WebScape, DeckScape e Postcard...

Per non parlare del solitario, del formsedit, delle varianti di tetris... Se viene qualche altro "microsoftista" a casa, gli farò vedere questi!

La cosa più clamorosa (mannaggia, quest'aggettivo si è inflazionato) è che quella roba è stata fatta senza Motif (che ho sempre detto che non è bellissima; per giunta si paga; ma come può venire in mente a chi usa Linux di usare quella roba?) e senza OpenLook (che pure giudicavo carina, e che mi aveva fatto pensare che Motif fosse un esercizio di un universitario alle prese con un esame di informatica).

Cioè quei prg usano una sua libreria scritta semplicemente in Modula-3 che sfrutta fino a raschiare il fondo X11R4... sì, erre quattro!!! Hai letto bene: "due versioni fa"! dopotutto quei prg sono del '93-94...! Oops, quasi dimenticavo: threads a non finire, lo stesso programma apre diciotto finestre contemporaneamente e vedi ognuna andare avanti "per i fatti suoi"... librerie per web, motif (anche questo, dopotutto c'è sempre qualche fanatico), lisp, 3D, etc...

Infine, e questa cade come una mannaia, è stato scritto *tutto* in Modula-3. Anche un maniaco del C++ come il sottoscritto deve ammettere (arrrgh) che il C++ fa una pessima figura, a confronto.

Rimpiango i tempi in cui lessi per la prima volta un articolo entusiasta sul Modula-2. All'epoca stavo ancora imparando il C (quindi parecchi anni fa) e, con aria di sufficienza credevo di avere "tutto" in mano.

Poi passai alla programmazione a oggetti, perché i miei programmi seri erano saliti di un ordine di grandezza - da poche centinaia di linee in C a parecchie migliaia di linee in C++ - e il problema del debugging si faceva drammatico...

...fino al punto di chiedermi come mai Linux è stato scritto in C anziché in C++ (del resto scorrendo il sorgente del kernel si notano alcune furbate per emulare un "comportamento a oggetti", come per esempio la struct file_operations con i metodi per lseek, read, write, readdir...).
Pensavo che il problema fosse solo di "eleganza dei listati", e che addirittura i linguaggi a oggetti "eleganti" fossero solo per gli universitari (e non per chi lavora).

Dopo aver provato quei programmi, dopo aver ipotizzato almeno lontanamente la fatica da fare per farne degli equivalenti in Linux, scorrendo listati e files di documentazione, mi rendo conto che effettivamente il Modula-3 fa risparmiare seriamente sotto tutti i punti di vista: di pazienza, di debugging, di "passaggio" dal progetto cartaceo al listatone, etc.

Cose mai viste, davvero. Uno stupore addirittura superiore a quello che avevo provato quando cominciai a capire che il C++ non era "C con qualche ammennicolo per scrivere meno righe e più belle".

Qualcuno qui potrebbe aspettarsi un'affermazione infantile del tipo "ma allora Linux andava scritto in Modula-3". Per adesso 'sta frase mi fa solo ridere.

Qualcun altro potrebbe pensare che a furia di vedere oggetti grafici a video possa essermisi annebbiata la vista. È una patacca anche questa, che però merita, per l'ennesima volta, una simpatica citazione: fino al W95 compreso (non ho ancora provato W98), lo spazio per i vari Pen, Brush, etc, è, indipendentemente dalla quantità di megabytes di memoria RAM, ancora limitato a 64k... (sessantaquattro kappa, avete letto bene: per questo io dico winDOGS, perché è fatto da cani, e non solo per modo di dire). Per cui se un programma usa X, se lo usa seriamente (non certo partendo da sorgenti per Winzozz riadattati a X), i risultati si vedono. E nei demo che ho visto, i risultati si vedono...

Dietro quella montagna di cose belle, funzionanti e arcitestate, ci sono molte meno ore di programmazione e debugging di quante ne possa immaginare anche uno che smanetta dall'84 come il sottoscritto. Certo un DeckScape non si progetta e realizza in una settimana, però scriverlo in C++ è un incubo, scriverlo in C è umanamente impossibile anche per uno squadrone di progettisti e programmatori pluristipendiati. E scriverlo in modo da evitare "Errore dell'applicazione irreversibile" rasenta l'utopia... ;-)

Bene, ora viene il cruccio finale: perché mai non dovremmo abbandonare tutto, immediatamente, per passare al Modula-3.

Click here for Linux on Asus notebooks! Devo consigliarlo o no, M3?

In primo luogo, M3 è per una "nicchia" di utenti, per pochi pazzi, ecco tutto. Non lo conosce nessuno, salvo alcuni ambienti universitari strettamente informatici... questo argomento sarebbe sufficiente per lasciar perdere.

In secondo luogo, bisognerebbe insegnarlo a chi di programmazione non sa ancora nulla. Purtroppo tutti noi abbiamo esperienza di linguaggi imperativi (fai questo e poi fai quello) e talora descrittivi (come un /etc/passwd), dunque partiremmo con un buon numero di "pregiudizi" più o meno radicati, anche se non ce ne accorgiamo (la prima cosa che ho cercato di capire, una volta passato a Linux, è se fosse stato possibile usare il video esattamente come lo usavo in DOS, cioè col mefitico b800:0000hex...:-)

Naturalmente chi ha smanettato in C++ (o in altri linguaggi ad oggetti) pure ne verrà influenzato in modo probabilmente non positivo per quello che è l'obbiettivo da raggiungere (cioè "modula3izzarsi" :-).

Il Modula-3, a prima vista, sembra un "Pascal con oggetti". Però, più si va avanti, e più si capisce che dietro c'è proprio una "filosofia", così come c'è dietro il C++. M3 non è vicino a quasi nessuno dei classici "modelli" di programmazione; faccio un solo esempio per tutti, la garbage-collection: il dramma dei puntatori di C e C++ in M3 non esiste.

Non posso andare oltre nella descrizione perché il rischio di dire una idiozia a questo punto comincia ad essere maggiore di zero, per cui mi fermo qui e rinvio a tempo indeterminato la terribile questione :-)

Gli esempi mi hanno convinto, e i listati mi hanno convinto ancora di più. Sono costretto ad ammettere, nonostante la mia fulgida esperienza :-), che la mia "formazione programmatoria pluriennale" :-) è andata su di un binario che non era il migliore.

E così, mentre la gente si svena per comprare K6, P-PRO, P-II, etc, per farci funzionare Winzozz a velocità almeno decente, io su un 486 vecchio ormai di più di due anni e due mesi, ho visto scintille, fuoco e fiamme, per giunta su un Linux a cui non piacciono gli sprechi (fatte salve alcune cosucce di X)...

Fine dello sfogo :-)


Questo doveva essere un messaggio d'aiuto, ma pare proprio che prima di spedirlo abbia già risolto tutto... :-)

Un mio programma si "impossessa" del modem nel modo "gentile" in cui mgetty si aspetta il locking (ed anche uucp, ed anche ifcico, etc!!) e non viene disturbato da nessuno. Purché naturalmente sia del gruppo uucp (perché /dev/ttyS3 è crw-rw---- uucp.uucp). Più facile di quanto potessi immaginare...

Non mi dilungo in spiegazioni perché nel file locks.c dei sorgenti di mgetty c'è tutto quel che serve. Scavando nei sorgenti altrui c'è sempre qualcosa di nuovo da imparare... :-)


E poi dicono che io parlo bene di Linux

Ho compattato la messagebase con RAR 2.0, ed ecco i risultati:


RAR 2.0 "classico": 18296774 bytes, 5628141 compressi, riduzione: 30%
con 128k di buffer:                 5312189,                      29%
con 256k di buffer:                 4894033,                      26%
con 512k di buffer:                 4452605,                      24%
con 1 Mb di buffer:                 4102658,                      22%

Il RAR "classico" usa solo 64k di buffer a causa delle mefitiche segmentazioni del DOS... invece, visto che si tratta di grossi files, più aumento la grandezza del buffer e più migliora la compressione. Il buffer in questione è il "dictionary size" (switch "-mdX", con X uguale ad a,b,c,d,e per 64k...1024k). Il che sotto DOS non si può fare.

Insomma, comprimendo sotto Linux, ho risparmiato più di un mega e mezzo: se prima ci volevano quattro dischetti, ora ce ne vogliono solo tre!!!


cp/m-86 v1.0... sotto dosemu!

Che emozione... ho caricato il cp/m-86 sotto DOSemu: è bastato aggiungere la riga:

floppy { heads 2 sectors 8 tracks 40 fiveinch file cpm86.dsk }

per far caricare la disk-image che nel remoto 1991 mi feci partendo dal floppy originale, che aveva i parametri suddetti, prima che quelli della megaditta buttassero tutto (scrissi un programmino in C per l'occasione).

Ecco cosa si vede a video dopo la partenza:


CP/M-86 Bootstrap Loader 1.0
Reading Track 0 1 2 3 4

CP/M-86 for the IBM Personal Computer.
Version 1.0
Copyright 1982, Digital Research Inc.


Hardware Supported :
                    Diskette(s) : 1
                     Printer(s) : 0
                 Serial Port(s) : 0
                    Memory (Kb) : 128


A>
              |U=00|02/10/82|00:02:18|

Da notare: "User=00", cioè disperato tentativo di multiuser in monotasking, con tanto di status-line sulla 25esima riga (come la barra "Avvio" di Wirus95, oppure, più probabilmente, perché il software in circolazione lavorava su 24 righe perché i terminali più di tanto non facevano)... le directories non esistevano ancora... la data di default è mercoledì 10 febbraio 1982, cioè presumibilmente la data ufficiale del rilascio (e nel 1982 non c'erano ancora le schede timer per PC/XT)... memoria massima utilizzabile 128k (!!!) anche se il sistema ne riporta fino a 640 (figurarsi poi come vengono bellamente ignorati i diversi mega di XMS, EMS, etc).

Ecco che dunque dò un altro comando (DIR non dà le statistiche):


A>stat *.*

 Drive A:                         User :  0
 Recs  Bytes FCBs Attributes      Name
  205    26k    2 Dir RW        A:ASM86   .CMD
   16     2k    1 Dir RW        A:ASSIGN  .CMD
   19     3k    1 Dir RW        A:COPYDISK.CMD
  109    14k    1 Dir RW        A:DDT86   .CMD
   72     9k    1 Dir RW        A:ED      .CMD
   14     2k    1 Dir RW        A:FUNCTION.CMD
   45     6k    1 Dir RW        A:GENCMD  .CMD
   52     7k    1 Dir RW        A:HELP    .CMD
  195    25k    2 Dir RW        A:HELP    .HLP
   50     7k    1 Dir RW        A:NEWDISK .CMD
   59     8k    1 Dir RW        A:PIP     .CMD
   14     2k    1 Dir RW        A:PROTOCOL.CMD
   14     2k    1 Dir RW        A:SPEED   .CMD
   73    10k    1 Dir RW        A:STAT    .CMD
   31     4k    1 Dir RW        A:SUBMIT  .CMD
   21     3k    1 Dir RW        A:TOD     .CMD
----------------------------------------------
Total:  130k   18
A: RW, Free Space:        11k
A>

Notare i file-control-blocks dei files, i records da 128 bytes (perché all'epoca erano ancora di moda i flopponi da otto pollici, 77 tracce, settori da 128 bytes, fino a 168k se doppia faccia)...

Il comando COPY non esiste ancora, c'era infatti PIP. NEWDISK è format, PROTOCOL e SPEED setuppano la seriale, SUBMIT serve per eseguire files batch (sì, ci voleva SUBMIT AUTOEXEC.BAT !!! :-), TOD visualizza e modifica data e ora, HELP addirittura un help contestuale sui comandi (davvero innovativo, per l'epoca! :-). ASSIGN somiglia a quello DOS; COPYDISK è il diskcopy (ma no!), ED è l'editor, FUNCTION programma i tasti funzione (F1="dir" per default), e infine ci sono i tool di sviluppo: asm86/ddt86/gencmd (assembler, debugger e linker)!!!

Clicca qui per la sezione ELICOTTERI Quando il sistema parte, esce la scritta "loading track 0... 1... 2..." ad ogni traccia che viene caricata :-) Se si carica da floppy disk è davvero folkloristico.

Sotto DOSemu ruba parecchia CPU perché evidentemente i programmatori della Digital hanno fatto il solito ciclo "cicla continuamente finché non trovi un tasto premuto".

Il CP/M originale, il mitico CP/M-80 2.2 (Control Program for Microcomputers, versione per 8080 e Z80) vedeva al più 64k, e quindi, con questo nuovo potente processore a 16 bit qual era l'8088, avendo scoperto che prevedeva i registri code-segment e data-segment, avendo insomma capito che l'uso "combinato" permetteva di vedere ben 128k restando lontanamente compatibili con gli sforzi dei programmatori del CP/M originale, pensarono bene di sfruttare la scia del successo del CP/M con questo nuovo potentissimo sistema operativo, rilasciato nel febbraio 1982...! :-)

Sono poco meno di sedici anni fa, ed è già archeologia del software :-)


printf("%d", sizeof(double)) dà 8 (un double è allocato in 8 bytes).

printf("%d", sizeof(long double)) dà 12 (occupa ben 8 bytes: che formato è? IEEE? o che altro?).

printf("%d", sizeof(long long double)) dà... 8 :-) senza errori :-)

Parentesi: quest'ultimo era un bug che nel gcc è stato corretto da tempo. Il tipo "long double" continua ad esistere e a richiedere la bellezza di 12 bytes...!

Non vorrei aver "imparato Linux" per poi spacciarmi "esperto di SCO"...

Un tizio che non sopporto mi ha detto quanto segue (e purtroppo in questo discorso non si può ribattere ammettendo la bontà di Linux):

«Una volta, quando NT costava 4-5 milioni, un "sistemista NT" era di gran prestigio. Oggi, che NT costa 7-800mila lire, un "sistemista NT" è una mezza cartuccia. E se dici che sei "sistemista Linux", e sanno tutti che Linux è gratis, allora non vali proprio niente.

Insomma, qui l'informatica la fa la Microsoft, indipendentemente dal fatto che NT sia una schifezza e Linux sia roba buona: come fai a dire a un cliente "ti installo un server Linux"? quello ti ride dietro e magari pretende pure di non pagarti...».


Qualcuno mi chiede: vorrei installare il Linux sul mio 486...

  1. scegli il filesystem umsdos, in modo da non riformattare l'ardisco; svantaggi: sprechi in velocità e in spazio su disco;
  2. io ho finora usato la slackware anziché la debian; quest'ultima non l'ho mai provata ma a quanto ho letto è certamente migliore di molte altre (compresa la slackware a cui purtroppo sono abituato);
  3. Linux è quello, indipendentemente dalle distribuzioni debian, slackware, red hat... e se cominci ad usarlo massicciamente scoprirai quanto a fondo sfrutta il PC che hai (altro che DOS+Win).

Parentesi: sono stato qualche anno con la RedHat, poi con la Mandrake, e da un po' mi sono "convertito" alla SuSE.


Come se non sapessi già che Linux è una favola...

Mi danno una scheda di rete su bus PCI. Totalmente anonima, priva di qualunque scritta o indicazione. Premetto che ho una scarsa esperienza di reti locali (e per uno "sparapose" come me, è notevole).

La metto nel PC, riconfiguro il kernel attivando una marea di schede di rete (perché non so questa di che tipo è), ricompilo e faccio il reboot.

Mi dice che la riconosce come NE2000, va a pescarsi address (6000h) e IRQ (9) dal BIOS PCI.

Metto i cavetti, aggancio all'hub, lancio ifconfig e route: funziona tutto, quel catafalco DOS lì dietro prevedeva telnet, e telnet qui mi funziona al primo colpo: i led dell'hub lampeggiano spavaldamente.

Poi mi accorgo di avere anche il dischetto a corredo della scheda :-).

Oggi le comiche: scopro sul dischetto drivers e programmi TSR per supportare quello che il kernel di Linux fa ordinariamente (IPX, etc),

Oggi le comiche 2, la vendetta: ci sono anche i drivers per SCO Unix (mentre Linux ha ancora tutto di serie, e funziona benissimo), e nel readme.txt della directory scounix c'è scritto "...Under SOC Unix" :-)

Ah, utilissimo, c'è anche il programmino di diagnostica. Naturalmente ci vuole il DOS... :-)


Linux, musica per le mie orecchie

Ho provato Xwave 0.6 (xwave-0.6.tar.gz), è davvero ben fatto - cento volte meglio di quella "fetenzìa" di Blaster Master per DOS.

XWave permette di campionare e salvare in formato Riff/Aifc/Au/raw con compressione Pcm/Alaw/Mulaw/Adpcm (su questi formati e sul tipo di compressione vorrei saperne qualcosa in più: quale mi conviene usare?).

Ho collegato al mic della scheda sonora la cuffia della radio. Quindi ho cliccato su "Rec" e quando ho mosso la rotellina del volume della radio fino a vedere che il "record level" a video raggiungeva valori decenti, dopodiché ho registrato circa 75 secondi alla massima qualità (44.5 khz, 16 bit stereo) salvando in au/mulaw, ottenendo clamorosamente un file di poco più di 6 mega e mezzo (88k/sec), che è la metà del file in formato raw (ma è comprimibile con gzip fino a 57k/sec, mentre col RAR 2.0 si scende fino a 53k/sec).

Ora il pallino è questo: una radio FM sempre accesa, agganciata al mic della soundcard; con "at" gli dico di "registrare" un giornale radio a 8 khz mono (qualità telefonica; dopotutto non è musica ma parole) per poi riascoltarlo in un secondo momento... Ci manca solo il telecomando (e la funzione in C per cambiare stazione, ma credo che questo stereo Amstrad "made in Cartagine" non preveda simili features)! =:-)

Ed ecco ora le domande:


Porta della camera dei commilitoni, dopo che la sfondai con una pedata. Ancora sul filesystem umsdos

Alla fine dell'installazione della Slackware ho notato che avevo un solo programmino shareware (xv), alcuni programmi freeware, e tutto il resto in licenza Gnu (cioè gratis e con sorgenti).

Linux supporta parecchi filesystem: il suo (ext2), quelli di alcuni Unix (BSD, Coherent, SCO, Minix, etc), quelli DOS (FAT, VFAT del '95, etc), quelli di altri sistemi (Amiga, OS/2, etc), nonché alcuni nati in ambiente Linux (xiafs, umsdos, etc). Basta riconfigurare e ricompilare il kernel (ma di solito nei files di installazione c'è già un kernel configurato col supporto di umsdos... almeno nella Slackware così è).

Una partizione umsdos ("Unix on top of MSDOS filesystem") si appoggia su una partizione DOS già esistente, e la directory principale della umsdos è nella directory \LINUX di quella DOS. Dunque tu da DOS+Win vedrai solo comparire una directory \LINUX con una marea di files sotto.

Le differenze nelle distribuzioni sono parecchie, ma solo dal punto di vista di chi configura il sistema. Installando i pacchetti software, di solito non ci si accorge di nulla. Io comunque continuo a pensare che la Debian sia migliore.

Problemi puoi averne solo se ti ostini ad usare software linkati staticamente con vecchie librerie (per esempio di Linux 1.xx.xx quando magari usi Linux 2.0.xx); ma in quel caso è sufficiente ricompilare.


e poi dicono che io parlo bene di Linux (sono monotono, eh?)

Problema hardware: ho un drive da 1.44" cui si è sfasciata la testina 1 (quella di sotto), a causa di un dischetto che, rimasto incastrato dentro, mi ha costretto ad estrarlo con le maniere forti.

Il problema è stato risolto con l'inevitabile acquisto di un altro drive, ma mi dispiaceva buttare quello fuso. E così ho aggiunto in /etc/fdprm le righe:


#               size sec/t hds trk stre gap  rate spec1 fmt_gap
faccia0          729     9   1  81    0 0x2A 0x02 0xDF     0x50
faccia0h        1458    18   1  81    0 0x1B 0x00 0xCF     0x6C

Nell'ordine: nome formato, grandezza in settori, settori per traccia, testine (una sola: una vera eccezione), tracce (una in più perché il mio drive, come tutti gli altri, la fa e basta), e il resto dei parametri copiati dai modelli simili (rispettivamente il 720k sul drive da 1.44 e quello 1.44 sull'1.44).

Dunque, arraffato il primo floppino da 720k a portata di mano, e dati i comandi:


setfdprm -p /dev/fd0 faccia0
mformat a:

ottengo un bel dischetto DOS formattato a 359k su 81 tracce, leggibile anche dal drive ufficialmente guasto che una pseudotirchieria informatica mi ha impedito di buttare (e di sprecare). Ma che gli faccio io alle d... disk-drives... ;-)


soundprocessing

Ho provato Sapphire (versione "distribution 15").

Sapphire si propone per il sonoro quello che POVray è per la grafica: dato un file input con dei comandi, produce in output un file sonoro (wav, raw, etc) con i suoni descritti e mixati secondo il linguaggio in input.

Ai bei vecchi tempi, quando campionai la goccia d'acqua per studiarne la forma d'onda, anch'io avevo pensato di scrivere un compilatore simile. Gli avrei dato in input "forma d'onda sinusoidale, ampiezza x, aumento della frequenza x% ogni y secondi, volume variabile, etc, composta con la forma d'onda xyz, etc".

Sapphire fa proprio questo e fa anche alcune cose che io non riuscii a risolvere (per difficoltà o per ignoranza): composizione di più onde, oscillatori, stereo, eventi, ricalcolo delle frequenze, distorsione, filtri e taglio di frequenze, uso di scale diverse da quella standard (che si basa sul "La" a 440 Hz per un'ottava di 12 semitoni), etc.

Ad una primissima occhiata - ho compilato solo i demo - sembra che la sintassi del linguaggetto sia dichiarativa: si definiscono degli oggetti e lui calcola e tira fuori l'output.

Il dimostrativo più grande, che ha richiesto parecchie ore di cpu, è un'intero brano musicale le cui note sono state ricuperate da un file midi (quindi in origine è stato "suonato" su una tastiera), ma i cui strumenti sono stati creati ad hoc.

Così come gli oggetti e le luci di POVray sono assolutamente perfetti, allo stesso modo i suoni prodotti da Sapphire sono di una "purezza" unica: il migliore dei campionamenti non arriva alla perfezione di un'onda sonora disegnata (calcolata) con le funzioni trigonometriche...!

Il discorso è molto ampio. Questo programma va studiato, al pari di POV. E come per POV, i primi risultati possono essere frustranti. L'autore ha cercato di tener tutto semplice e ordinato, ma è uno che di onde sonore ne capisce parecchio.

L'eseguibile è di soli 55k, il sorgente pure è di poche decine di kbytes in C.


Linuxethernetworking su fildiferro (e poi dicono che mi sparo le pose)

Ok, ok, è sabato pomeriggio e sicuramente prima di lunedì non avrei mai trovato un coassiale degno di questo nome.

Però la tentazione era forte. La NE2000 di cui qualche messaggio fa, più una super-anonima scheda di rete del periodo pre-rinascimentale: i "tappi" c'erano, i connettori a T pure... e allora perché aspettare lunedì quando mi avanza mezzo metro di fil di ferro a sezione sottile?

E così ho connesso i due PC in "Ethernet" ma su fil di ferro anziché su etere e... funziona!!!

Sui dischi di boot il telnet non c'era, ma il "mount -t nfs fantozzy:/ /mnt" ha funzionato al primo colpo. Una velocità spaventosa: la 386 sembra uno dei superpentium della megaditta ben frenati dal Winzozz.

DELIRIO!!! =:-)


Una stazione diskless in rete con la vecchia '386.

Ok, la 386 diskless con root su nfs funziona. Ma con ethernet, niente plip. E per giunta senza bootp non ne voleva proprio sapere di partire. Pazienza.

Le schede sulla 386 sono soltanto CGA, NE2000-comp. e hdd/fdd controller, senza hd, ma con un fdd da 1.2 Mb con DOS, LOADLIN e bzImage. L'autoexec.bat lancia LOADLIN con parametri root=/dev/nfs nfsroot=/386/ nfsaddrs=bootp (sarebbe comunque sufficiente un dischetto da 720k per avviare il tutto).

Il root-filesystem della 386 risiede nella dir /386 del mio sistema. Con un po' di hard-links ho risparmiato qualche mega di spazio (i soft-links non vengono seguiti dall'NFS server). In compenso con un po' di mount su nfs gli si possono far vedere tranquillamente le directory /cdrom, /mnt, etc.

I vari telnet, rlogin, finger @host, ping, mount di filesystem remoti, etc, funzionano senza far storie. Non ho provato, ma credo sia possibile montare un filesystem facendogli fare ping-pong sulla rete - cioè dalla 486 chiedo il mount di una dir della 386, la quale è in realtà già montata via nfs dalla 486... per cui monto "me stesso" passando per la 386 :-)

L'ultimo problema è che ancora non ho capito come fargli usare un account diverso da 65534:65535... ma questo lo farò quando avrò meno fame :-)


Gente, ho (ri)scoperto LyX 0.10.3-beta, un front-end per LaTeX.

Chi ha sempre parlato bene di LaTeX, nonché chi non conosce per niente LaTeX, dovrebbe provarlo. Per questi ultimi, LyX appare fin da subito come un word-processor wysiwig con equation-editor.

Mi ha fatto un'ottima impressione perché:

Si possono mettere dentro (inline) anche comandi TeX - per esempio \today, che ora mi restituisce "February 25, 1998" (purtroppo)... dovrò spulciarmi la documentazione di TeX per vedere se c'è un modo per italianizzare la situazione :-)

L'unica cosa che mi manca - sigh e sob! - è il font Galliard, un bel font truetype con cui io scrivo regolarmete tutti i miei documenti. Sono un "galliardista" convinto, non vedo di buon occhio il Times New Roman...

Parentesi: ho scritto un numero allucinante di articoli, tesine, etc, con LyX, e ancora mi chiedono "che font usi?" quando vedono quegli stampati così belli...! LyX e una stampante laser sono un'accoppiata stravincente!


Ah ah!!! Ho provato Luxman 0.41, un clone GNU di Pacman (ma questo Luxman ha, a causa del torbido nome, gli occhiali da sole!!! :-)


Ho sentito che è uscita la Debian 1.3.1 da qualche settimana.

Un SH-64 solleva un container di 10 tonnellate (più del suo stesso peso) L'unica cosa che mi risulta è che Doom per Linux è inserito ancora nella parte degli "unstable"... e non ho capito perché. Sono anni che è stabilissimo. Quake pure c'è, ma Quake II non si vede. Altri giochi "famosi"? Nessuno. Mah... :-(


Mi son deciso a provare xforms perché in LyX ne parlavano bene (e Lyx "è quello che è").

Non sarà della semplicità di otools, ma siamo certamente ad un livello ben superiore delle altre cose strane che ho visto in giro.

Nel pacchetto xforms ci sono, oltre alla libreria e ai demo, anche un form-designer abbastanza completo e maneggevole. È troppo presto per dire qualcosa, però come prima prova - disegnare una finestra con un po' di bottoni, menù e pappardelle varie, ed ottenere in output direttamente il listato in C (compreso il main()) senza scrivere neppure una riga di codice, mi sembra un ottimo risultato...

Purtroppo (o "per fortuna"?) si lavora in C. Non dovrebbe essere una tragedia, visto che LyX è scritto in C++ ed usa comunque xforms; non ho dato un'occhiata ai listati ma comunque

Come al solito i font disponibili sono solo le solite "quattro famiglie" (times, helvetica, courier, charter), e io che ho installato una marea di X-fonts (ma comincio a pensare che il subset standard sia quello che ho appena indicato).

Altro problemino: io lavoro sempre a 1024×768, e xforms (e LyX) usano di default font minuscoli... :-)

Giudizio del sottoscritto: xforms vale proprio la pena di provarlo, se non altro perché il fdesign "è quello che è" (e dovrebbe essere sufficiente a capire che si può insistere su questa strada). Peraltro i dimostrativi a corredo sono semplici ma molto convincenti.


ELKS 0.0.68

Ho la 386/40 con 4 seriali, 3 parallele, 1 fdd 5.25" (1.2Mb), doppio controller hd (ESDI + AT/BUS), soundblaster e NE2000. Guardate cosa esce con le images di ELKS 0.0.68 [images.zip]:


ELKS boot....
Console: direct 80x25 emulating vt52 (3 virtual consoles)
Calibrating delay loop... ok, 7.98 bogomips
PC/AT class machine, 80386 cpu
640k base, 7424k extended
ELKS kernel (64256 text + 9116 data + 50816 bss)
Kernel text at 1002:0000, data at 1fb2:0000
454k of memory for user processes
lp0 at 0x3bc, using polling driver
lp1 at 0x378, using polling driver
lp2 at 0x278, using polling driver
HD driver copyright 1994 Yggdrasil computing, inc.
Extended and modified for Linux 8086 by Alan Cox
DOShd: found 1 floppy drive(s)
DOShd: found 1 hard drive(s)
ELKS version 0.0.68

hd: probing disc /dev/fd0
hd: /dev/fd0 has probably 9 sectors and 40 cylinders
VFS: mounted root (minix filesystem)

Loading init...

Panic: kernel restarted!
Apparent call stack...
[etc etc]

Una piccola riflessione però è d'obbligo.

Vogliono sfruttare i sorgenti di Linux per costruire ELKS. Idea interessante, ma la realtà è durissima: la versione 0.0.68 ha un code-segment quasi pieno (come vedete sopra, avanzano "ben" 1280 bytes di codice e 5604 bytes di dati).

A questo punto si potrebbe fare qualcos'altro, di più intelligente (ma questa è solo una mia opinione e, come tale, tutt'altro che oro colato).

L'idea è questa: definite le specifiche precise di quello che deve fare il sistema operativo, costruire un "kernellino" altamente ottimizzato (anche al parossismo di 50% di C e 50% di ASM) che supporti gran parte delle syscalls di Linux.

In più (e qui viene il bello) il difficile sarebbe costruire un sistema di librerie dinamiche "su misura" per i limiti dei 64k (anche qui un uso massiccio di assembler).

A quel punto il problema sarà solo "comprimere" entro i 64k+64k (code+data/bss) le utilità di sistema. Con uno scriptino awk ho visto che più dell'85% degli eseguibili che ho in /bin /sbin /usr/bin /usr/sbin è più piccolo di 64k... con codice per 486, che occupa pressoché sempre più dell'equivalente 8086 (pensiamo tanto per esempio agli align-16 del primo e gli align-byte del secondo).

Infine, il bello potrebbe venire proprio dai 286, che hanno un protected mode grezzo ma simpatico, su misura per sistemi operativi "protetti"... :-)

[...] Purtroppo, nella foga di riciclare il codice, sono partiti col piede sbagliato: hanno dovuto lavorare sodo per "adattare" i malloppi di Linux al PC-BIOS, etc... dunque, ancora prima di arrivare ad una versione "completa", già si trovano tragicamente a corto di spazio per il kernel (che deve stare in 64k, altrimenti dovranno cominciare a lavorare con i segmenti, e allora con meno di 512k non si ragiona, etc etc...).

Se ci riescono - e la cosa mi sorprenderebbe un po' - si vedrà un PC/XT con 512k lavorare su Internet in tcp/ip, mentre uno o due utenti sono collegati ai terminali seriali... :-)

[...] Giurano che funziona, ma io ancora non sono riuscito a superare almeno il boot su una macchina XT. Dall'emulatore DOS funziona (wow: ELKS/Linux che funziona in una finestra DOSemulata sotto Linux... un Linux emulato in Linux :-)

Cosa ci può funzionare? In teoria qualsiasi programma Unix che, una volta compilato, riesca a stare nei classici 64k+64k (codice+dati) e che non abbia bisogno di diversi mega di memoria (virtuale e reale) per andare avanti.

Si vociferava della possibilità di usare addirittura il gcc 1.40, ma ancora non l'ho visto da nessuna parte. I dischetti rilasciati sono un bootdisk (con i soli 64k del kernel) ed un rootdisk con le utility minimali (vi, rm, cp, la shell, etc).

(Z80?) Portarlo su Z80 è comunque impossibile; bisognerebbe riuscire a far stare il kernel in meno di 16k (lo Z80 più di 64k non vede, ed è esagerato pretendere di usare un kernel di 58k su un sistema con 64k di memoria ;-).

ELKS ha soltanto il filesystem Minix, e quindi vai anche senza hard disk (per lavorare basta un PC/XT con un floppy da 360k!!!). Il filesystem Minix ha la limitazione dei 32Mb (e filenames di 15 caratteri).


Sto provando FreeType 1.0 (la versione finale è di fine gennaio).

Primissima impressione: è stato fatto "a mestiere". Ovvero:

È più veloce di quanto non facciano intendere nella documentazione: da 50 a 200 glyphs/sec (forse non è tantissimo, ma il demo fttimer renderizza nettamente più veloce di quel che ho visto a occhio sotto Winzozz alla stessa risoluzione).

Parentesi: è uscita da tempo la 2.0...


"Bug" di Linux sulla scheda sonora? Macché!

I problemi che abbiamo avuto noi con la Mad16 Pro erano simili: bisognava partire da DOS, inizializzare la scheda col programma in dotazione, e poi avviare Linux.

Però, da quando abbiamo compilato il kernel col supporto diretto della Mad16, tutti i problemi sono spariti.

Per utilizzare la wavetable (non fornita con la Mad16: l'ho comprata a parte) anziché il sintetizzatore FM / Adlib / OPL-4, ho dovuto indicare di usare l'external-midi: funziona ("playmidi -e medleyfu.mid" anziché "playmidi medleyfu.mid").

Se ti sparisce la parallela potrebbe essere a causa dell'uso degli stessi indirizzi da parte della wavetable: ciò mi sembra un po' strano perché per far sparire il problema (ma non necessariamente far funzionare la wavetable) sarebbe sufficiente assegnarle da Bios un address differente (lpt1 anziché lpt2, per esempio).

Quanto al termine "bug di Linux", puoi riferirlo solo alle versioni sperimentali (2.1.xx)... sono quattro anni che uso Linux ed ancora non ho trovato un bug degno di questo nome (in compenso ho trovato il modo di bloccare NT4 dopo i primi 10 minuti che l'ho utilizzato :-)


Per il supporto dei floppy non sono state spese grandissime energie, per ammissione dello stesso Torvalds ("I hate programming floppies").

Se il floppino è buono, tutto bene. Ma se il floppino non è buono, allora sì che è un dramma: nella filosofia Unix si presume *sempre* che i dischi siano molto affidabili... :-)

Il DOSemu protesta un po' meno, potresti usare quello. Quanto al fatto di "sistemare" un floppy DOS, io uso:

dosfsck -t -a -v -V -w /dev/fd0

(per usarlo, il floppy non deve essere "mounted").



 > === /proc/interrupts prima di eseguire Win ===
 >  5:          4   sound blaster
 > === /proc/interrupts dopo l'esecuzione di Win ===
 >  5:          2   sound blaster

Dunque: nel primo caso, senza Win, hai quattro interrupt (IRQ5) dalla SB, nel secondo si "ferma" a due. Il "+" vicino al numero di interrupts mi pare che indichi che l'irq è allocato dinamicamente (quando fai close() sulla periferica, l'irq può essere assegnato a qualche altro driver che ha bisogno dello stesso irq).

> 0378-037f : lp

È vero, 378h sparisce... dunque significa che una volta inizializzata la scheda sonora, questa si "pappa" anche gli address della porta parallela. Hai provato a configurarla come LPT2 (278h) o LPT0 (3BCh)? In questo caso non dovrebbe più sparire...

Non so cosa dirti. Probabilmente non hai una scheda basata sul chipset OPTi originale, ma su un clone (che magari fa qualcosa in più, ma ha bisogno di essere inizializzato).

Due strade:

1) disassemblare il prg di setup della scheda e rifare le stesse operazioni di I/O al boot di Linux :-)

2) aspettare che venga supportata direttamente. Io ho avuto la fortuna di ritrovarmi una Mad16 proprio poco tempo dopo che era supportata direttamente da Linux - prima bisognava comunque far partire il sistema in DOS, inizializzare (SNDINIT.EXE, 450k) e poi avviare Linux (LOADLIN.EXE)...


DESCENT per Linux!!!

Allora... ho compilato e installato la libggi. Richiede una patch al kernel per il KGI (kernel graphics interface): la cosa non è che mi appassioni così tanto, ma ne vale la pena, perché così i programmi non dovranno essere più suid-root per usare la VGA. La libreria si compila con estrema semplicità.

La Parallax ha dato in giro i sorgenti di Descent. Se me lo avessero detto non ci avrei mai creduto. L'autore è partito da quelli per Mac perché più portabili di quelli per DOS.

Il make install fallisce dopo un po' di files (dice che manca un symlink a sound.c), ma rilanciandolo continua correttamente. La cosa capita più di una volta durante la compilazione.

La versione non supporta il sonoro (per ora, spero); in effetti manca la directory "gsi" (una include per le Sun? boh?). Ho creato dei files fittizi (md gsi; touch gsi/gsi.h) per farlo continuare. Tremila errori: si aspetta di trovare GSI_8BIT, GSI_CHANGE_CHANNEL_VOLUME, etc... Ma puerca vaca... ci voleva la libreria GSI... vi rinvio alla prossima volta...


Allora, rieccomi finalmente a smanettare sulla libGGI 0.0.9 (General Graphics Interface). Avevo letto da qualche parte che il passaggio da svgalib a libggi sarebbe stato abbastanza trasparente, e invece... :-(

Primo gravissimo problema: non sono riuscito a vedere neppure il più fetente dei modi grafici, nonostante supportasse la mia gustosa ET4000 (ma anche S3, Matrox, etc) e una carretta di monitor.

Ma ho visto anche altre cose poco carine, per cui è partita subito una mail particolarmente infuocata ad uno dei tedesconi che curano il malloppo (eppure la 0.0.9 era "stable"). Riassumo qui il contenuto:

  1. c'è il soft-cursor... a qualcuno piacerà pure, certo, sarà pure più "VT100", ma io spudoratamente parteggio per l'hardware-cursor, e non ho visto alcuna opzione in configurazione per attivarlo ;-(
  2. non mi carica i textmode fonts... pare sia una missing feature, visto che il programmino "restorepalette" della svgalib funziona benissimo (quindi la libGGI sa che è una VGA).
  3. i vari /dev/vcs* NON funzionano. D'accordo, non è uno standard, ma è davvero molto comodo....
  4. i led della tastiera non funzionano... bug? ;-)
  5. gpm non funziona più, non trova il "selection" nel kernel ;-(

Altre cosacce poco carine:

Dunque, non sono riuscito a vedere né Doom/GGI, né Descent/GGI (ma quest'ultimo mi darà altre grane: evidentemente io non ho i files della versione 1.5, per cui si blocca con un errore all'avvio), né il banale programmino "testpattern"... Ma puerca vaca...


Dopo aver smanettato un po' con la libreria FreeType, sono riuscito a scrivere un po' di testo a video (svgalib) con dei font *.TTF usciti da Winzozz.

L'output è ottimo, sento la mancanza solo del kerning, che nella documentazione vien detto spettare al livello applicativo... :-(

La documentazione è molto ben curata (30k di FAQ e 61k di apiref.txt, tanto per cominciare), ma l'utilizzo è sufficientemente semplice da farmi scrivere il programmino di prova partendo da un esempio senza leggere la documentazione :-)

Con la libreria si "genera" una bitmap banale da interpretare (un bit per pixel) e da mandare sullo schermo o sulla stampante. È previsto anche un byte per pixel, per "ammorbidire" le curve a video con un effetto "grigi".


Sono riuscito a far funzionare qualcosa con la libggi: è bastato (sigh!) sistemare tutto in modo "vga standard" (dal monitor al clock della scheda) e finalmente ho visto qualcosa in grafica (ma non più di 360×480×256).

Dopo aver fatto qualche altro salto mortale con i sorgenti di Descent, sono riuscito a farlo partire in modo 320×200 (anziché 640×480, come insistentemente prentendeva l'autore del porting); purtroppo, avendo i files *.PIG/*.HOG della versione 1.0, mi si è piantato tristemente dopo le prime tre schermate di presentazione.

In compenso ggiDoom funziona... ma solo perché va a 320×200, per cui non ha bisogno né di linear-framebuffer né di page-flipping.

Ho scritto un altro messaggio infuocato al tedescone che curava la ET4000 per dirgli che le sue routines falliscono miseramente su tutta la linea, mentre la gloriosa svgalib 1.2 continua a farmi vedere, con un solo mega di RAM video, 640×480×16M, 800×600×64k e 1024×768×256.

Gli ho detto anche - ma è un sonoro bluff - che a questo punto mi tocca modificarmi da solo i src di Descent per farlo andare sotto svgalib... ;-)


Il mio full-screen editor, superpotente e superveloce con i /dev/vcs*, quando va in modo ansi/vt100 è lentuccio (come del resto le ncurses). Sarà che in giro tutti hanno uno strapentium... oppure usano vi ;-)

Forse è stato proprio l'accanimento ad usare la console come un vt100 a non far migrare a Linux quella marea incredibile di "programmi DOS in modo testo". I "sacri puristi" avrebbero storto il naso, però oggi ci sarebbe una quantità spaventosa di software...

[...]

Ma se la svgalib non viene più aggiornata, "qualcuno" deve pur diventare il nuovo standard. E l'idea della ggi (la vga accessibile senza privilegi da superuser) è superlativa...


Un amico ha insistito per farmi provare la Red Hat 5 uscita da DEV (che lui, del resto, non si è ancora azzardato ad installare). Io, cresciuto nella Slackware, nutro una certa diffidenza in formati diversi dal *.tar.gz ... ;-)

Il CD contiene 226 mega di files *.rpm, e non ho notato nessuna grossa novità - curiosamente, è di novembre scorso, mentre i CD che ho io (il Linux Toolkit della Walnut Creek) sono di marzo '97.

L'unica novità è la libc6 (glibc2 0.5c); tutti i programmi sono compilati in modo da usarla, e dato che non mi fido ad installare librerie e materiale delicato, alcuni programmi presumibilmente succosi (come xgalaga) non ho potuto vederli.


L'emulazione della svgalib è un gioco da ragazzi, deve solo adattare le funzioni. Il codice (che emula libvga e libvgagl) è di una semplicità spaventosa. [...]

Avevo dimenticato di dire che una volta installato il kernel graphics interface, non puoi più usare nulla (né svgalib originale, né Xserver), per cui devi usare il suo xserver :-)

Come ho detto al tedescone (che se ne è lavato prontamente le mani, da buon tedescone), era meglio una printk... se tutti i programmi e le patch al kernel devono fare una presentazione ipergalattica, finiremo come ai vecchi tempi degli autoexec.bat supercaricati di immondizia più o meno inutile... :-)


Se parli bene di ncurses vuol dire che non hai neppure assaggiato /dev/vcs*.

Quanto alla slang (usata peraltro anche dal dosemu), vorrei capire che trucco usa per essere davvero più veloce di ncurses.

Chi ha un DEC VT100 (oltre alla console) mi faccia un fischio ;-)

Mi sto "lavorando" il capo della megaditta per farmi regalare quel vecchio VT100 che hanno nel magazzino attrezzi (funge da raccoglitore di polvere, forse per fini statistici), così mentre mia sorella scrive messaggi (sempre in modo testo), io posso continuare a fare scrivere le mie portentose utilities (che funzionano in modo testo e sulla console vanno a centonovanta :-)

E poi mi avanza sempre una 386 su cui ci girerà Linux...

Sinceramente, Linus dovrebbe trovare un altro modo per usare un qualsiasi device (a partire dalla vga) senza i privilegi del superuser...

Insomma: Linux nasce "text", anzi, "vt100" (o giù di lì), per cui poteva raccogliere l'enorme eredità DOS (il che non è successo), in due modi...

  1. tutti i programmi che pretendono di lavorare come superuser (a questo punto era meglio non lasciarlo, il DOS); oppure:
  2. tutti i programmi per i quali non è strettamente necessaria la grafica (una vera marea) sarebbero passati qui sfruttando almeno multitasking e protezioni - dopotutto il tipico utente Linux ci lavora *da solo* e su un PC non troppo potente... io apro otto console (le altre quattro mi servono per syslogs, programmi miei e schermo locale del prg di BBS)

Ma a parte qualche rara eccezione, non è successo niente di tutto questo :-(.

Linux è "troppo Unix". Se scrivi una stupidaggine "in Unix", ti funziona più e meglio sul Linux a casa che sullo SCO in ufficio. E fin qui non si può lagnare nessuno.

Ma se oltre a questo avesse un minimo di finezze sue, proprietarie, intoccabili (diciamo pure un modo diretto per pilotare tastiera, mouse schermo in modo testo e in modo grafico), tutto quello che c'era in DOS sarebbe passato immediatamente qui.

E sarebbe passato qui col risultato comico di rallentare, almeno da noi, la "foga visuale" degli altri sistemi operativi (la cui avidità rispetto a tutte le risorse cresce in modo inarrestabile).

Mah, sarò anche monotono su questo argomento (e forse non solo su questo), ma resta il fatto che quando la gente vede quello che picchietto sulla tastiera, davanti ad uno schermo per lo più nero e con scritte tra l'incomprensibile e l'apocalittico, non è che dica subito "voglio anch'io Linux".

Un'amica mia viene a casa e mi chiede di scrivere un fax ad una persona di Padova.

Detto fatto: lancio X, lancio LyX, problemino, ps uxa, kill, rilancio LyX, scrivo, faccio processare in DVI per l'anteprima a video (e le scritte nella window in background, che a me sollevano il morale, per lei avevano un'aspetto losco), converto in Postscript, lancio Ghostscript per l'help sui comandi, rilancio Ghostscript, lo blocco perché sta aspettando troppo (perché avevo dimenticato di aggiungere quit.ps come ultimo comando), lancio sendfax per l'help sui comandi, lancio man sendfax perché non capisco se oltre a "-v" mi serve qualcos'altro, lancio finalmente sendfax e... ecco, il fax è arrivato a destinazione e io a video ho scritto un mefitico "echo $?" per avere uno "0" che, con gran sollievo di Cristina, dico significare "tutto OK".

Certo, un programma per mandare i fax avrebbe probabilmente da lavorare in grafica. Ma vuoi mettere quello schifo di programmino dello ZyXEL, scritto non si sa quanti lustri or sono in Turbo Pascal 3.01A (chi lo ricorda? era quello lì che in 39k di .COM aveva editor, compilatore, librerie, linker e perfino overlay/chain manager)?!?!?!

Innervosito dal mefitico vi (che a tutt'oggi continuo ad usare, talvolta facendo finta di chiamarlo "vi" anziché "vu ai", o addirittura "sesta" [numeri romani]), ho scritto un text editor full screen che, come al solito, non ho rilasciato (come pure il programma di BBS).

Sinceramente - se non si fosse ancora capito - io li rimpiango un po', quei tempi... chi è che sfrutta almeno un decimo delle portentose features che si ritrova con il software che ha installato? ;-)

Chi è che con un Linux arcipotenziatissimo riesce ad avere in più del cinque per cento dei casi, giocattolini almeno simili alla marea di shareware e pd circolante in ambiente DOS?


Ieri ho visto che è uscito Linux 2.1.97... ma a che aspettano per cacciar fuori la versione 2.2.0 ? ;-)

Ho sfogliato rapidamente la Slackware 3.4, ma sono rimasto un po' deluso: pare sia tutta roba vecchia... :-(

Del DOSemu vedo in giro ancora la 0.66.7... ma a che aspettano a fare un bel salto di qualità? ;-)

C'è un bel sito dove sono listati i link ad una marea di programmi per Linux, tutta roba buona (e qualche volta anche commerciale), da cui ho pescato diverse cose che domani mi accingo a provare (pertanto, non avendole ancora neppure copiate sull'ardisco, non vi dico neppure che roba è). Il nome del sito? non ricordo...

Ho trovato un clamoroso programma che fa girare sotto Linux e X gli eseguibili del Visual Basic... cercate "VBVM"!!


C'è un clone (piccolo ma simpatico e divertente) di SimCity: è LinCity 1.09, che va sia in SVGA che sotto X. Funziona!!!

Che delizia!!! FORTISSIMO!!!! In soli 440k di .tar.gz... WOW!!!


Ho letto su "CeBIT news" (ma no!) l'intervista ad uno dei capi della SCO. In sintesi:

Linux insomma sarebbe tra due fuochi, SCO e M$...


La naturale evoluzione dei /dev/vcs* sarebbe per l'appunto quella di emulare un xterm in caso di necessità (ma perché le idee più geniali vengono sempre a me?). Infatti ho parlato di /dev/vcs*, non di textscreen memory-mapped (come ai tempi del mitico b800:0000).

Cioè: oltre alla portabilità, anche le features specifiche, con l'unico vincolo di non essere al livello di estrema personalizzazione.

Non le ho provate ancora. E comunque, almeno al momento, la cara vecchia stravecchia svgalib mi fa *tutti* i modi VGA, mentre XF86_SVGA non va oltre i 256 colori.


Linus era troppo "unixaro"... se qualcuno del gruppo iniziale avesse pensato al DOS un po' più tranquillamente della falange macedone che sviluppa il DOSemu, molte cose oggi sarebbero diverse.

In effetti c'è chi ci ha pensato: i vari xwpe, TurboVision per Linux, etc... i soliti tedesconi, più un italiota (incredibile ma vero). Con una certa fatica, però... mentre TurboVision girava assai spedito sui /dev/vcsa*.


LDDK... givin' 95 another kick :)

Ho trovato LDDK 1.0 (Linux Driver Development Kit). Sinceramente, pensavo non valesse neppure la pena di guardarlo. E invece...

Si tratta di un linguaggetto di definizione drivers per Linux. Uno mette un po' di keyword e poi aggiunge le righe in C, solo quelle del corpo vero e proprio del driver.

Esempio:


// costruzione del driver /proc/stupid

module "Procinfo" :
driver "Pmain" [ major=34 ] \{

core \{
       init \{
               printk("This is a real stupid message\\n");
            \}

       cleanup \{
                  printk("Have a nice day! \\n");
               \}
     \}

procinfo \{
            char *p;
            p = buf; /* buf is defined implicitely */
            p += sprintf(p,"Proc entry from %\<driver.name>\\n");
            retval = p - buf;
         \}

open \{
        printk("Stupid module has been opened\\n");
     \}

close \{
        printk("Stupid module has been closed\\n");
      \}
\}

Ora, il punto è questo. Io sto usando, per lavoro, dei tool equivalenti per ambienti orripilanti (NT, 95) che costano diverse centinaia di dollari, hanno chilometri di documentazione e sono molto più complessi.

Questo LDDK, oltre ad essere tremendamente semplice, fa un mucchio di cose molto carine: genera il manuale nei formati man e html, genera il codice (diviso per directory: source, include, doc...), il makefile, etc.

Supporta /proc (da cui leggere), /proc/sys (in cui scriverci pure, per mandare dati al modulo: cat > /proc/sys/driver/turz...), signal (dal modulo nel kernel ad un processo, che delizia!), uso di pezzi della kernel memory da parte di processi (una /dev/kmem personalizzata, insomma).

E così uno scrive core, open, close, read, write, ioctl direttamente, senza preoccuparsi di organizzare codice, files, include, define, etc.

Cercatelo su: http://www.llp.fu-berlin.de


Questo Blatura, oltre ad essere noto per la sua modestia e la sua umiltà, ed il cui dizionario non contiene né la parola "vanità" né i suoi derivati, ha raccolto un bel po' di link a "roba Linux"... vi segnalo una delle pagine, poi scorretevi voi il resto:

http://www.xnet.com/~blatura/linapp5.html

(purtroppo alcuni link sono saltati e lui ancora non si è degnato di aggiornarli... forse, una volta tanto, sarà davanti allo specchio a contemplarsi e ad elogiarsi).

Questo invece pare un gran bel sito che merita certamente una guardatina anche in ora di punta:

http://www.cs.washington.edu/homes/tlau/tome/linux-game.html

I giochi sotto X sono spesso giocattolini simpatici ma ingenui, però se proprio ci tenete, un bel malloppo lo trovate da:

http://www.spinne.com/x/games/

Avevo parlato di esecuzione di programmi Visual Basic sotto Linux, ecco finalmente il nome del sito:

http://softworksltd.com/vbvm.html

temo però che vadano bene solo quelli compilati in p-code, dubito che 300k di beta-test riescano ad emulare anche quelli in codice nativo...


Scusate la sincerità, ma è un'ammuina tremenda emulare il vt100 su uno schermo text-mode "B800:0000" ;-). Eppure nessuno ha mai fatto tante storie.

Abbiamo periferiche sfruttate fino a far friggere i chip sopra, e poi proprio lo schermo deve essere sottosfruttato? La svgalib che non piace ai Sacri Puristi, la ggi che stenta a decollare, Xserver che hanno estremo bisogno di tuning di monitor e tutto il resto (e non di rado danno grane a chi non ha la fortuna di avere una vecchia, stravecchia ma diffusissima e compatibilissima ET4000 come me... ;-).

Se fossi Linux (se vincessi venti miliardi al totocalcio, parola di uno che ha giocato l'ultima volta quando aveva sei anni e solo per far contento il papà) svgatextmode e svgalib li avrei integrati nel kernel da prima di subito... ;-)

Se esiste qualcuno che in ambiente DOS abbia mai usato l'Ansi.sys per far funzionare qualche sorgente "puro unix" che muova un po' il cursore e cambi i colori... (il command.com e il suo prompt non sono ammessi).

I /dev/vcs* potevano essere una sorta di /dev/kmem puntati però solo su quei pochi (4, 8, 16?) kappa di RAM del video. E invece no, sono dei files. Ma io non protesto, perché è più facile fare il port (!), magari su BSD (ma perché non ci pensa mai nessuno?).

Beh, dalla tua faccia direi che non ti ho proprio convinto. Pazienza, riproverò la prossima volta. Intanto mi godo questa svgalib che mi fa anche 640×480×16M, con tanto di programmino scritto da me per vedermi i files *.TGA freschi usciti dal POVray... :-)

Tanto per contraddirmi sempre: è proprio il destino di chi ha hardware nuovo, troppo nuovo, il fatto di avere una miriade di problemi?

Non so perché nessuno ci ha pensato ancora (i commerciali sono stupidi per definizione), ma se accanto al "Windows ready" ci aggiungessero "Linux ready", farebbero un sacco di soldi. Immagina un merlo qualsiasi che, magari a digiuno totale di Linux, vede la scritta "Linux ready". Si gasa e lo compra, dicendo: "così quando butto via Winzozz..." ;-) e si prepara psicologicamente a buttare via Winzozz:-)


Ho rimediato lo StarOffice 4.0 per Linux, quello uscito da IoProgrammo, lancio l'installazione e... zot!

Esce un orribile errore sulla primissima riga del SETUP.INS, trova una "I" e invece si aspettava una keyword (?!?!).

Inutile dire che, anche editando a mano il SETUP.INS ottengo sempre lo stesso errore (si blocca sulla prima lettera alfabetica per dire che cercava una keyword...).

Finalmente leggo il readme e scopro che vuole le libc 5.4.22, mentre io ho le 5.3.12 - a parte questo dettaglio (che in teoria non dovrebbe fare alcuna differenza, visto che il setup parte perché linkato dinamicamente con le libc.so.5) non c'è alcun altro problema.

In ogni caso quest'installazione dello StarOffice è degna di biasimo plurimo, aggravato e continuato. Nonostante sia la versione per Linux, la procedura di setup è "alla Winzozz" (per l'appunto con SETUP.EXE e SETUP.INS), con un mucchio di files con nomi astrusi (F_1922, etc) e filenames quasi tutti "alla DOS" (8+3). Come se non bastasse anche la finestra del programma di setup è "alla Winzozz".

Io non sono affatto entusiasta del look&feel della Motif, ma usarlo addirittura per emulare la "faccia" del Winzozz è proprio un insulto...

Ma guarda che roba: ora mi tocca fare un piccolo ma fastidiosissimo upgrade delle librerie (e io che volevo aspettare Linux 2.2 per passare alla libc6...).

[...]

Sono lieto di contraddirmi - sono pur sempre un essere umano, dotato quindi della naturale virtù dell'incoerenza.

Ho installato manualmente lo StarOffice 4, seguendo alla buona i comandi del file setup.ins, e riuscendolo a farlo partire senza troppe stranezze. Ho scompattato a mano nelle directories dove si aspettava di "trovarsi", ho compilato il file install.ini e i vari .sofficerc, etc... e alla fine è partito.

Innanzitutto la memoria richiesta. Non fa controlli sulla RAM disponibile, ma è assai evidente che con 20Mb RAM (+32 di swap) è inutilizzabile (se non per farci qualche giretto; togliendo i 32 di swap funziona ancora, ma è impossibile anche girarci). A occhio direi che l'ottimale è 64Mb RAM. Con 40Mb si dovrebbe andare comunque abbastanza spediti.

Bene: il pacchetto è veramente ben fatto, e la tanta RAM richiesta, che come già detto viene usata senza troppa parsimonia, è comunque giustificata.

L'eseguibilone gigante, che tira dentro una trentina di librerie (fra cui anche quella dei thread, che ha funzionato egregiamente) è in pratica un enorme browser con annessi wordprocessor, foglio elettronico e formula-editor, presentation, etc, più una sterminata marea di piccole ma utilissime features (una per tutte: la finestrella per i motori di ricerca, con le stringhe già pronte per i vari Altavista, Yahoo, etc).

Per essere più preciso, direi che la StarDivision ha fatto in un solo programma e con diversi mesi di anticipo tutto quello che Winzozz'98 pretende a tutt'oggi di fare: StarOffice si usa come un browser, salva ed importa files da parecchi formati (non ultimi Word ed Excel per '95), lo switching e il drag&drop tra le finestre è più che intuitivo.

Ed ancora: questo è il primo programma davvero bello. Per uno come me, che non ha mai nascosto l'antipatia per la Motif, è stato un vero piacere vedere che può essere sfruttata come si deve. StarOffice arriva lì dove Applixware non aveva neppure immaginato.

Applix nasce da dei "motiffisti convinti", StarOffice nasce da gente che sa che emulare il look&feel di Winzozz può convincere anche i più schizzinosi adoratori della Micro$oft. Infatti questi ultimi saranno i più sorpresi al vedere un mostro simile girare sotto Linux, (e saranno comunque poco sorpresi a sapere che ci vuole parecchia RAM).

Sono bastati 113 mega di spazio su disco per l'installazione completa, compresi fonts e clipart. Peccato che i fonts per X erano solo quelli a 75dpi, per cui sul mio monitor 14" a 1024×768 non si vedessero tanto grandi le scritte dei menù...

StarOffice stampa in formato Postscript; dispone di un po' di fonts postscript, PCL e Type1 (AFM). I font truetype non sembrano supportati, speriamo per la prossima versione.

Non sono riuscito a sfogliare le pagine di help, probabilmente per una delle mie numerose distrazioni causate dalla fretta di vederlo almeno partire.

Conclusione:

Si può usare già da subito (free for non-commercial use), senza la triste malinconia del "è bello, ma aspettiamo la prossima versione".


Ho una libreria mia basata su /dev/vcsa, e in ansi/vt100 puro, e ancora non sono abbastanza contento :-)

La ncurses ha un fetore (*) pauroso: devi essere tu a dirgli quando deve refreshare il video. I nomi delle funzioni sono mefitici. E per giunta, pur di sfruttare certe caratteristiche bieche dei vt100, prevede funzioni orripilanti (**).

(*) traduzione spontanea dell'inglese "feature"

(**) tipo: "aggiungi un carattere in mezzo a due righe che se sono underlined allora devono fare lo scrolling rotatorio in direzione del più vicino angolo comprendente un ACS_VLINE che non sia BOLD"...

Della slang... solo ora sto spacchettando la documentazione, mi hai convinto a darci un'occhiata più approfondita.

> Non si mette qualcosa nel kernel solo perché si pensa che dovrebbe > essere usata da tutti.

Certe cose sul kernel sinceramente ancora non le ho capite. Perché mai, per esempio, i driver per gli scanner sono (forse lo sono ancora oggi) ancora assenti? Perché non c'è un supporto diretto per il mouse?

La tua affermazione dovrebbe essere giustificata da un argomento preciso, che non sia solo la Sacra Purezza Di Unix o le Sacre Opinioni Di Linus in merito ai driver ;-)

Altrimenti dovremmo togliere dal kernel il supporto di tutto l'hardware che non è arcidiffuso in tutto il mondo (e resterebbero a stento il supporto per hard disk ide e porta seriale ;-).

[...]

Ci dev'essere un motivo per cui la gente prima compra delle VGA spaventose e poi sotto Linux le fa funzionare sempre in modo testo ;-) Se dai sorgenti di X si ottengono buone informazioni, perché nessuno le va a riciclare nella svgalib? ;-)

Se scrivere un programmino grafico sotto X fosse facile quanto sotto svgalib, allora dimenticherei svgalib anch'io. Ma se devo tracciare una funzioncina stupida su un diagramma cartesiano, mi costa meno farlo in C sotto svgalib (venti righe al massimo, commenti inclusi) che sotto X...


L'assembler Gnu è stato costruito in funzione delle esigenze del compilatore C, non in funzione del programmatore che vuole usare istruzioni strane e può scrivere codice non troppo corretto... ;-)

Insomma, per certi lavoretti devo ancora lanciare il dosemu (solo per tasm e tlink), e sarei arcicontento ad usare solo Linux senza dover imparare la sintassi Gnu.


GRANDE gioco per Linux!!!

È Battalion. Funziona sotto X e ha bisogno di un PC alquanto veloce (sul mio 486 purtroppo è ingiocabile, va ad uno o due frame al secondo).

È tridimensionale (usa le libMesa 2, peraltro fornite nel pacchetto con gli eseguibili), hanno tutti l'ombra (in modo da capire a che altezza stanno), compresi i proiettili (e quando fa centro, guardate che botto), i "cattivi" sono molto cattivi (nel senso che ti cercano appositamente per spararti addosso) ed anche molto vari (elicotteri con le pale che girano, aerei, carri armati e carri laser, etc), mentre la scenografia è altrettanto curata (strade, palazzi, ciminiere, antenne, etc), e se ci sparate sopra li sfasciate di brutto (antenne che si piegano, parabole e palazzi che esplodono, etc).

Comandi: gira a destra, gira a sinistra, accelera, alza la testa, abbassa la testa (per mirare) e spara.

Giudizio finale: davvero gustoso. Un mega e mezzo di .tar.gz; il sito lo trovate scavando su Blatura (che ho già segnalato qualche giorno fa) o su Linux Game Tome.


Segnalo (con qualche giorno di ritardo) che è uscito ELKS 0.0.70, il "Linux per i PC/XT con un solo drive da 360k".

Gira tranquillamente sotto DOSemu (un Linux nella finestra DOS di Linux!!! questa devo proprio raccontarla agli amici); con 640k RAM totali restano 462k liberi per le applicazioni.

Per provarlo, potete anche pescare il solo file images.zip contenente i tre dischi precompilati (boot/360k, root/360k, comb/720k - comb è un dischetto da 720k con boot e root).

Tali dischi hanno tanto di login shell e tre finestre virtuali (incredibile ma vero: neppure pc-unix e giocattolini simili hanno mai osato tanto), filesystem minix, supporto per diverse periferiche (hard disk XT e IDE, porta parallela, mouse PS/2, seriali, floppy, etc) e sfrutta intelligentemente il BIOS (per esempio: ogni cinque interrupts a 100hz dello scheduler, chiama l'irq0 del BIOS).


Carissimi fantozziani, come ve la passate,

vi scrivo per dirvi che a distanza di pochissimi giorni in cui ho messo il mio address e-mail nel Linux Counter... mi sono arrivate diverse mail indesiderate. Sarà una coincidenza? (devo ammettere che il mio address è anche sul cercapersone di Altavista).

Per esempio: c'è uno che ha un metodo per guadagnare più di 1.454.000 $ nell'arco di sei mesi... e ti vende il metodo a soli 49,95 $ !!! ;-) (e meno male che dice di avere uno yacht da 22 metri, due Ferrari, etc).

Qualcuno di voi sa dirmi se ha avuto la stessa "coincidenza"? L'immissione dei dati nel Linux Counter seguita da mail-immondizia...


Traduco dall'articolo "Windows NT versus Unix", citato anche su Linux Focus (l'articolo è 94k di HTML, ma ci sono parecchi pezzi interessanti... ma se avessi voluto tradurli tutti, non avrei finito più).

Comincio...

Oggi l'affidabilità è spesso più importante della velocità. Questa è in genere quasi totalmente dipendente dall'hardware, per cui la scelta dei sistemi operativi si basa sull'affidabilità, anche se uno dei sistemi offre più funzionalità, scalabilità, facilità di manutenzione, a che serve avere tanti vantaggi quando un server real-time per transazioni finanziarie soffre di frequenti crash e relativi downtimes?

NT è ben rappresentato da un'auto veloce, economica, sprtiva e con un sacco di gadgets... che si guasta proprio nel traffico, costringendo a visitare di frequente il meccanico.

Si parla spesso di NT come "stabile", ma questo non è molto preciso. Se lo fosse, non saremmo qui a leggere articoli come: http://www.zdnet.com/pcweek/opinion/0330/30coff.html "Corporate IT needs an engine that never quits" (P.Coffee, PCWeek 30-3-98)

oppure: http://www.zdnet.com/pcweek/opinion/0413/13coff.html "We do not have a failure to communicate" (Peter Coffee, PC Week 13-4-98)

Quando l'autore di questi articoli ha chiesto "Cosa usi quando non vuoi avere system crash?" è stato bombardato da "almeno il triplo delle normali vigorose risposte via e-mail". Risposte a proposito delle quali dice:

"Non ho avuto neppure un messaggio che dica che NT sia abbastanza buono. Al contrario. Sperano che NT 5 risolva un po' di problemi...

Uno mi dice che sul suo sito un 486 con Linux sta battendo paurosamente un Pentium/200 con NT e per giunta lui ha macchine Linux che stanno girando ininterrottamente da prima che NT4 è stato rilasciato".

In lingua originale: "...Linux on a 486 is outperforming Windows NT on a 200MHz Pentium, and he has Linux machines that have been running without interruption since before Windows NT 4.0 was released".

[...]

Domanda: su quale hardware e software gira il sito www.windows95.com ??! Risposta: Pentium Pro con BSDI Unix più Apache. A febbraio '98 il nome del sito è stato cambiato in winfiles.com.

[...]

Beh, se una ditta è di piccole o medie dimensioni, ha pochi processi da far girare (e che non siano mission-critical), prevede di assumere altri system administrators per Microsoft Exchange e Internet Information Server, ed ha un congruo budget per le licenze Microsoft (organizzate "per server" e "per postazione")... allora non si può che scegliere NT. Ecco un case-study ben fatto sulla migrazione a NT: http://www.aberdeen.com/research/comp/onsite/case1/body.htm

[...]

Per piccole aziende o per chi ha budget ridotti, o anche per utenza affari dal medio al grande e che non hanno la mania della Grande Offerta Commerciale, Linux o FreeBSD tranquillamente eccedono in performance e funzionalità rispetto a NT, che ciò avvenga con hardware Intel-based o meno. Il tutto ad un prezzo di $0.00, un prezzo che Bill Gates non riuscirà a battere facilmente.

Perché investire in un sistema operativo che richiede costosi training e re-training per ogni nuova release di NT? I system administrators di Unix e Linux sono tecnicamente più capaci e sanno risolvere più problemi di quelli per NT...

Perché spendere quasi $5000 per MS Exchange Server (prezzo per soli 50 client) che sembra in fin dei conti buono solo per maneggiare la posta di poche centinaia di dipendenti quando potete usare il Sendmail che viene con le distribuzioni Linux, tecnicamente assai più capace rispetto a NT e tranquillamente pronto per le richieste di migliaia di impiegati?

Unix offre tutto. Perfino un ottimo disk usage (diversamente da NT), e non può essere crashato da un virus scritto 10 anni fa in ambiente DOS.

Ma la cosa più importante è questa: Unix è buono per qualunque hardware, qualunque CLI o GUI, commerciale o GNU, si può scegliere tra diversi concorrenti, si può customizzare dinamicamente... NT va solo su Intel o Alpha, niente CLI - solo GUI (provate a partire con NT in modo CLI-only), e per giunta una sola GUI (non si possono scegliere altri windowing systems come invece avviene per X), solo software commerciali e per giunta solo prodotti Microsoft (avete mai sentito di qualche "NT Server clone"?), etc.

[...]

I maggiori Information Technology mangers notano il web-server dipartimentale sta girando da un anno, un anno e mezzo, sotto... Linux.

La reazione normale: upgrade a NT. Ma subito dopo tornano a Linux a causa della caduta netta delle performance...

Alla Cisco Systems i capi hanno deciso di passare a NT. Gli administrators stanno tentando disperatamente di far girare NT (tenendo su, nel frattempo, ancora gli intramontabili sistemi con Linux) pur di non scontrarsi con i capi e dimostrare l'incauto acquisto... Se sei un manager, considera seriamente queste informazioni. Chiedi ai tuoi tecnici "cos'è" che va. Non farti imbrogliare dai rivenditori e dai loro paroloni

[...]

Linux e NT4.

NT è scelto spesso come "cost-effective hardware solution". Confrontiamolo con Linux e vediamo quanto è vero sulle feature di entrambi tralasciando ciò che non è fornito di serie (come Perl 5, che la MS non distribuisce).


Componente              Linux                   Windows NT 4.0

sistema operativo       gratis, o 49.95$        $809 (5 users),
                        per una distribuzione   $1129 (10 users),
                        su CD-ROM               $3999 (25 users Ent. Edition)

free tech   http://www.linux.org/help/howto.html   no
  support   http://www.redhat.com

kernel source           yes                     no

web server              Apache                  IIS
ftp server              yes                     yes
telnet server           yes                     no
SMTP/POP3 Server        yes                     no
DNS                     yes                     yes
network file systems    NFS e SMB               solo SMB
news server             yes                     no

remote window server    X                       nessuno
remote management       tutti i tools           solo User Manager For Domains
                                                e Server Manager

C, C++, Perl 5, RCS     yes                     no

filesystems supportati  ben 32, +diskquota      solo 3, senza diskquota
[...]

Il servizio postale americano ha usato nel 1997 oltre 900 sistemi Linux per il riconoscimento del destinatario sulla posta. Ogni sistema consiste di cinque Dual Pentium Pro 200 MHz più una macchina con un PPro200, tutti che girano sotto Linux. http://members.aa.net/~jtaves/linux.htm

[...]

Aziende che usano Linux: (cfr. http://www.m-tech.ab.ca/linux-biz/) Cisco, Sony, Mercedes, Yellow Cab Service California...


A Roma ho visto l'altro ieri sera, in una libreria Mondadori, il pacco da 6 CD Linux a 61mila lire. Solo che non si capiva la data di uscita...

Intanto ci tocca aspettare una 2.2 stabile, quindi qualche altro mese; non vale la pena aggiornare tutto "a puntate".

Sono indeciso sulla Slackware. Ho letto diverse cose interessanti sulla Red Hat (che del resto è anche quella commercialmente più elegante, qualora quelli della megaditta si arrendessero), ma continuo a pensare (erroneamente?) che la Debian sia migliore...

Insomma: nel dubbio, aspettiamo. Tanto qui va tutto bene, anzi, c'è gente che tiene su dei sistemi Linux 1.2.x perché non vuole fare un reboot... :-)

Vedo che il kernel della 2.1.102 è di quasi dodici mega di .tgz...!


E poi dicono che io continuo imperterrito a parlar bene di Linux

Sono gasato come una Perrier: ho appena riciclato codice Turbo C, nella fattispecie un mio programma per la stampante che ho scritto il 19 gennaio 1991 (addirittura PRIMA di aprire la mia portentosa BBS), e che ha funzionato al primo colpo - ho editato il listato solo per aggiungere nel commento iniziale "portato a Linux addì 26 maggio 1998" :-)

Sono tentato di fondare il primo LUG (Linux User Group) della mia città, composto dal sottoscritto e - per chissà quant'altro tempo - da nessun altro :-) :-)


Prestazioni del trasferimento dati sulla porta parallela

Le prestazioni che ho registrato, almeno per ora, sono:

- Winzozz '95 "Connessione diretta via cavo": 20-30 kb/sec

- driver plip di Linux: 32-40 kb/sec

- interlnk/intersvr del DOS 6: "Turbo" a 50-60 kb/sec, "Normale" a 20-30 kb/sec


E poi dicono che io ANCHE IN UFFICIO parlo bene di Linux...

Caso 1: le schede di rete.

Inutile dire che Winzozz non è mai (dico: MAI!!!) riuscito a riconoscere correttamente una delle nostre numerose NE2000-compatibili. È vero: qualcuna è PCI, qualcun altra è ISA, qualcuna è Plug&play, una è jumperless, altre sono con i ponticelli. Ho detto "Winzozz", e intendo diverse versioni di W95 (da quella "pura" del remoto 1995 all'ultima pluri-patchata del maggio 1997 "con funzionalità aggiuntive USB"), idem con patate per Winzozz 'NT (con e senza Service Pack 2; il 3 non ce l'abbiamo).

Linux le ha riconosciute TUTTE, sempre e SUBITO, senza eccezioni!!! I miei due floppini (boot e root) hanno, da gennaio ad oggi, fatto la parte del leone tutte le volte che si trattava di trapiantare hardware. Per non parlare dell'introvabile WINIPCFG, quel programmino che dice l'identificativo hardware (quello di 6 bytes) della scheda. Bastava il disco di boot di Linux, molto più rapido di una estenuante ricerca nei meandri dell'ardisco di ogni macchina.

Caso 2: l'effedisco.

Metti il caso che uno trapianti l'ardisco da una macchina all'altra, e che l'altra è un 486 di quelli da 7.94 BOGOmips (un 486/120 veloce quanto la mia vecchia intramontabile 386/40!!!) con WINbios e SENZA supporto per LBA e affini. Sono falliti, nell'ordine: fdisk del DOS 6, fdisk allegato al W95, fdisk di serie del Winzozz NT.

Insomma: su quel 486 diseredato dovevano esserci 500 Mb per W95 e un giga per NT4. E l'effedisco di NT4 diceva invece che c'erano 500 mega per W95 e 4 mega per NT...

Lancio il solito boot di Linux, creo la seconda (e la terza) partizione e rilancio il setup di Winzozz NT. Funziona. NT si accorge che la "sua" partizione è di un giga (fino alla traccia tremila dell'ardisco) e riesce clamorosamente a lavorare. Anche stavolta Micro$oft ringrazia Linux.

Nell'ultima partizione (dal cilindro 3001 al cilindro 3305, 150 mega circa) installo un Linux supercompleto: dovevo pur premiarmi per essere riuscito a sbrogliare un problemuccio non da poco (se non andava, mi avrebbero fatto smontare e rimontare almeno un altro paio di PC).

Dopo il DANNO, le BEFFE:

Non è finita: spengo, riaccendo, "NTDETECT 4.0, Checking hardware...": zot! Schermo nero per parecchi (parecchi) secondi. Alla fine lo lascio fare e, incredibilmente, si riprende. Altro che Linux, dove vedi tutto quello che sta succedendo.

Qualcuno pensa che Linux è complesso. Infatti editando una dozzina di files di testo (httpd.conf, /etc/hosts, /etc/rc.d/rc.inet1, ...) uno allestisce un intero sito Internet. Qui in ufficio, per tener su un PC in una peer-to-peer (workgroup) devo cliccare qui e là per parecchi minuti, nelle finestre più strane (altro che un filo logico), e se anziché W95 è un NT allora devo prevedere il triplo del tempo.

Sotto W95 e NT4 non si capisce MAI "perché la rete non funziona". Sotto Linux basta dare un'occhiata in giro: cat /proc/interrupts, e vediamo se si muovono i pacchetti; dmesg, e vediamo se la rete è riconosciuta; route, e vediamo dove devono transitare i pacchetti, etc.

Non basta: se uno sbaglia l'IRQ della NE2000 sotto Win, sembra che funzioni tutto (con la differenza che in "Risorse di rete" uno vede solo sé stesso, se non sono nati altri problemi nel frattempo). Seguendo le ridicole spiegazioni dell'help di Winzozz ("Risoluzione dei problemi", un titolo falsissimo), si arriva nel 99% dei casi alla mefitica "Controllare l'installazione della rete", cioè non capisci mai se è un cavo spezzato o un IRQ sbagliato o un driver "sporcato".

Lo stesso discorso vale per un cumulo di altre periferiche. Per esempio le porte seriali. Non sai mai cos'è configurato, altro che i dettagli fino alla paranoia durante il boot di Linux. Anzi: il solo disco di boot di Linux mi ha dato più informazioni utili (utili sul campo, da subito!) di qualsiasi altro programma di diagnostica per DOS e/o Winzozz.

E che dire del fatto che devi fare il reboot ogni volta che cambi qualcosa? Sembrerebbe normale, se non fosse che se fai due modifiche di un certo peso, una delle due si perde nel vuoto. Ma a confronto con Linux (dove al volo puoi fare rmmod e poi insmod con argomento irq=5, per esempio) viene come minimo da piangere (per chi Winzozz è costretto ad USARLO ed a farlo funzionare!!!).

Insomma: quando scrivono codice per Linux, sarà pure che spesso riciclano altro codice, ma prima di rilasciarlo lo fanno funzionare, cioè fanno esattamente quello che c'è scritto nelle specifiche dell'hardware, fanno esattamente quello che hanno previsto. C'è in giro un mucchio di codice mal fatto, sì, ma il kernellone di Linux è un muro d'acciaio. Altro che Winzozz, dove l'unica cosa che conta è l'apparenza, dove se uno ha un problema gli si dice di fare un upgrade dell'hardware (e del software), dove non si capisce più qual è il codice originale e dove comincia lo strato delle "pezze" e delle correzioni.

Ok, ok. Il collega di lavoro pure apprezzerebbe Linux (ma gli interessa almeno quanto a me interessa l'ippica). Ma se dopo queste dimostrazioni (buona parte delle quali avvenute sotto i suoi occhi) pensa ancora che Linux sia robetta per ragazzi... allora Linux è condannato: sarà pure un ghepardo inferocito (contro il vecchio elefante malato Micro$oft), ma non potrà mai vincere i pregiudizi.

Della serie: uno guarda la pubblicità, il paccone colorato, il discorsone del rivenditore, e poi vien da te a fare la faccia di chi ha capito tutto della vita.

Qualora ci fosse in futuro davvero bisogno di un server qui in ufficio (non un server "per bellezza", un server che non serve a niente), mi farò vedere in giro dai colleghi con i dischi di NT, ma installerò Linux senza dir loro nulla. Vedremo la faccia di questo "esperto di cose della vita" quando la rete funzionerà dal primo momento e non cadrà nemmeno a spingerla (si fa per dire: dopotutto sono dei sistemi Winzozz...).


Ho provato GPG e ho letto qualcosa della sua documentazione.

In breve:

Il PGP era bello e distribuito in sorgente, ma ad ogni release cambiava l'algoritmo... insomma, c'era un po' di caos. Questo, pensato proprio per la licenza GNU, dovrebbe "correggere" proprio quei problemi del PGP.

Ora il punto è: quanto è sicuro questo rispetto agli altri?

Se l'algoritmo è un'implementazione "tipo RSA", in teoria è pressoché inattaccabile. Il grossissimo vantaggio dell'RSA è che aumentando la potenza dei computer (e quindi aumentando il "rischio" che qualcuno scopra una chiave con attacco sistematico), si può aumentare ancora di più la grandezza della chiave. Se aggiungo un solo bit alla chiave, il numero di tentativi necessari raddoppia... (mi sono espresso in maniera brutale; su www.rsa.com è possibile prelevare il file delle FAQ di RSA, 860k di .PDF, che spiega molto più in dettaglio questi particolari).

Insomma: l'algoritmo potrebbe essere indistruttibile ma potrebbe contenere punti deboli (magari imprevisti dagli stessi progettisti). In termini di crittografia si parla spesso di casi (senza nome, purtroppo) in cui un potentissimo algoritmo di crittografia sviluppato "ad hoc" e dichiarato inattaccabile, conteneva poi delle debolezze stupide.

Da questo punto di vista RSA è avvantaggiato perché è una ventina d'anni che cercano di attaccarlo (nb: sapevate che il brevetto su RSA scade il 20 settembre del 2000?).

Morale della favola: aspettiamo ancora un po' e poi ne riparliamo. Quando anche gpg avrà il suo nome e il suo blasone internazionale allora potremo dormire tranquilli.

In realtà, dato che le mie (e probabilmente anche le vostre) esigenze di crittografia sono limitate a qualche scambio messaggi tra amici in rete, dubito che ci si impelaghi in una paranoia da "big brother is watching YOU"...!


Ah ah! Ma è proprio 'na pacchia 'sto PLIP... "non si capisce niente" (si fa per dire): finger, talk, mount, ping (insomma, tutto quello che va in tcp/ip, cioè tutto! non ho provato, ma credo di poter tranquillamente aprire una sessione X via porta parallela)... e, con una cp di diversi mega, si vede ogni tanto qualche "attimo di pausa" (molto breve).

Altro che la "connessione via cavo" del Winzozz, che non solo va più lentamente, ma quando chiedi una copia... il sistema "si siede", fino a copia avvenuta. Per non parlare dell'handshaking: immediato in Linux, parecchi (parecchi!) secondi con Winzozz. E non è tutto: da Winzozz non funziona in bidirezionale (sempre il vecchio schema client/server, dove il server non può fare nient'altro che abbattere la connessione) e per giunta bisogna dirgli pure il nome del computer remoto, infatti usa due protocolli (ipx e netbeui)... 'na tragedia!

Dimenticavo: si possono mettere in piedi tutte contemporaneamente (la scheda di rete, la parallela con plip, la seriale con ppp...), mentre su winzozz non sono ancora riuscito (sarò stupido io o più probabilmente stupido winzozz) a chiamare Intrunat mentre quella "granda fetenzia" di "connessione via cavo" sta girando (indipendentemente dal fatto che ci sia davvero qualcuno acceso dall'altra parte del cavo!).


Una "rete" di due PC ha collegamenti banali:


*--+---------------+--*
   PC             PC

dove "*" è il "tappo" da 50 ohm, "---" è il cavo coassiale e "+" è il connettore a forma di "T". Al posto del coassiale io ho usato del fil di ferro (!!!) ed è andato bene lo stesso (l'importante infatti sono i "tappi": senza quelli non funzionerà mai nulla). I due fili del fil di ferro sono "paralleli" (il pin al centro del T di una va col pin al centro dell'altro T; quello "massa" del T di una va col "massa" dell'altro T).

Il problema che riporti è curioso. Linux, con la dozzina abbondante di schede ne2000-compatibili che gli ho fatto vedere (in ufficio e a casa) ha sempre azzeccato subito la configurazione - base address (quasi sempre 300h, per la PCI è in genere da 6000h in su) ed interrupt (5, 9, 10, 11, 12: ne ho viste di tutti i colori, e forse faresti bene a provarli tutti se non ne sei assolutamente sicuro).

Le routing tables sembrano sistemate correttamente. Quanto ai led della scheda, devo tristemente ammettere che mi hanno sempre ingannato: non si capisce mai se ti stanno indicando che va tutto bene o va tutto male :-) Il fatto che lampeggino significa che hai azzeccato almeno l'address della scheda.

Sotto Winzozz, quando sbagli a settare l'interrupt (alla faccia del plug&pray, mentre Linux mi ha sempre aiutato), sembri essere solo sulla rete (cioè "crede" di trasmettere, ma non arrivano mai pacchetti).

Consiglio finale: pare (PARE!) che se il supporto per la ethernet è caricato come modulo, pare che ci siano problemi. Non ho fatto prove intensive, ho sempre avuto il supporto per la ne2000 compilato nel kernel.

p.s.: quando ne vedrai le prestazioni smetterai di chiamarla "mini" lan :-)


La mia stima per il PGP è da tempo in discesa. Non ho mai apprezzato troppo il fatto che dalla 1.0 alla 2.6.2i ci siano stati tanti cambiamenti (chiamali "cambiamenti", chiamali "problemi", fatto sta che uno non può stare ad inseguire tutte le magagne di ogni versione ogni volta).

E poi gpg è gnu, quindi posso tranquillamente dimenticare il pgp...

RSA è protetto da copyright fino a settembre 2000. IDEA è protetto da brevetto internazionale, mi pare.

Quanto al discorso "sicurezza"... andremmo a finire chissà dove. Il problema su cui dobbiamo porre l'attenzione è: gpg implementa *perfettamente* il Diffie-Hellman? PGP lo fa? etc.

Vedo però più consistente una distribuzione Linux con gpg a bordo che una caotica distribuzione in cui è schiaffato dentro un pgp in omaggio all'abilità (programmatoria e legale) di chi l'acquista ;-)

[...]

O si tratta di una coincidenza estrema, oppure è vero che tutti coloro che vogliono fare crittografia a chiave pubblica a livello commerciale (e-commerce, firma elettronica a livello legale, privacy, autenticazione, etc) parlano sempre di RSA.

[...] Potrei confondermi. Ma mi chiedo (sapendo già qual è la risposta): è meglio un sorgente RSA della stessa RSA (non esportabile e blah blah blah), meglio un PGP cambiato 19 volte in pochissimi anni, o meglio un gpg in fase di sviluppo?

Per me, da casa mia, parteggio (senza eccessivo fondamentalismo) per gpg, per un buon numero di buone ragioni.

Ma finora in ambiente di lavoro sento sempre la stessa parola, "erre esse a, mille venti quattro bit". Vogliono l'RSA perfino per crittografie stupide (quelle dove se fai uno "XOR 0xff" su ogni byte puoi dormir tranquillo per i prossimi trent'anni).


Ho provato stamattina (cioè 16 ore fa) il kernel di Linux 2.1.108, uscito il 2 luglio - e da allora ancora non c'erano più novità.

Una sola parola, anche se usurata: MOSTRUOSO.

Undici mega e mezzo di .tgz, perché dentro c'era anche il malloppo per Mac, Sparc, Amiga, etc (comprese periferiche!).

Novità abbastanza marcate a tutti i livelli, ho sonno e quindi rinvio ad altro messaggio i commenti.

Piuttosto, a confronto con la 2.0.32 che ancora uso tutti i giorni, sembra un po' più aggressivo col disco (ma non so ancora dire se corrisponde ad un guadagno di velocità o meno).

Bruttura: non c'è più lo shift-pageup/shift-pagedown per scorrere i virtual-screen... per giunta (ma questo è un bug mio, per fortuna) il mio full-screen text-editor non riusciva a scrivere sui /dev/vcsa*.

Una marea di periferiche in più, ma ancora non riconosce qualche device PCI (questa è la volta buona che gli mando una mail) e (questo sembra un problema mio) OSS-free non riconosceva la più nota scheda sonora (stando a quel che vedo in giro), cioè la ESS1868 con Yamaha OPL3-SAx.

Features a non finire sì, ma alcuni pezzi di codice sono proprio dei tempi di Pappagone. Come ad esempio la plip, ancora a 4 bit :-( anche se è documentato il "mode 1" a 8 bit...

[...]

Avevo detto "aggressivo" ma non avevo specificato in che termini.

Ho provato la 2.1.108 su una macchina con 48Mb RAM e senza una swap area, e la prima impressione (rispetto alla 2.0.30 di pochi istanti prima) era proprio che "macinasse" di più l'hard disk, cioè che riuscisse a leggere e scrivere più settori nello stesso tempo. L'esatto contrario di Winzozz, dove il numero di "grattate" per secondo è sempre lo stesso, per cui si può solo... rallentare ;-)


Mostruoso: un emulatore PC che NON esegue le istruzioni macchina in modo virtual 8086... ma le emula. Per cui non ha bisogno di un processore 80x86.

Dunque sotto questo Bochs ci girano DOS, Linux, Windows 95, etc, e tra poco perfino Windows NT.

Bochs è scritto in C++. Non ho fatto ancora neppure una prova, ma sfogliando i sorgenti posso dire che è una genialata di prima categoria, e non mi meraviglierò quando "sorpasserà" il DOSemu ;-) [sorpasso imminente!].

Purtroppo Bochs NON è in licenza gnu ;-(


Ho convinto quelli della megaditta a installarmi un PC con Linux acceso 24h/24, con tanto di modem USR Sportster Flash e linea telefonica sua (non usata per altri scopi). Questo per motivi di "telelavoro" perché sarò a Roma solo per qualche altra settimana.

Se prevarranno i "contrari", il PC sarà un (puzzo)lentissimo 486 con 16Mb RAM, hard disk da 1,7Gb, scheda di rete NE2000 su ISA e uno scassatissimo CD 8X che non di rado si rifiuta di aprire il cassetto per sputar fuori il ciddiromm...

Se prevarranno i "favorevoli", il PC sarà da usare come server e sulla rete locale si ballerà un po' di SAMBA ;-). In questo caso avrei un P100 con 64Mb RAM, due hard disk identici da 1.7Gb, scheda di rete NE2000 su PCI, un CD 8X abbastanza rodato.


La storia di PGP non è molto carina...

In ambiente commerciale conoscono tutti RSA (e RSA soltanto). Curioso il fatto che nonostante la mai sufficientemente chiara legislazione americanoide, lo vogliano tutti.

Esempio: degli apparecchietti (iButton) Dallas, esportabili in Italia, con RSA a bordo (ed anche con chiavi a più di 512 bit).

Vorrei sapere questi esperti crittografi perché non si sono mai lagnati per il fatto che PGP ha cambiato schema, chiavi e tutto praticamente ad ogni versione, costringendoli ad un lavoro immane ;-)

Per cui, in attesa di una gpg più che stabile e più che analizzata, scarterei comunque lo "standardissimo" PGP perché nel mondo del lavoro è considerato poco più che una curiosità (non dai miei colleghi ma dai più grossi clienti), e prima o poi, se gpg non affonderà, sarà reso inutile da gpg.


Volevo segnalare che il numero di luglio/agosto di DEV contiene un bel po' di materiale fresco per Linux (anche se ci sono diversi "doppioni")... l'unica seccatura è che i files sul CD sono tutti in formato RPM.

Con questo rpm2tgz sono riuscito a evitare di dover installargli tutti i pacchetti "required" (che in un modo o nell'altro già avevo).


Ordunque: il portatile Acer / Texas Instruments "Extensa 355" ha un LCD DSTN 800×600 che sotto Winzozz funziona a 800×600×256 (bleah) nonostante la SVGA a bordo (una Chips & Tech CT65550) abbia un mega di memoria.

Infatti, come già vi dissi, l'XF86_SVGA va tranquillamente a 800×600×64k.


Un po' di statistiche (dischi ed interrupts) di qualche annetto fa
Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/hda3             958117  940998     7407     99%   /
/dev/hda2             648467  550299    98168     85%   /root
/dev/hda4             834879  775006    51411     94%   /home
/dev/hdb1             528933  528318      615    100%   /files
magma:/               648543  522893   125650     81%   /mnt
/dev/hdc              666008  666008        0    100%   /cdrom
magma:/dos           1455296 1099456   355840     76%   /dos

 0:  232215768   timer
 1:    1623234   keyboard
 2:          0   cascade
 3:     536170 + serial
 4:     140984 + serial
 6:        193   floppy
 7:     957657   plip1
 8:          0 + rtc
 9:          0   uart401
11:    1824653   adc1848
13:          0   math error
14:    2060611 + ide0
15:    4126314 + ide1


Oops, errore di sbaglio, intendevo "porte parallele" ma pensavo già ad altro :-)

Con la nuova gestione delle parallele (2.1.108 e successive, almeno quelle che ho provato io) chiama "plip0" la prima porta che trova...

Il "losco" di cui parlavo era il sospetto (ancora non verificato) che la gestione della parallela sia un po' troppo "sui generis", e che i timeout suggeriti con plipconfig siano un po' strettini.

Il frequente errore di timeout è dovuto al fatto che basta un quarto di millivolt a scatenare un interrupt che il driver plip prende subito sul serio. Infatti, a cavo staccato, non si verificano (almeno sul mio 486) errori di timeout. Se invece il cavo è attaccato ad entrambi i PC ma uno dei due è spento, quello acceso proverà più o meno frequentemente a solleticare quello spento... credo però che si tratti di un problema software (qualcuno dei vari mountd nfsd tcpd etc che carico al boot).


La scomparsa delle BBS non verrà decelerata da una maggiore configurabilità di un programma... :-( e per giunta Linux potrebbe aver già "saturato" :-( se qualcuno ora pensa ad installarlo, è solo "perché lì il Netscape va più veloce", non perché è definitivamente più affidabile di chiunque altro.

Piuttosto, potrebbe reggere in piedi la posta elettronica (mi ripeto, lo so, mi ripeto sempre), quella che in pochi kappa ti porta una marea di novità.


Ho avuto in omaggio una brillantissima VGA PCI S3 Virge/DX (chipset 86c375) con 2Mb RAM, che tragicamente la svgalib 1.2.13 mi riconosce come una S3 Trio64 2Mb e non va a più di 800×600 :-(

In compenso vedo gli 800×600×16M, che goduria!!!

/usr/lib/svgalib/speedtest oscilla, a seconda dei modi video, tra i 14500 kb/sec e i 22200 kb/sec, niente male per un '486.

Il CD a corredo della scheda ha driver per le cose più astruse (W31, OS2, W95, WNT) ma naturalmente ignora l'esistenza di Linux ;-)


Altro: la Redhat6 ha le sue diecimila pecche, ma mi sembra che troppo malvagia non sia. O forse è perché ho ricompilato Linux 2.2.5 sul 486, e stravedo tutto? (seriali, plip, ax25, ne2000pci, bt848/video4linux, due fdd, due hdd, un cd 4-disk, etc). O forse perché vedo che con Linux questo 486 ha ripreso a volare? (mentre con W95 è di una lentezza da record mondiale).


Clamoroso: il Midnight commander per Linux dispone perfino di un comando "Undelete files (ext2fs only)" che... funziona! Devi solo reinventarti il nome. Visto che sono files quasi tutti ascii, è una vera manna!!!


Un amico sta facendo i salti di gioia per aver rimesso in piedi una vecchia 386 che, con quel Linux sopra, va di una ferocia inaudita :-)

Intanto altri mi telefonano per dirmi delle loro intenzioni di comprare dei superpentiummoni a prezzi da capogiro :-) L'unico buon motivo per comprare bestioni simili è l'emulatore di PlayStation (ma ci vuole almeno un P200MMX e una VooDoo2 con 16Mb) per farsi qualche gustosa partitina a Gran Turismo... :-)


RedHat 6

Non è affatto malvagia, e sono riuscito ad installare tutto già al secondo tentativo - il primo è fallito perché, partendo da DOS, si rifiuta di proseguire qualora non vuoi la swap partition; partendo da floppino e chiedendo il modo "expert" ha avvisato che non c'è la swap ma ha proseguito normalmente.

Gnome è molto interessante, specie a 800×600×64k (ho riciclato il vecchio XF86Config perché XConfigurator vedeva solo 640×480×256) e tutto il resto pure fa un bel figurone.

Ma la cosa che più mi ha tolto il sonno è il mare di features che ha in più la versione 2.2 di Linux...


Mi son fatto una copia di un intero hard disk su un file ("dd if=/dev/hdc of=/tmp/disk") e poi ho "montato" il file ("mount -t msdos /tmp/disk /mnt -o loop=/dev/loop3,offset=31744"; l'offset serve a dirgli di scansarsi i settori della partition table). WOW!!!


Vi prego, vi prego! Cliccate sugli sponsor qui sotto, perché solo così mi vien voglia di aggiornare questo pregevolissimo sito con pagine molto più serie di questa (per esempio quella sulle fotocamere digitali o quella su Flannery O'Connor).

Click here for index page.

home page - send e-mail