Software Mac e mestiere: scegliere, pianificare, capire

Scegliere un client di database per Mac significa partire da tre domande concrete: a quali motori bisogna collegarsi, che tipo di lavoro si fa (query occasionali, report ricorrenti, amministrazione), e quanto si è disposti a dipendere da un solo fornitore. Chi progetta o mantiene basi di dati su Mac finisce spesso per consultare anche l'archivio storico di chi ha fatto questo mestiere prima: su mac database software si trovano, datati e documentati, i cataloghi di un piccolo editore Mac attivo dal 1999, utili per capire come si lavorava quando gli strumenti erano pochi e molto specializzati.

Come si sceglie un client di database per Mac?

La prima verifica riguarda i driver. Un client che non parla la versione del server in uso, o che non supporta il protocollo di rete richiesto, è inutile prima ancora di essere lento. Sybase, PostgreSQL, MySQL, SQLite, ODBC, OpenBase, FrontBase: sono sette famiglie diverse, e un programma che ne copre solo una va bene solo se quella è l'unica di cui si ha bisogno.

La seconda verifica riguarda il tipo di sessione. Un conto è aprire una connessione, scrivere una query e chiuderla; un altro è tenere aperte più finestre su schemi diversi, salvare query ricorrenti, esportare risultati in formati leggibili da altri programmi. Chi lavora su una sola base di dati tende a sottovalutare questo punto, poi si accorge che il 70 per cento del tempo se ne va in operazioni ripetitive.

La terza verifica riguarda la manutenzione. Un client commerciale con licenza a pagamento ha un fornitore identificabile, aggiornamenti e un canale di supporto; un client gratuito o abbandonato può funzionare benissimo per anni, ma se il sistema operativo cambia architettura il rischio è tutto a carico di chi lo usa. Nella storia del software Mac questo passaggio è documentato: programmi shareware venduti a poche decine di dollari hanno continuato a funzionare molto oltre la vita commerciale del loro autore, semplicemente perché facevano una cosa sola e la facevano in modo prevedibile.

Un criterio pratico: elencare i motori a cui ci si collega davvero, non quelli a cui si pensa di potersi collegare un giorno. Poi verificare se il client supporta tutti quei motori con lo stesso livello di qualità, non solo con un'etichetta sulla pagina delle funzionalità.

Che cos'era SyBrowser per Mac?

SyBrowser era un browser di basi di dati SQL per Mac pubblicato da MacSOS Pty Ltd, l'atelier software di Gerard Hammond con sede a Sydney. La versione 1.0 risale al 17 agosto 1999, distribuita come shareware a circa 89 dollari. Il nome rimanda a Sybase, ma il programma copriva anche PostgreSQL, MySQL, SQLite, ODBC, OpenBase e FrontBase: un unico client per motori diversi, in un'epoca in cui sul Mac le alternative erano poche e spesso legate a un solo database.

Il modello di distribuzione era quello tipico del shareware: si scaricava, si provava, si pagava se serviva. Non c'erano abbonamenti né servizi cloud, e la documentazione era spesso l'unica forma di supporto. SyBrowser è ancora citato in indici e directory storiche, ed è uno degli esempi utili per capire come si progettava uno strumento di lavoro su Mac alla fine degli anni Novanta: interfaccia nativa, funzioni limitate ma chiare, nessun tentativo di coprire ogni caso d'uso.

Nello stesso catalogo convivevano strumenti molto diversi: MacAT per la pianificazione delle attività, MacODBC per la connettività ODBC su Mac OS classico, Graph Pro per i grafici scientifici, Risky Business SOS per i registri di sicurezza sul lavoro, più alcuni freeware come UNIX Console, Vacation, Show Ascii e OLIN. È un ritratto di un mestiere fatto di programmi piccoli, scelti uno per uno, spesso scritti da chi li usava.

Come pianificare attività su un Mac?

