    *****   Vol.  1   *****      Pag.  1      *****   Numero  12   *****

    ====================================================================

    @@@@@@ @@@@@ @@    @@@@@ @@   @@   @@  @@@@@@ @@  @@@@ @@  @@  @@@@
      @@   @@    @@    @@    @@@@@@@  @@@@   @@   @@ @@    @@  @@ @@
      @@   @@@   @@    @@@   @@ @ @@ @@  @@  @@   @@ @@    @@  @@  @@@
      @@   @@    @@    @@    @@   @@ @@@@@@  @@   @@ @@    @@  @@    @@
      @@   @@@@@ @@@@@ @@@@@ @@   @@ @@  @@  @@   @@  @@@@  @@@@  @@@@

    ====================================================================

                                 Dicembre 1991

    ====================================================================

      Bollettino telematico mensile a cura del network 2:334 - Fidonet 

                 Editor natalitius:     Maurizio Codogno
                 Editor accountista:    Alfredo Berlusconi
                 Editor dimissionarius: Roberto Piola
                 Editor finestrator:    Renato Rolando
                 Editor coordinator:    Franco Carcillo
                 Editor programmator:   Marco Russo
                 Editor auscultator:    Lorenzo Travaglio     
                 Collaboratori:         Tutti voi :-)

    --------------------------------------------------------------------

                            IN   QUESTO   NUMERO :

    Editoriale, di Maurizio Codogno   .   .   .   .   .   .   .  pag.  2
    La programmazione Event-Driven, di Marco Russo    .   .   .  pag.  3
    Fusione, di Roberto Piola .   .   .   .   .   .   .   .   .  pag.  7
    Itapac - parti 8 e 9, di Alfredo Berlusconi   .   .   .   .  pag.  8
    BBS e Radioascolto, di Lorenzo Travaglio  .   .   .   .   .  pag. 11
    Vivamiga, di Renato Rolando   .   .   .   .   .   .   .   .  pag. 13
    Curiosita`: Il gergo hacker - parte 9 .   .   .   .   .   .  pag. 15
    Notizie Fidonet, di Franco Carcillo   .   .   .   .   .   .  pag. 18
    Notizie dal net 334   .   .   .   .   .   .   .   .   .   .  pag. 20
    I nostri bbs  .   .   .   .   .   .   .   .   .   .   .   .  pag. 21

    ====================================================================

         Il materiale presente in Telematicus e` (C) dei singoli autori.
    E` espressamente  consentita  la  distribuzione  e il riutilizzo del
    bollettino  in  tutto  o in  parte,  purche` non  a fini di  lucro e
    citando sempre la fonte di provenienza. 

    *****   Vol.  1   *****      Pag.  2      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................


                                                       -----> EDITORIALE 
                                                              ==========

         Carissimi lettori,
    A  parte i soliti auguri di Buone Feste che sentirete poi da  troppa 
    gente perche` valga la pena di spendervi piu` di due parole,  vorrei 
    farvi  notare  che  questo  e`  l'ultimo  numero  del  volume  1  di 
    Telematicus. A gennaio, se ne avro` il tempo, vorrei partire con una 
    veste   editoriale  piu`  legata  al  video,  con  una   specie   di 
    impaginatore on-line per il testo della rivista.

          Dicembre e` anche tempo di bilanci: perche` non mi spedite  un 
    bel  matrix dicendo cosa vorreste avere e non avere l'anno  prossimo 
    su Telematicus? Almeno ricevero` un po' di posta...

          Un  cordiale saluto a Marco Russo che ha raccolto l'invito  di 
    scrivere qualcosa, e a Lorenzo Travaglio che ogni tanto si fa  vivo: 
    su, non ammazzo nessuno, sono troppo buono io!

          Infine  ribadisco qui l'invito che Franco Carcillo ha  scritto 
    nella  rubrica Notizie Fidonet: nessuna persona che abbia voglia  di 
    fare  il corrispondente Fidonet dagli altri net italiani? Nemmeno  a 
    Natale,  che sono tutti piu` buoni??? Tanto lo so che  arriva  anche 
    fuori da Torino...

                        ciaociao .mau.

    *****   Vol.  1   *****      Pag.  3      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................

                                   -----> LA PROGRAMMAZIONE EVENT-DRIVEN
                                          ==============================

         Il rapido evolversi delle interfacce utente verso sistemi user-
    friendly  ha portato qualche stravolgimento non solo  per  l'utente, 
    che  puo' passare giorni e giorni a schiacciare pulsanti  e  muovere 
    finestre col mouse, ma anche (e direi soprattutto) per i  programma-
    tori.

         Non piu' di dieci anni fa la struttura piu' "amichevole" che si 
    conoscesse  era una sequenza di menu in cui l'utente poteva  trovare 
    tutte  le  funzioni di cui necessitava  utilizzando  l'applicazione. 
    Certo, prima di poter "visitare" tutta un'applicazione ci voleva del 
    tempo,  ma era sicuramente piu' facile eseguire  un'operazione  sce-
    gliendo  tra  varie possibilita' presentate a video  che  non  farlo 
    scrivendo lunghi comandi (spesso infarciti di incomprensibili  para-
    metri) sulla tastiera...
    Venne  il Macintosh, venne Windows, venne l'Amiga,  l'Atari,  X-Win-
    dows....  oggi si puo' dire che non esista piattaforma senza i  suoi 
    bravi ambienti a finestre con menu a tendina, uso massiccio di  help 
    on-line, il tutto comandabile semplicemente muovendo il mouse...
    Addirittura anche senza arrivare ad usare sistemi con grafica  avan-
    zata  si possono vedere programmi che seguono in tutto e  per  tutto 
    questo nuovo "standard": qualsiasi applicazione MS-DOS un po' recen-
    te ha le stesse funzionalita' di una Windows, con le dovute  propor-
    zioni, ovviamente.

         Quello che non e' cosi' evidente, invece, e' che questa  migra-
    zione verso interfacce utente sempre piu' evolute ha costituito  una 
    radicale svolta nel metodo di costruzione dei programmi stessi. Oggi 
    un  programmatore rischia di dover passare piu' tempo  a  disegnare, 
    controllare,  gestire, in una parola a "fare"  l'interfaccia  utente 
    che non a "fare" il programma vero e proprio.

         Inizialmente  si  potrebbe dire: come, uno che usa  Windows  ha 
    gia'  tutto pronto, le routine sono gia' li', basta chiamarle,  qual 
    e'  il problema? Il problema e' proprio che le routine  da  chiamare 
    non  sono  cosi' poche, ma soprattutto il problema  piu'  grande  e' 
    stare  dietro alle imprevedibili mosse dell'utente che, preso  dalla 
    sindrome  del  mouse, puo' richiedere al programma di fare  le  cose 
    piu' disparate nelle situazioni piu' impensate (per il  programmato-
    re...).
    E  cosi' veniamo al nodo cruciale: il programmatore non decide  piu' 
    cosa l'utente puo' fare in ogni situazione possibile, il  programma-
    tore deve invece prevedere di gestire ogni "mossa" dell'utente, ogni 
    "impulso"  esterno (come errori di accesso al disco), in una  parola 
    ogni EVENTO possibile indipendentemente dal contesto in cui si trova 
    ad agire. La differenza, che potrebbe apparire sottile, e' in  real-
    ta'  molto grande, soprattutto se si pensa alla mole di  lavoro  ag-
    giuntivo che questa visione delle cose comporta.

         Facciamo  un  esempio: immaginiamo di utilizzare  un  programma 
    "vecchio  stile" e di volere effettuare una stampa di  alcuni  dati; 
    probabilmente  ci  troveremo di fronte ad un menu  con  scelte  tipo 

    *****   Vol.  1   *****      Pag.  4      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
    "Salva,  Carica, Stampa, Esci". Scegliamo di stampare:  compare  una 
    serie  di richieste circa la stampa che vogliamo  effettuare,  cioe' 
    che  stampante useremo, che formato di stampa, quante righe per  pa-
    gina, e cosi' via. Come utenti non abbiamo molte alternative se  non 
    rispondere alle domande che il programma ci pone, spegnere il compu-
    ter, andare a bersi una coca cola: di queste decisioni il programma-
    tore  deve prevedere solo la prima, al massimo la seconda... in  ef-
    fetti  il programmatore consente all'utente in quella situazione  di 
    effettuare un numero molto limitato di operazioni. 

         Ora resettiamo l'immaginazione e proiettiamo nel nostro encefa-
    lo  una bella videata con finestre, menu, icone, ghirigori  vari...; 
    decidiamo di stampare alcuni dati: andremo su di un menu di  stampa, 
    attiveremo questa funzione, comparira' una bella finestra con  tutti 
    i parametri di stampa, modificheremo quelli che non ci vanno bene  e 
    daremo il via alle operazioni.... 
    Detta  cosi' potrebbe sembrare la stessa cosa vero? Ma  facciamo  un 
    passo  indietro.  Tanto per cominciare, come ho  attivato  il  menu? 
    Potrei averlo fatto usando la tastiera, oppure con il mouse...  Com-
    pare la mia finestra con tutti i parametri... ah pero' adesso che mi 
    ricordo devo tornare sul documento per cambiare l'altezza del  tito-
    lo,  devo fare una copia del documento sul dischetto, devo  cambiare 
    il colore del bordo della mia finestrella, devo....

         Come  vedete il programma deve essere pronto a seguire tutti  i 
    "devo" dell'utente... ed e' proprio il programmatore che deve preve-
    dere tutti questi casi, o meglio deve fare in modo che l'utente  non 
    compia  operazioni  "distruttive"  richiedendo  simultaneamente  due 
    operazioni incompatibili tra di loro. 
    Un modo semplice e brutale e' fare in modo che se l'utente decide di 
    stampare  un documento o compila debitamente la richiesta di  stampa 
    che  gli viene proposta oppure annulla la stampa... senza  lasciarla 
    "in sospeso" sotterrando la nostra finestrella con milioni di  altre 
    finestre.  Questo  pero' e' appunto un metodo brutale,  che  snatura 
    tutta la filosofia con cui queste nuove interfacce utente sono nate.

         Abbiamo quindi scoperto un nuovo "stile" di programmazione, che 
    e'  la programmazione pilotata dagli eventi  (programmazione  event-
    driven).  Scrivere  un programma event-driven significa  in  soldoni 
    scrivere tanti programmi, uno per ogni evento possibile, che possono 
    poi interagire tra di loro. Attenzione pero' che non stiamo parlando 
    di  multi-tasking, ma di interazione a livello di dati:  infatti  la 
    stessa operazione (l'uscita da un programma) puo' richiedere  diffe-
    renti "passi" a seconda dello stato in cui si trova il programma. 
    Per esempio, immaginiamo che nel menu sia sempre attiva l'operazione 
    "Esci";  se questa viene richiamata quando non ci sono altre  opera-
    zioni  in sospeso, non si dovra' fare altro che restituire  il  con-
    trollo  al programma chiamante (in genere il sistema operativo),  ma 
    le cose cambiano se, ad esempio, ho effettuato una modifica su di un 
    documento senza averla ancora salvata.

         Questo e' il primo esempio di come le cose si complicano quando 
    si  scrive un'applicazione event-driven, e la  complessita'  aumenta 
    sempre  di piu' quando si devono controllare un numero  sempre  piu' 
    elevato di fattori variabili...

    *****   Vol.  1   *****      Pag.  5      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
         Ora, e' indubbio che questo modo di procedere sia "legato" allo 
    stile di programmazione tradizionale, quello in cui il programmatore 
    deve prevedere tutte le situazioni possibili e decidere cosa fare in 
    ognuna  di esse: con questo tipo di interfaccia utente il numero  di 
    situazioni e' talmente grande che diventa quasi impossibile scrivere 
    un programma consistente operando in questa maniera.

         Ovviamente esiste un sistema per semplificare le cose.

         Normalmente  esiste un "nocciolo" del programma (che a  seconda 
    dei  casi puo' essere implementato nel sistema operativo,  puo'  far 
    parte di una libreria o essere riscritto di sana pianta) che  gesti-
    sce gli eventi ad un livello basso, possiamo anzi dire che  "genera" 
    gli eventi: questo nocciolo non e' altro che un loop in cui si vanno 
    a  testare tutti gli "agenti esterni" (mouse, tastiera, floppy,  se-
    riale, parallela, ...) e in base ai segnali che essi producono deci-
    de che tipo di evento generano. Per esempio, il movimento del  mouse 
    assume  due significati diversi se il pulsante del mouse e'  premuto 
    oppure no; inoltre se si preme il pulsante del mouse in una zona del 
    video piuttosto che in un'altra il significato dell'operazione  puo' 
    cambiare.

         Questo "nocciolo" spesso e' la parte piu' cruciale del program-
    ma  e il piu' delle volte e' il programmatore che lo deve  scrivere, 
    magari utilizzando tutta una serie di primitive messe a disposizione 
    del sistema operativo: questo e' esattamente quello che succede  nel 
    Macintosh.  Per  fortuna esistono delle ottime  librerie  che  hanno 
    questa  parte di programma gia' pronta, ed eliminano gia' un  grosso 
    problema.

         A  questo punto iniziamo a parlare di eventi ad un  livello  di 
    astrazione piu' alto di quello che abbiamo visto sinora.
    Il nostro "nocciolo" analizza attentamente l'hardware e genera even-
    ti: chiamata di un menu, chiusura di una finestra, ecc.
    Il  programma  deve prevedere quindi un'operazione per  ogni  evento 
    possibile.  Un evento, pero', puo' interessare una o piu' parti  del 
    programma.
    Se,  infatti,  decidiamo di uscire dal programma, e'  probabile  che 
    questo evento influisca su quasi tutte le parti del programma,  poi-
    che' occorrera' effettuare tutta una serie di controlli per  verifi-
    care  che  tale operazione sia consentita. Se  invece  decidiamo  di 
    ridurre una finestra, quell'evento interessera' soltanto la parte di 
    programma che si occupa della gestione di quella finestra... che poi 
    questa  operazione  comporti una serie di operazioni  (e  quindi  di 
    eventi)  successive, questo non e' importante. L'evento  "riduci  la 
    finestra"  interessa direttamente quella finestra; il programma  po-
    tra' poi generare un evento "ridisegna la finestra" che interessa la 
    finestra che sta sotto, ma questo non ci interessa ora, ci  interes-
    sera' solo quando gestiremo l'evento successivo, che anziche' essere 
    generato  dal "nocciolo" di cui parlavamo prima sara'  auto-generato 
    dal programma stesso. In realta' questa differenza non e'  importan-
    te, poiche' ogni evento viene gestito allo stesso modo indipendente-
    mente da chi lo abbia generato.

    *****   Vol.  1   *****      Pag.  6      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
         Chi  e' riuscito a capirmi finora avra' iniziato a  comprendere 
    come  viene  strutturato un programma event-driven:  esistono  tanti 
    moduli  che convivono, operando ognuno per conto suo ma  comunicando 
    (quando serve) con gli altri moduli creando e ricevendo dei  messag-
    gi, cioe' degli eventi.
    Ma a cosa corrispondono, praticamente, questi moduli? Questo dipende 
    dal programmatore... ma la cosa piu' ovvia da fare e' di considerare 
    ogni  "oggetto" che possiamo visualizzare (finestra, menu,  bottone, 
    icona, ecc.) come un modulo del programma. Estendendo questo concet-
    to, possiamo pensare che esistano dei moduli che non siano altro che 
    insiemi di moduli piu' elementari (ad esempio, una finestra e'  com-
    posta  da un bordo e dalla somma degli elementi che  contiene,  come 
    testo non modificabile, linee di input, bottoni, e cosi' via).

         Nonostante tutto questo sia molto schematizzabile, vi  assicuro 
    che  non  e' affatto facile scrivere (almeno la prima  volta...)  un 
    programma con tutte queste cose...
    Per  fortuna  ci sono dei sistemi per semplificare il  lavoro:  oggi 
    questi sistemi sono i linguaggi object-oriented. Come dice la  paro-
    la, questi linguaggi sono orientati agli oggetti, cioe'  costringono 
    il  programmatore a scrivere non piu' delle semplici funzioni  (fun-
    zione per disegnare una finestra, per disegnare il menu, per gestire 
    il movimento della finestra, la scelta dei menu....) ma degli ogget-
    ti.  Oggetti  come finestre, menu, icone...  Ogni  oggetto  contiene 
    tutte  le funzioni (che prendono il nome di metodi) per la  gestione 
    completa dell' oggetto stesso.
    Questo significa che l'oggetto finestra possiede i metodi per  dise-
    gnare  la finestra e gestire tutti gli eventi a lui indirizzati.  Il 
    programma  che crea la finestra puo' quindi permettersi il lusso  di 
    ignorare  del tutto come funziona la finestra, poiche' essa e'  com-
    pletamente  autonoma e non ha bisogno di alcun "aiuto"  esterno  per 
    poter funzionare!

         Un programma event-driven puo' comunque essere scritto  utiliz-
    zando un linguaggio tradizionale, ma sicuramente e' molto piu' "sem-
    plice"  (soprattutto  dopo aver fatto un po'  di  esperienza)  farlo 
    utilizzando  dei linguaggi object-oriented; ancora piu' semplice  se 
    avrete delle buone librerie a disposizione...

         Per questo numero basta cosi'!!!

         Per insulti e commentacci vari contattatemi in Matrix o su Fido 
    Torino nell'area "Filo diretto coi Points".

         Un saluto.

                       Marco Russo
                       2:334/1.110@fidonet.org


    *****   Vol.  1   *****      Pag.  7      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................

                                                          -----> FUSIONE
                                                                 =======

          [NdE:  Ho  ricevuto  questo da uno  dei  nostri  piu`  assidui 
    collaboratori, impossibile non pubblicarlo]

         C'era  una volta un picolo BBS di montagna, Tecnosoft BBS,  en-
    trato in rete Fidonet per avere le tanto decantate aree messaggi.

         Poi,  salto'  fuori un altro BBS, ancora piu' piccolo,  ma  300 
    metri piu' in alto, e Tecnosoft divenne il "BBS di campagna".  Inol-
    tre vennero i points, ed il traffico di mail aumento' a dismisura...

    Nel  frattempo,  continuava la ricerca disperata ed inutile  di  uno 
    sponsor, ed il sysop incomincio' a soffrire di continue e prolungate 
    crisi depressive, con il crescere delle spese e con l'accorgersi che 
    la  sua  limitata disponibilita' di hardware non gli  permetteva  di 
    mettere in linea tanto da attirare utenti a sufficienza.

    Malinconicamente aiuto' un altro giovine sysop a mettere in piedi un 
    BBS  sponsorizzato... Che invidia vedere l'enorme hard disk in  mani 
    di  un nuovo venuto, mentre si tira avanti con due rumorosi e  lenti 
    hard da 20 Mega.

         Un  tragico sabato, al sysop in questione arrivo'  una  lettera 
    che lo getto' nello sconforto piu' nero. Dopo una mezz'ora di  deci-
    sione, si decise a telefonare: "Paolo, tu volevi avere un BBS  Fido-
    net,  vero?  Dammi tempo un'ora che te lo porto, con  tutti  i  miei 
    utenti, le mie aree messaggi e le mie aree files". Avvenne cosi'  la 
    fusione  tra il BBS di campagna ed il BBS sponsorizzato: al  vecchio 
    numero di Tecnosoft (0121-500663) risponde malinconico un Front End: 
    "Il numero e' cambiato! Chiamate lo 0121-542795 - orario 20.00-8.00; 
    domenica tutto il giorno", mentre al nuovo numero (542795)  risponde 
    un  potente BBS, a cui mancano ancora numerosi ritocchi, ma  che  ha 
    gia' da offrire molto piu' del vecchio Tecnosoft - se non altro come 
    enormi aree files.

         Comunicazione  di  servizio: io non saro'  piu'  reperibile  al 
    334/306.0, ma solo al 334/306.666.

         @    @
                   Ciao. Ci vediamo sul nuovo King BBS
         \____/


    *****   Vol.  1   *****      Pag.  8      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................

                                             -----> ITAPAC - PARTI 8 E 9
                                                    ====================

                    ERRORI
                    ------

         Durante  il collegamento con il PAD possono verificarsi  alcune 
    situazioni  che  sono decisamente anomale. Queste  anomalie  possono 
    compromettere il collegamento o anche la richiesta di  collegamento. 
    In  questo caso, in base al parametro 6, il PAD genera un  messaggio 
    corrispondente all'anomalia che e' venuta a verificarsi.

          RESET DTE  - L'host ha chiesto il reset del PAD. Tutti i para-
    metri  che abbiamo eventualmente riprogrammato vengono riportati  ai 
    valori che sono stati previsti dal nostro profilo o modificati prima 
    della  connessione. In pratica e` persa la programmazione fatta  du-
    rante il collegamento con l'host remoto.

          RESET ERR  - Errore di procedura. O la rete oppure il collega-
    mento col l'host ha commesso un errore di procedura nella  comunica-
    zione  arrivando cosi' a provocare il reset del collegamento  ed  il 
    ripristino dei parametri standard.

          RESET NC   - Reset  per congestione della rete;  qualche  pac-
    chetto  e'  andato perso in quanto la rete di  comunicazione  e'  in 
    condizioni di eccessivo affollamento.  La connessione con l'host  e' 
    ancora attiva e si puo' riprendere il colloquio.

          ERR INV    - Parametro  o comando non valido. Se  l'errore  si 
    verifica  durante la riprogrammazione di piu' parametri in  un  solo 
    comando  e' necessario correggere l'errore e mandare di nuovo  tutta 
    la stringa.

          ERR ILL    - Comando  non permesso, il NUI e'  errato.  ITAPAC 
    permette  solo NOVE tentativi di collegamento errati, al  decimo  si 
    interrompe  il collegamento con il PAD. Le NUI sono attive solo  sui 
    PAD a cui sono state assegnate: puo' capitare percio` che la NUI sia 
    corretta e che il PAD non la riconosca.


                    MESSAGGI
                    --------

          I  messaggi di tipo CLR xxx sono generati per segnalare  l'in-
    terruzione  o  il fallimento della connessione con l'host  remoto  e 
    riportano il PAD nel modo comandi per essere cosi' in condizione  di 
    chiedere una nuova connessione.

          CLR DTE  - Il collegamento e' stato interrotto dall'host.

          CLR CONF - Disconnessione  confermata: abbiamo inviato al  PAD 
    la  sequenza Control-P per attivare il richiamo del PAD  ed  abbiamo 
    inviato il comando CLR <CR>.

    *****   Vol.  1   *****      Pag.  9      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................

          CLR OCC  - L'host non dispone di porte libere per il  collega-
    mento. E' necessario attendere e riprovare piu' tardi.

          CLR NC   - La rete e' sovraccarica nel circuito che ci collega 
    all'host richiesto, ma puo` essere in compenso libera per effettuare 
    un collegamento diverso.  Questo messaggio puo' essere generato  sia 
    alla  richiesta che durante il collegamento. Per i collegamenti  in-
    ternazionali possono essere disponibili diverse "strade" che transi-
    tano  per diverse nazioni, puo' quindi essere utile provare  accessi 
    alternativi per aggirare il tratto congestionato.

          CLR INV  - E' stata richiesta una funzione non valida.

          CLR NA   - Accesso non permesso: l'host chiamato appartiene ad 
    un gruppo chiuso.

          CLR ERR  - Chiamata abbattuta a causa di un errore nella  pro-
    cedura Locale

          CLR RPE  - Errore di procedura dall'host chiamato: la chiamata 
    e' abbattuta

          CLR NP   - NUA non disponibile o non attiva sulla rete.

          CLR DER  - L'host chiamato e' guasto.

          CLR  PAD  - L'host ha chiesto al PAD la disconnessione.Il  PAD 
    ha abbattuto la chiamata.


                    I PROFILI STANDARD
                    ------------------

          I dieci profili standard che sono stati predefiniti dal Gesto-
    re sono stati studiati per tutta una serie di differenti applicazio-
    ni.  L'utente in commutata e' solitamente in condizione di  ricevere 
    il profilo 3 dal Gestore. Ecco la raffigurazione del profilo 3.

          PROFILO 3
          1 = 1        6 = 5        11 variabile    16 = 127
          2 = 1        7 = 21       12 = 1          17 = 24
          3 = 126      8 = 0        13 = 5          18 = 18
          4 = 255      9 = 2        14 = 1          19 = 2
          5 = 1       10 = 80       15 = 0 

          Gli  altri nove profili sono disponibili nel  manuale  ITAPAC: 
    Manuale di accesso alla rete itapac da parte di terminali start-stop 
    (X28) o su richiesta al sottoscritto. Se le richieste saranno molte, 
    faranno parte di un prossimo articolo.

                    VELOCITA` DEL PAD
                    -----------------
          Nonostante  il  vostro modem comunichi con il PAD ad  un  baud 
    rate  ben preciso (300 o 1200 baud full duplex) la trasmissione  dei 

    *****   Vol.  1   *****      Pag. 10      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
    pacchetti  rallenta in maniera drastica il numero dei  caratteri  in 
    ricezione e in uscita dal vostro DTE. Il PAD invia in  continuazione 
    segnali di Clear-to-send e Ready-to-send che si traducono in  macro-
    scopiche  pause  tra i pacchetti. A bassa velocita`  (300  baud)  la 
    commutazione non e` avvertibile, a 1200 invece si`. Abbiamo calcola-
    to che la velocita` reale di trasferimento e ricezione e` di  solito 
    compresa  fra i 450 baud e i 700 baud.  Il rallentamento si  "sente" 
    soprattutto  durante  la trasmissione di un file, in cui il  PAD  e` 
    sottoposto a lavoro, per cosi` dire, pressante. 
          In Xmodem, addirittura, il PAD rischia di sconvolgere i segna-
    li di Time Out, o di confondere tutto. I grossi Networks come DELPHI 
    tengono conto anche di questo, altri minori NO. Se il vostro  Xmodem 
    non  riesce a downloadare niente, significa solo che  l'Host  remoto 
    non prevede alcuna distinzione tra pacchetti e terminali asincroni.
          La domanda e`: accade solo su Itapac (non sarebbe da stupirsi) 
    o e` un problema comune a TUTTI gli NCP ?

                    LE SERATE "NC"
                    -------------
          Ci  sono  serate in cui qualsiasi indirizzo  chiamato  risulta 
    "NC".  Lo stato di Network Congestion e` molto frequente su  Itapac, 
    ed  impedisce l'utilizzo della rete dall'NCP usato.  Le  cause  sono 
    misteriose. Di notte le ditte non usano del tutto Itapac, e a  parte 
    qualche eccezione la rete PARE sia usata solo da hobbisti.  
          Dunque?  Ai centri assistenza negano tutto, ma la  realta`  e` 
    questa. Itapac, come conclusione, fa schifo. Non solo la fanno paga-
    re molto piu` di equivalenti reti all 'estero, ma oltre al danno  ci 
    aggiungono  anche la beffa: a volte NON VA. Come NON VA ?  Mah...  a 
    loro tutto funziona. E poi ci si stupisce se la gente tenta di  fre-
    garli.

                    LE NUI CHE USANO GLI HACKERS
                    ----------------------------
          Le NUI che solitamente usano (o usavano...) sono NUI dimostra-
    tive.  Non  hanno un account, e quindi,  teoricamente,  non  possono 
    esaurirsi.  Gli  operatori non possono neppure accorgersi  del  loro 
    uso, non avendo un record delle chiamate addebitate.
    Se una NUI dimostrativa "muore" le cause possono essere solo due:
    1) Itapac ha cambiato i codici per normale manutenzione interna.
    2) Itapac e` stata avvisata di quanto succedeva, o da un loro tecni-
    co  che ha rilevato un traffico anormale e ha controllato, o  da  un 
    esterno.


                    COME UN HACKER SI PROCACCIA UNA NUI
                    -----------------------------------

          Il metodo piu` sicuro e piu` facile e` quello di copiarla alle 
    Fiere  in cui Italcable o comunque operatori dispongono di  collega-
    menti in rete di tipo X28 commutato. Notate che gli X28 dedicati NON 
    necessitano di NUI, possedendo una propria linea fisica per  l'adde-
    bito.
          Avvicinatevi all'operatore e domandate "Quel computer ce  l'ha 
    il telefono? L'operatore (se avra` tempo) si impietosira`, di fronte 
    a  tanta manifestata ignoranza, e si sentira` tranquillo  anche  nel 

    *****   Vol.  1   *****      Pag. 11      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
    battere  la propria Password. Voi, con allenato colpo  d'occhio,  vi 
    guardate la tastiera e vi memorizzate la Nui. Per fortuna oggigiorno 
    i  tecnici  della Italcable utilizzano le macro,  e  di  conseguenza 
    quasi nessuno riesce ad impossessarsi di NUI alle fiere.

          Una nuova tecnica di scanning, basata su tentativi statistica-
    mente calcolati, e` stata accuratamente studiata e consolidata da un 
    aficionado delle bbs (un certo HM). Tale tecnica potrebbe garantire, 
    se  applicata a ricerche prolungate, esiti positivi di ricerca  NUI. 
    Peccato che il numero minimo di NUI provate non possa comunque esse-
    re inferiore alle 10.000 creando cosi` problemi di costo.
    Questo  serva  a scoraggiare chiunque abbia dei  propositi  illeciti 
    riguardo  all'utilizzo della rete nazionale a commutazione  di  pac-
    chetto.

                                               -----> BBS E RADIOASCOLTO
                                                      ==================

          Nel  Gennaio 1991 e' stato aperto, su alcune banche  dati  del 
    NET  334 uno spazio dedicato all'Associazione Italiana  Radioascolto 
    (A.I.R.)  nell'intento portare a conoscenza del pubblico  telematico 
    il mondo del radioascolto e le sue tematiche.
          Inizialmente  limitata a "Fido_To" ed "EUreka!" quest'idea  si 
    e'  successivamente sviluppata fino a coinvolgere ormai 11  BBS;  ad 
    Ottobre  inoltre  e' stato aperto il link con  "A.I.R.  BBS  Rimini" 
    gestito  dal  nostro socio Mario Morigi e per il futuro  si  prevede 
    l'espansione a livello nazionale.
          Si  tratta  di un'area messaggi e di  un'area  files  (questa, 
    purtroppo, non su tutti i BBS) in cui si possono trovare idee, noti-
    zie  ed articoli riguardanti il mondo della radio, dove per  "radio" 
    si  intende anche semplicemente l'apparecchio di cui  tutti,  credo, 
    disponiamo,  utilizzato  in maniera un po' diversa  dal  solito,  ad 
    esempio  per  ascoltare musica sui 1440 kHz di  R.  Luxembourg  ("il 
    juke-box d'Europa") invece che dalle FM nostrane.

          Che cosa serve per iniziare? Solo una radio che disponga alme-
    no  di  una gamma di Onde Corte; da questo punto in  avanti  non  ci 
    sono,  praticamente,  limiti. La si puo' ascoltare di  giorno  o  di 
    sera, per 5 minuti o per tutta una notte, da soli o in compagnia,  a 
    casa o in vacanza, sempre ed ovunque. Si possono ascoltare  trasmis-
    sioni  in italiano da tutto il mondo, oppure approfondire  la  cono-
    scenza di qualsiasi lingua straniera, dare la caccia a deboli segna-
    li di trasmissioni locali latinoamericane, insomma, si puo' fare  di 
    tutto con questo meraviglioso apparecchio.
          Provereste  voi a guardare la TV senza  l'antenna?  Certamente 
    no. Ebbene, anche la radio riceve i segnali nelle stesse condizioni, 
    per cui occorre pensare ad una soluzione analoga. Se il vostro appa-
    recchio  non e' un portatile, o comunque non ha un'antenna  telesco-
    pica incorporata allora dovete pensare ad una soluzione alternativa. 
    I  piu' smaliziati sanno che non c'e' limite agli esperimenti e  che 
    ogni possibile soluzione ha pregi e difetti. Tuttavia, per iniziare, 
    vi  propongo la soluzione piu' semplice: comprate qualche  metro  di 
    filo  unipolare (a trecciolina, smaltato o inguainato), fissate  uno 
    spinotto  ad  una estremita' ed inseritelo nella presa  per  antenna 
    esterna  che  si trova nel ricevitore, stendete la  rimanenza  nella 

    *****   Vol.  1   *****      Pag. 12      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
    camera  o fatelo uscire dalla finestra ed  accendete  l'apparecchio, 
    sintonizzandolo  fra  i 6000 ed i 6200 kHz: qui troverete  tutte  le 
    stazioni europee che sono di piu' facile ascolto.

          Provate  ad accendere la radio che giace da qualche  parte  in 
    casa vostra; utilizzandola in modo diverso scoprirete un mondo  nuo-
    vo,  credetemi.  Dopodiche' non dimenticate di  scrivere  le  vostre 
    esperienze  in area messaggi, non e' necessario  ascoltare  stazioni 
    difficilissime,  anche le esperienze con le emittenti piu'  "facili" 
    sono importanti.
          Per chi si vuole cimentare ricordo che a Gennaio '92 ci  sara' 
    una grossa occasione: il "2. A.I.R. Contest", aperto a tutti per  la 
    modica  cifra  di Lit. 7000, di cui trovate il Regolamento  in  area 
    messaggi oppure richiedendolo a Bruno Pecolatto, via Soana 13 - Pont 
    Canavese (TO).
          Se  volete  conoscerci piu' da vicino  potete  richiedere  una 
    copia omaggio della nostra rivista, Radiorama, scrivendo alla Segre-
    teria  A.I.R. - Casella postale 63 - 35020 Ponte San  Nicolo'  (PD), 
    oppure  venirci a trovare il terzo sabato di ogni mese a  Torino  in 
    via Vipacco 15, all'incirca verso le 15.00. Il prossimo incontro  e' 
    fissato  per  il 21 Dicembre, occasione giusta  per  scambiarci  gli 
    auguri di Natale.

          A  nome  dell'A.I.R. e del suo Presidente,  Alberto  Gandolfo, 
    desidero ancora una volta ringraziare l'Associazione TAMTAM, il  suo 
    Presidente  Franco  Carcillo e tutti i Sysop che  hanno  gentilmente 
    messo  a nostra disposizione uno spazio sui loro BBS: Enrico  Arman, 
    Franco  Carcillo,  Marco Civra, Mimmo  Cristofaro,  Fabrizio  Dogli, 
    Paolo Giulio Gialli, Paolo Goria, Sandro Magni, Mario Morigi, Rober-
    to  Piola,  Luigi Ravina, Franco Schinco, Mike  Sinesi,  Luigi  Vay, 
    nonche' tutti coloro che hanno contribuito e contribuiscono  tuttora 
    con i loro messaggi allo sviluppo di questa iniziativa.

          A  tutti  voi i piu' calorosi auguri di Buon Natale  e  Felice 
    Anno Nuovo.

                                         Lorenzo Travaglio
                                               2:334/1.105

    ------------------------------------------------------------
    ELENCO DEI BBS CHE CONTENGONO LE AREE RADIOASCOLTO
    (f = area files, m = area messaggi)
    ------------------------------------------------------------
    Fido_To                011-5765565 (area Forum - f+m)
    EUreka!                011-6624400 (f+m)
    Charlie's Puppies      011-3297706 (f+m)
    Travelmatic            011-502423  (The Smart BBS - m)
    Sintel                 011-596274  (pag. 327 - m)
    Piemonte Computer bbs  0121-542795 (m)
    Italia Network #1      011-8989069 (m)
    Italia Network #2      011-304840  (m)
    Italia Network #3      011-8126756 (m)
    Italia Network #4      011-8981304 (m)
    Italia Network #5      011-3174440 (m)
    AIR BBS Rimini         0541-777003 (m)

    *****   Vol.  1   *****      Pag. 13      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................

                                                        -----> VIVAMIGA
                                                               ========

          Amiga <-> Window 3.0
          --------------------

          Bene, carissime amebe ed ameboidi (mi sembra di scrivere l'in-
    troduzione di Dylan Dog) purtroppo questo mese ha portato poca  roba 
    nelle  capaci fauci del nostro Amiga. C'e' il solito giochino  della 
    Psignosys  a 40 livelli di parallasse con 56Mb di grafica  (si  vede 
    chiaramente che puntano al CD!) assolutametnte ingiocabile e noioso.

          E' uscito uno stupendo prg di generazione di frattali, Mandel-
    Paug, sicuramente il piu' veloce in giro... ed anche il piu'  preci-
    so. Permette animazioni di frattali (ad es. una serie di immagini in 
    ingrandimento) anche se devo dire che da quel lato non sia ne' molto 
    debuggato  ne' molto ottimizzato, contrariamente al resto  del  prg. 
    Dimenticavo, permette sia il Mandelbrot che il Julia; da non perdere 
    se v'interessa la cosa. Per la cronaca, con uno zoom spinto ho dovu-
    to alzare a 15 il livello di definizione ed ho terminato il  disegno 
    (Lace, Hi Res) in 11 ore. Lo stesso disegno e' stato portato a  ter-
    mine su di un 3000 in 3 minuti! Questo perche' il 3000 col coproces-
    sore forniva al livello di definizione 1 una precisione nei  calcoli 
    piu' che sufficiente!  Allucinante.

          E' uscito anche un bel prg di comunicazione sviluppato apposi-
    tamente  per il sistema operativo 2.0, e si vede. Purtroppo  non  ho 
    ancora  avuto modo di testarlo con una BBS, ma se tanto mi  da  tan-
    to... l'unico ad averlo testato, ed ad esserne uscito deluso e' quel 
    tal Verdone possessore non solo di un 3000 ma anche del super-galat-
    tico  HST US Robotics. [NdE: no, ha il Dual Standard che  e`  ancora 
    piu`  supergalattico]  Mah! Secondo me il tipo si  e'  faticosamente 
    letto  una volta il manuale del JRcomm ed ora non ha  intenzione  di 
    rileggersene altri. Dimenticavo, si chiama MXM_Term 1.9.

          Sono sempre piu' convinto di scrivere soltanto per il mio capo 
    redattore; possibile che non vi sia almeno venuto in mente di  chie-
    dermi cosa sia una 'trasmigrazione metabolica?'. 8-( [NdE: io  leggo 
    sempre quello che RRE scrive, visto che devo correggergli le  bozze, 
    e  visto  che  so cos'e` una t.m. non mi sono  preoccupato  piu`  di 
    tanto. Ma dai, amighisti, scrivetegli qualcosa cosi` sta contento!]

          Comunque  arriviamo  al sodo (disse l'uovo in  pentola):  oggi 
    voglio trattare alcuni concetti base per distinguere chiaramente gli 
    msdossiani col loro Windows 3.0 dagli Amighisti col loro SistemaOpe-
    rativo 2.0. Trovo la cosa estremamente interessante e, visto che  mi 
    accingo a scrivere un mare di fregnacce, siete pregati di interveni-
    re nel dibattito... Windows, ultimo capolavoro della piu' potente  e 
    panciuta casa di software (indovinate chi) dovrebbe essere  l'ultimo 
    grido in fatto di User Friendliness. Si basa su alcuni punti-forza:

           - La GUI (Graphics User Interface)
           - Il mutitask
           - La gestione della memoria

    *****   Vol.  1   *****      Pag. 14      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
          Le GUI sono gia' in giro da una vita, prima ancora che sul Mac 
    (volevo farvi una breve storia, ma tanto non frega nulla a  nessuno. 
    Per  chi fosse interessato c'e' una breve carrellata su di un  libro 
    per  Amiga, contattatemi). La GUI di Windows 3.0 e'  abbastanza  ac-
    cattivante, grafica in 3D, menu, gadget, icone etc.
          La GUI dell'Amiga 2.0 (che chiamero' d'ora in poi A2.0) sembra 
    copiata  di peso da Windows, i concetti-base li troviamo tutti.  Per 
    intenderci  oltre  a Windows fatto in tal  guisa  (lasciamo  perdere 
    quell'aborto di Mac) un altro esempio di GUI in 3D basato su toni di 
    grigio  e'  il NeXt. Insomma i concetti di costruzione  di  una  GUI 
    sembrano  orami  essersi consolidati a tal punto  da  diventare  uno 
    standard. [NdE: mai sentito parlare di X11R5?]
          Il multitask su Windows e' una bella nota dolente, chiaramente 
    quello  non e' multitask, non piu' di quanto io sia un  genio  della 
    programmazione. Semplicemente quando dovete usare un altro  applica-
    tivo  quello precedente sparisce. Da cosa capisco Windows  memorizza 
    il suo stato e poi lo si disattiva. Non resta neppure di tipo  resi-
    dent  (che  cioe' gira in contemporanea con altri  task).  [NdE:  in 
    realta`  non  e` un multitask ma un task switching: puo`  girare  un 
    solo task per volta, e puoi scegliere quale far girare]

          Chiaramente  il multitask dell'A2.0 e' superiore, e'  un  vero 
    multitask.  Tanto  per intenderci si possono  lanciare  n  programmi 
    tutti  uguali,  mentre se tentate questo  in  Windows  semplicemente 
    riappare il programma precedentemente lanciato. Il concetto di resi-
    dent e' molto piu' esteso, si possono lanciare n programmi  ciascuno 
    con  un  proprio stack, ma tutti facenti capo allo stesso  pezzo  di 
    codice  in memoria (chiaramente le global nel codice  devono  essere 
    rigorosamente  costanti!)  [NdE: si dice codice  shareable]   L'A2.0 
    possiede  gli Screen, grande invenzione che manca totalmente a  Win-
    dows.

          La  gestione  della memoria e' un punto di forza  di  Windows: 
    nessuna limitazione (vabbe', `quasi') e la possibilita' di impiegare 
    la memoria virtuale sull'HD (con ovvie limitazioni nelle  prestazio-
    ni). L'A2.0 non possiede questa chicca, credo principalmente per  il 
    fatto  che  la MMU (Memory Management Unit) non  sia  disponibile  a 
    livello di microprogrammazione sul 68000 (presente invece dal  68010 
    in  poi). In area Amy Devs qualcuno aveva proposto  di  implementar-
    la...  Chiaramente tutti si son dati da fare per far vedere che  si, 
    loro i manuali li sanno leggere, ma guai a tradurre le proprie cono-
    scenze teoriche in un programma. Quanto al sottoscritto, non sapreb-
    be da che parte iniziare e cosi' e' rimasto tutto sulla carta.

          Signori, mi rendo conto di avere appena superficialmente scal-
    fito il problema; tuttavia lo spazio e' tiranno. Se interessera'  (e 
    chi tace NON acconsente) continuero' il discorso sul prossimo  nume-
    ro.
          Arvudze

                                                    RRE
                                            2:334/100.9


    *****   Vol.  1   *****      Pag. 15      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................

                                                  -----> IL GERGO HACKER
                                                         =============== 

          <boot>: [tecnico; da `by one's bootstraps', `dai propri tiran-
    ti degli stivali] v.,s. Caricare o inizializzare il sistema operati-
    vo  su  una macchina. Questo uso non e` piu` gergale, ma  ha  creato 
    molti derivati che lo sono tuttora.

          Il derivato `reboot' implica che la macchina non e` stata giu` 
    a  lungo, o addirittura che il boot e` stato un <bounce> inteso  per 
    ripulire  uno  stato di <wedgitude> [in cui non si  aveva  piu`  una 
    situazione  stabile e chiara]. Questo e` a volte usato nei  processi 
    di pensiero umani, come nel seguente dialogo: "Mi sono perso".  "OK, 
    reboot. Ecco la teoria..."

          Si puo` anche trovare nelle varianti `cold boot' (da  macchina 
    spenta) e `warm boot' (colla CPU e tutti i dispositivi gia`  accesi, 
    come dopo un reset hardware o un crash software).

          Un'altra variante: `soft boot', reinizializzazione di una sola 
    parte  di  un  sistema, sotto controllo di altro  software  che  sta 
    ancora girando: "Se stai usando l'emulatore <mess-dos>, Ctrl-Alt-Ins 
    fa  un  soft-boot  dell'emulatore, lasciando  girare  il  resto  del 
    sistema".

          Opposto   a  quest'ultimo  c'e`  `hard  boot',   che   connota 
    un'ostilita`  o  una frustrazione nei confronti  della  macchina  da 
    bootare.  "Ho dovuto fare un'hard boot di uesta dannata Sun"  o  "Mi 
    raccomando di fare un hard boot". 

          Nota storica: questo termine deriva da `bootstrap loader',  un 
    programma  molto  corto  letto  da  schede  o  nastro  cartaceo,   o 
    direttamente battuto dal pannello di controllo. Questo programma era 
    sempre  molto corto (grandi sforzi venivano fatti per  raccorciarlo, 
    in  modo  da  minimizzare  la fatica e  la  possibilita`  di  errore 
    possibili  nel  digitarlo),  ed  era appena  capace  di  leggere  un 
    programma  leggermente piu` complesso (solitamente da un lettore  di 
    schede  o  di nastro cartaceo), a cui cedeva  il  controllo;  questo 
    programma  a  sua  volta  era  abbastanza  intelligente  da  leggere 
    l'applicazione  o il sistema operatico da un nastro magnetico  o  da 
    un'unita`  disco.  Cosi`, in passi successivi,  il  calcolatore  "si 
    tirava  su da solo" in uno stato operativo utile. Al giorno  d'oggi, 
    il  bootstrap  si trova di solito in ROM o EPROM, e legge  il  primo 
    passo  in  una  posizione fissa del disco, detta  il  `boot  block'. 
    Quando  questo  riceve il controllo, ha  abbastanza  conoscenza  per 
    caricare il SO richiesto e passargli il controllo.

          <bottom-up implementation>: [da sotto un su] s. Opposto hacker 
    di termine tecnico `top-down design'. In molte culture di programma-
    zione, e` considerato saggezza rivelata cheil modo miglire per crea-
    re una applicazione e` partire dai livelli di astrazione maggiore  e 
    scendere man mano giu`, specificando le sequanze di azione in detta-
    glio sempre maggiore fino a che non si arriva al codice vero e  pro-
    prio. Gli hackers trovano spesso utile (specialmente in incarichi di 

    *****   Vol.  1   *****      Pag. 16      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
    esplorazione  che  non possono essere  strettamente  specificati  in 
    anticipo) che funziona meglio `costruire' le cose nell'ordine  oppo-
    sto,  scrivendo e testando un chiaro insieme di primitive  e  quindi 
    cucendole insieme.

          <bounce> [rimbalzare]: v. 1. [UNIX, forse dall'immagine di una 
    palla  lanciata contro un muro che rimbalza] Un messaggio  di  posta 
    elettronica che non puo` essere recapitato e ritorna al mittente una 
    notificazione di errore e` detto essere `bounced'. Vedi anche <boun-
    ce  message>.  2. Avere relazioni sessuali:  prob.  dall'espressione 
    `bouncing the mattress' [far rimbalzare il materasso], ma influenza-
    to  dalla frase di Piglet nei libri di Winnie-the-Pooh "Salta  anche 
    su  di  me, Tigger", caricata psicosessualmente. 3. Fare  un  reboot 
    casuale  di un sistema per mettere a posto un  problema  transiente, 
    principalmente tra gli utenti <VMS>. 4. [IBM] fare un <power  cycle> 
    di una periferica per resettarla.

          <bounce  message>: [UNIX] s. Messaggio di notifica spedito  al 
    mittente  da  un nodo che non puo` spedire  <email>  all'  indirizzo 
    Internet  richiesto  o al link successivo in un  <bang  path>  (vedi 
    <bounce>).  Le  ragioni di questo possono comprendere  uno  username 
    inesistente  o scritto non correttamente, o un nodo di  relay  giu`. 
    Alle volte anche i b.m. possono fallire, portando a risultati  occa-
    sionalmente  disastrosi:  vedi <sorcerer's  apprentice  mode>  [modo 
    dell'apprendista  stregone].  Il collettivo `bounce mail'  e`  anche 
    comune.

          <box>  [scatola]: s. [in IBM] Un calcolatore: spec. nella  co-
    struzione  "foo box", dove foo is un qualificante di funzione,  come 
    `graphics', o il nome di un SO (tipo `UNIX box', `MS-DOS box', ecc.) 

          <boxed comments> [commenti inscatolati]: s. Commenti (note  di 
    spiegazione  nel codice) che occupano diverse linee. Chiamati  cosi` 
    perche`  in  codice  C e assembler sono  spesso  circondati  da  una 
    scatola in uno stile piu` o meno simile a questo:

     /*************************************************
      *
      * Questo e` un boxed comment in stile C
      *
      *************************************************/

    Varianti  comuni di questo stile omettono gli asterischi in  colonna 
    due  oppure aggiungono una serie di asterischi per chiudere il  lato 
    destro  della scatola. La variante piu` tersa omette tutto tranne  i 
    delimitatori  di  commento  all'estrema sinistra;  la  `scatola'  e` 
    implicita. Opp. <winged comments>.

          <boxen>  /bok'sn/:  [per analogia con <VAXen>]  s.pl.  Plurale 
    fantasiosi  di  <box> spesso trovato nella frase `UNIX  boxen',  per 
    descrivere sistemi hardware <UNIX>. La connotazione e` che due  UNIX 
    boxen possono sempre essere scambiate tra loro.

          <boxology>  /bok-sol'@-jee/: s. 1. La raffinata arte di  dise-
    gnare diagrammi usando i caratteri `box' (principalmente `|', `-'  e 

    *****   Vol.  1   *****      Pag. 17      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
    `+'  in  un  font  ASCII a  spaziatura  costante.  Nota  anche  come 
    `character graphics' o `ASCII graphics'. 2. Disegni boxologici.  "Il 
    suo report e` pieno di boxologia". Confr. <macrology>.

          <BQS>: agg. Sinonimo di <Berkeley Quality Software>.

          <brain  dump>:  [deposito del cervello] s. L'atto  di  dire  a 
    qualcuno  tutto quello che si sa su un particolare argomento o  pro-
    getto. Usato tipicamente quando qualcuno lascia ad altre persone  la 
    cura  della  manutenzione di una parte  di  codice.  Concettualmente 
    analogo al <core dump> di un sistema operativo, visto che  quest'ul-
    timo salva gran parte di informazioni di stato (<state>) utili prima 
    dell'uscita. Esempio: "Devi darmi un b.d. su FOOBAR, prima di comin-
    ciare  a lavorare per la HackerCorp.". Vedi <core dump> (sign.  #4). 
    Alla Sun, questo e` anche noto come `TOI' (Transfer Of  Information, 
    trasferimento di informazione).

          <brain-damaged>:  [col cervello danneggiato:  generalizzazione 
    di  `Honeywell Brain Damage' (HBD), una malattia  teorica  inventata 
    per  spiegare alcuni cretinismi nel sistema <Multics>  della  Honey-
    well]  agg.  Ovviamente  sbagliato:  <cretinous>;  <demented>.  C'e` 
    l'implicazione  che  la  persona responsabile di  cio`  debba  avere 
    subito  dei danni al cervello, perche` si sarebbe dovuta  comportare 
    meglio.  Chiamare qualcosa b.-d. e` davvero cattivo;  implica  anche 
    che non e` usabile, e che il suo fallimento non e` dovuto tanto a un 
    accidente, quanto a poverta` di sviluppo. 

          <break>: 1. vt. Causare la rottura di qc (in qualunque senso). 
    "L'ultimo  tuo patch all'editor ha scassato (`broke') i  comandi  di 
    paragrafo". 2. v. (di un programma) Fermarsi temporaneamente, cosic-
    che`  si  possa debuggare. Il posto dove si ferma e`  detto  "break-
    point".  3. [tecnico] vi. Mandare un break RS-232 (125 ms  di  linea 
    su) su una linea seriale di comunicazione. 4. [UNIX] vi. Digitare il 
    tasto  che  al momento fa spedire dal driver della tty  al  processo 
    attuale  il segnale SIGINT. Normalmente il tasto break (sign.  3)  o 
    delete sono quelli usati.

          <breakage>: s. 1. rottura e i casini conseguenti.  2. [IBM] Le 
    persone  in  piu` che devono essere aggiunte ad  una  organizzazione 
    perche` i piani principali sono cambiati: usato spec. di squadre  di 
    sviluppo software e hardware.

          <bring  X to its knees>: [mettere qc in ginocchio] v.  Di  una 
    macchina,  sistema operativo, pezzo di software, o algoritmo:  cari-
    carlo in maniera cosi` estrema o patologica che lo si ferma virtual-
    mente.  "Per  mettere in ginocchio un MicroVAX, prova ad  avere   20 
    utenti  che fanno girare <vi> - o quattro che usano <EMACS>.  Confr. 
    <hog>.

          <broken>:  [scassato] agg. 1. Che non lavora propriamente  (di 
    programmi).  2.  Che si comporta in maniera  strana,  spec.  (quando 
    usato per una persona) che esibisce una depressione estrema.

          <broket>: /broh'k@t/ o /broh'ket/ [per analogia con `bracket': 
    una  `broken  bracket'] n. Ciascuno dei caratteri `<' e  `>',  usati 

    *****   Vol.  1   *****      Pag. 18      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
    come  coppia  di delimitatori. La parola e`  nata  come  contrazione 
    della  frase `broken bracket', cioe` una parentesi che e` ricurva  a 
    meta`.  (Al  MIT, e apparentemente anche nel <Real World>,  sono  di 
    solito chiamate <angle brackets>, o parentesi angolari).

          <Brooks's Law> [legge di Brooks]: prov. "Aggiungere mesi  uomo 
    a un progetto software in ritardo lo fara` finire ancora piu` tardi" 
    -  un risultato del fatto che il vantaggio di dividere  un  progetto 
    tra  N programmatori e` O(N), ma la complessita` di coordinamento  e 
    di riunione dei vari sottolavori e` O(N^2). La citazione e` da  Fred 
    Brooks, un manager del progetto IBM OS/360 e autore di `The Mythical 
    Man-Month'  [Il mitico mese uomo], un eccellente libro tra  i  primi 
    sull'ingegneria del software; il mito in questione e` stato espresso 
    piu` laconicamente come "Il tempo del programmatore e` fungibile", e 
    Brooks ha definitivamente stabilito che questo e` falso. Gli hackers 
    non hanno mai dimenticato questo avviso, troppo spesso, il  <manage-
    ment> si`.

          <BRS>:  s. Sinonimo di <Big Red Switch>  [Grande  Interruttore 
    Rosso]. Questa abbreviazione e` abbastanza comune on-line.


                                                  -----> NOTIZIE FIDONET
                                                         ===============

    * TamTam a Nuove Tecnologie '91
      -----------------------------
          
          La scommessa e` stata vinta! 
    Il  bisogno di sapere, la fame di conoscere, la semplice  curiosita` 
    hanno portato, allo stand di TamTam, decine e decine di persone:  un 
    successo  davvero  solo sperato, concretizzatosi in  nuove  adesioni 
    all'associazione.
    E` stata una esperienza faticosissima ma premiante, non certo econo-
    micamente  (e questo si sapeva prima) ma senz'altro per la gioia  di 
    aver  parlato del proprio hobby, aver coinvolto e interessato  nuove 
    persone, da quei bravi missionari telematici che siamo.
    D'altronde l'impegno per la promozione dei servizi telematici amato-
    riali  e  la diffusione di valide iniziative di  supporto,  sono  LO 
    scopo  principale  di TamTam. Notare che, lentamente ma  con  sempre 
    maggior  interesse, le nostre iniziative, come l'incontro del  primo 
    lunedi` del mese, vedono avvicinarsi nuove generazioni di  telemati-
    ci, non puo` che vedere soddisfatte le aspettative di chi,  volonta-
    riamente, crede nella telematica come nuovo media di comunicazione.
    Ma questo successo non puo` che essere di stimolo per nuove  inizia-
    tive, nuovi impegni, nuovo coraggio, nuove `missioni'.
    Alla prossima, dunque!                     


    * Firenze: decisa la costituzione di AFI.
      ---------------------------------------

          Un  gruppo di SysOp, principalmente del net 332 e 335,  si  e` 
    ritrovato in una umidissima  Firenze, domenica 24/11, per  approvare 
    la bozza di statuto preparata da Franco Mulato (e altri) per l'Asso-

    *****   Vol.  1   *****      Pag. 19      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
    ciazione FidoNet Italia.
    L'Associazione curera`, a livello nazionale, gli interessi dei SysOp 
    (assistenza legale, rapporti con Enti ecc..) e promuovera` iniziati-
    ve tese a meglio far conoscere la telematica amatoriale.
    La sede sara` a Firenze, l'atto costitutivo sara` firmato nei  primi 
    giorni di dicembre.


    * Giorgio Rutigliano lascia il coordinamento italiano
      ---------------------------------------------------

          Giorgio Leo Rutigliano, primo SysOp italiano della rete  Fido-
    Net (con FidoPotenza a fine 1985) ha lasciato dopo 6 anni la  carica 
    di  Region Coordinator (RC) per l'Italia. Contemporaneamente  si  e` 
    anche dimesso da coordinatore del net 335 (SudItalia).
    A  Giorgio  un grazie sentito per quello che ha fatto e  per  quello 
    che, nonstante la momentanea disaffezione, continuera` certamente  a 
    fare per la rete FidoNet.
    Il  nuovo NC del net 335 e` Stefano Pasquini, gia` coordinatore  na-
    zionale echomail (REC).
    Il nuovo RC, Franco Carcillo, gia` NC del 334, iniziera` a  svolgere 
    l'incarico da fine novembre.


    * Telematicus cerca corrispondenti 
      --------------------------------

          Telematicus  intende  ospitare interventi  e  notiziari  anche 
    degli altri net italiani. A tal fine si cercano attivi corrisponden-
    ti  che, entro il 20 di ogni mese, siano in grado di inviare NEWS  e 
    quant'altro   necessario   all'editor  (.mau.)  [NdE:   spedite   al 
    2:334/100.5...] .


    * Servizi telematici e pirateria
      ------------------------------
    
          Ha  fatto scalpore la recente irruzione della  forza  pubblica 
    presso un rivenditore `non autorizzato' di software soggetto a copy-
    right. Il pirata pare avesse in casa tra migliaia di dischetti anche 
    700 milioni! Il medesimo disponeva di un un BBS, utilizzato per  gli 
    scopi illeciti di cui sopra.
    L'avvicinarsi del mercato unico europeo e di nuove leggi sul crimine 
    informatico porteranno senz'altro la legislazione italiana a  meglio 
    definire anche i reati di pirateria; attualmente la vacanza legisla-
    tiva provoca uno stato quanto mai confusionale sulla reale  applica-
    bilita`, per analogia, di norme relative ad altri elementi  patrimo-
    niali.
    I  servizi telematici, da sempre considerati, forse non del tutto  a 
    torto, covo di pirati e di incalliti smanettoni, se vogliono rimane-
    re  `pubblici' e non `pirati' dovranno essere davvero `sani e  puli-
    ti'; la presenza, soprattutto sistematica, di software piratato, per 
    i BBS della rete FidoNet potrebbe far scattare, secondo alcuni lega-
    li,  la  denuncia per associazione a delinquere. E coi  tempi  della 
    giustizia italiana, la dimostrazione di innocenza ha costi, economi-

    *****   Vol.  1   *****      Pag. 20      *****   Numero  12   *****

                       #####  TELEMATICUS  #####
    ....................................................................
    ci e morali, improponibili per gli hobbisti telematici. E`  pertanto 
    in  atto, su tutti bbs della rete, un severo controllo sui  software 
    disponibili  al prelevamento; i servizi che, nonstante  gli  avvisi, 
    continueranno  in modo sistematico a mettere in linea tale  software 
    si vedranno esplusi della rete. 
    Dura lex, sed lex.


                                              -----> NOTIZIE DAL NET 334
                                                     ===================
   
          Il 2 dicembre 1991 abbiamo il solito incontro mensile, l'ulti-
    mo del 91, per SysOp e utenti dei servizi telematici torinesi.  Nel-
    l'occasione grande festa per il successo di TamTam a Nuove  Tecnolo-
    gie. L'appuntamento e` per le ore 21, al CRDC in corso Sicilia 12.

          Come  gia`  visto  sopra, al nodo  334/306  non  trovate  piu` 
    Roberto  Piola, ma Paolo Goria, col suo nuovo Piemonte Computer  BBS 
    reperibile  dalle 20.00 alle 08.00 di tutti i giorni, e la  domenica 
    24 ore, allo 0121-524975.

          In  questo  mese di novembre, abbiamo anche  avuto  due  nuovi 
    ingressi in FidoNet: Enrico Olivetti col suo Olivetti Software  BBS, 
    allo 011-373651, e Gianni Bragante con Lady Bright BBS, che si trova 
    a  Vigliano Biellese (VC) e risponde (la sera, se non ho letto  male 
    la nodelist!) allo 015-8353153. Ai nuovi sysop un cordiale saluto, e 
    la  speranza  che mi mandino una paginetta dove raccontino  il  loro 
    BBS!


    *****   Vol.  1   *****      Pag. 21      *****   Numero  11   *****

                       #####  TELEMATICUS  #####
    ....................................................................


                                                     -----> I NOSTRI BBS
                                                            ============

         (BBS)              (numero)    (orario)(vel.) (SysOp)

         Fido_Torino........011-5765565....24h..2400   F.Carcillo 
         SDN-Italy!.........011-5765568....24h..9600   F.Carcillo 
         Charlie's_Puppies..011-3299706....24h..9600   F.Schinco
         Magazine...........011-8989069....24h..9600   L.Ravina
         I.N.#2 ............011-304840.....24h..2400   M.Sinesi
         I.N.#3 ............011-8126756....24h..9600   L.Vay
         I.N.#4 ............011-8981304....24h..9600   S.Magni
         I.N.#5 ............011-3174440....24h..2400   F.Bogli
         EUreka!............011-6624400....24h..9600   P.G.Gialli
         TorinoNet..........011-3100485/70.24h..2400   E.Arman
         Infotel............011-2238389....24h..2400   T.Moreno
         LordDrake..........011-710408.....24h..9600   F.Croce
         Travelmatic........011-502423.....24h..9600   M.Cristofaro
         Sintagma...........011-596274/48..24h..2400   M.Civra
         EGO................015-757151.....24h..2400   G.Amosso
         Piemonte_Computer..0121-542795....20-8.2400   P.Goria
         Lady_Bright........015-8353153....20-8.9600   G.Bragante
         Olivetti_Software..011-373651.....24h..2400   E.Olivetti