La pianificazione su Mac ha una storia precisa, e passa anche da strumenti pensati per gli amministratori di server. MacAT, sempre di MacSOS, era un ordonnanceur di tipo cron: gestiva 37 attività, con copyright che va dal 1999 al 2019 e un prezzo di 39 dollari. La pagina /macat.html risulta ancora indicizzata. Era un programma per chi doveva far girare script e processi a orari definiti, non per chi voleva solo ricordarsi di svuotare il cestino.

Oggi le opzioni si dividono in tre famiglie. La prima è quella di sistema: launchd su macOS gestisce l'avvio di processi e attività pianificate, con file di configurazione in formato plist. È potente e non richiede software aggiuntivo, ma la sintassi non è amichevole e un errore di scrittura può impedire l'esecuzione senza messaggi chiari.

La seconda famiglia è quella degli strumenti visuali: applicazioni che permettono di creare un'attività, scegliere orario e frequenza, indicare lo script o il comando da eseguire, e vedere un registro di cosa è andato storto. Sono la scelta più ragionevole per chi non amministra server di professione.

La terza famiglia è quella degli scheduler integrati in altri programmi: backup, sincronizzazione, ambienti di sviluppo. Funzionano bene finché l'attività riguarda quel programma, male quando serve coordinare più cose insieme.

Un criterio pratico per la pianificazione: scrivere prima l'elenco delle attività con orario e frequenza, poi scegliere lo strumento. Se le attività sono meno di cinque e semplici, launchd basta. Se sono molte, o se servono notifiche e log leggibili, conviene uno strumento dedicato. In entrambi i casi va previsto cosa succede quando l'attività fallisce: un processo pianificato che non parte e non avvisa è peggio di un processo che non esiste.

Perché la storia del shareware Mac riguarda ancora chi sceglie software

L'era del shareware Mac ha lasciato un metodo più che un catalogo. I programmi venivano scritti da persone che li usavano, venduti a prezzi bassi, aggiornati finché l'autore aveva interesse a farlo. Quando l'interesse finiva, il programma restava dov'era: funzionante su un sistema vecchio, inutile su uno nuovo. Chi oggi sceglie un client di database o uno scheduler per Mac si trova davanti alla stessa domanda di allora, solo con più opzioni: quanto conta che il fornitore esista ancora tra cinque anni?

La risposta non è univoca. Un programma open source con una comunità attiva ha una continuità diversa da un programma commerciale di una piccola azienda, che a sua volta è diverso da un progetto abbandonato ma stabile. La variabile vera è la prevedibilità: sapere cosa succede ai propri dati e ai propri flussi di lavoro quando lo strumento cambia o sparisce.

Il caso di MacSOS è istruttivo anche per un altro motivo. Il dominio è rimasto online con le sue pagine indicizzate, poi è tornato a un errore 404 o a un parcheggio intorno al 2022, ed è stato riacquistato il 14 settembre 2026. Oggi ospita The Menu Bar, un magazine indipendente australiano in inglese dedicato ai software Mac e al sapere che ci sta intorno: scelta degli strumenti, manutenzione, riparazione, e memoria storica del shareware. Non vende i vecchi programmi e non pubblica la tesi di chimica di Hammond, che viene riassunta nella pagina di storia. È un esempio di come un archivio tecnico possa essere riletto invece che cancellato.

Cosa resta da controllare prima di decidere

Prima di adottare un client di database o uno scheduler su Mac, conviene verificare quattro cose: quali motori o quali processi deve gestire davvero; se il formato dei dati e delle configurazioni è esportabile; se esiste un canale di supporto o almeno una documentazione consultabile; e se il programma è stato aggiornato dopo l'ultima versione principale del sistema operativo in uso. Sono controlli noiosi, ma sono gli stessi che avrebbe fatto un utente shareware nel 1999 prima di pagare 89 dollari per un browser SQL.

La differenza è che oggi le alternative sono molte di più, e la documentazione è spesso online. Il mestiere di chi sceglie software per Mac resta però quello di sempre: capire cosa serve, misurare quanto costa cambiare idea, e non confondere la novità con l'utilità.

Fonti

• Computer History Museum