Nel precedente articolo abbiamo parlato di macOS, iOS e lo stresso legame con BSD. Oggi iniziamo un nuovo argomento: siamo abituati ad utilizzare le funzionalità di base di macOS: Mail, Safari, Siri e volendo esagerare il Terminale. Esistono altre componenti meno famose, ma ugualmente importanti.
Logging
Con il passaggio ad una piattaforma basata su BSD, macOS ha ereditato anche il supporto per il tradizionale log dei sistemi Unix. Questo supporto fornisce la piena compatibilità con il meccanismo secolare comunemente noto come syslogd.
Il meccanismo syslog gestisce i messaggi testuali, che sono classificati in base a due parametri: facility e severity. La prima, riguarda ‘da dove’ è partito il messaggio, quindi la sorgente, mentre la seconda misura il livello di rigidità del log. (ad esempio, LOG_ERR = impossibile aprire il file)
Utilizzando il file di configurazione /etc/syslog.conf, un amministratore può decidere le azioni da intraprendere, che corrispondono alla combinazione dei due parametri facility/severity. Ma dal punto di vista pratico, come funziona?
I programmatori si interfacciano con syslog usando l’API syslog, che consiste in una chiamata a openlog(), attraverso syslog(), che registra i messaggi con una certa priorità; a questo punto il daemon syslog intercetta questi messaggi.
Da macOS Tiger, Apple ha introdotto un nuovo modello per la registrazione dei log chiamato Apple System Log o ASL. Questa nuova architettura (utilizzata anche in iOS) mira a fornire una maggiore flessibilità di quella fornita da syslog. ASL è modellato su syslog, con gli stessi parametri, ma consente di usare più funzioni, come il filtraggio e la ricerca che invece non sono offerte da syslog.
ASL è modulare (perché l’attività di logging può essere svolta su interfacce diverse, come ad esempio su quella kernel o sulla porta UDP 514) e questi log creati vengono raccolti in /var/log/asl. Sono gestiti dal comando aslmanager, che viene eseguito automaticamente da launchd, ma è anche possibile eseguire il comando manualmente.
I log ASL, a differenza dei file syslog, sono binari, non di testo: questo peculiarità li rende più piccoli. Apple comunque, anche avendo implementato ASL, include il comando syslog in macOS per visualizzare e visualizzare i log.
Apple Events e AppleScript
Una delle caratteristiche più trascurate in macOS, riguarda la sua capacità di scripting. Le origini di AppleScript risalgono a OS 7 con un linguaggio chiamato HyperCard. Da allora si è evoluto considerevolmente, diventando il meccanismo chiave dietro il comando osascript e l’amichevole (ma trascurato) Automator.
In fase di scripting, i comandi di AppleScript devono seguire una determinata grammatica che se rispettata, offre una vasta gamma di libertà; le applicazioni integrate in macOS possono essere quasi completamente automatizzate e, per coloro che diffidano degli script, Automator fornisce una GUI drag-and-drop composta da azioni presenti nel percorso /System/Library/Automator.
Il meccanismo che consente la magia di AppleScript si chiama AppleEvents, che è il protocollo di comunicazione predefinito in macOS: si tratta essenzialmente di messaggi spediti tramite codici da un’applicazione a un’altra: AppleScript usa i dizionari di ogni applicazione per associare a tali codici dei termini comprensibili, permettendo quindi la comunicazione nei due sensi tra codici AppleEvents e termini AppleScript.
FSEvents
Tutti i moderni sistemi operativi offrono le API per la notifica del file system. Windows ha il suo MJ_DIRECTORY_CONTROL, Linux ha inotify, mentre macOS e iOS offrono entrambi FSEvents.
FSEvents è concettualmente simile all’inotify di Linux: tramite queste API le app si registrano a ‘ricevere delle notifiche’ ogni volta che il file system viene modificato; quando il file system cambia il kernel ‘passa’ queste notifiche attraverso un file speciale /dev/fsevents ad un processo in userspace chiamato fseventsd che a sua volta va a notificare tutte le app che si sono registrate al servizio di notifica per avvisarle che qualcosa è cambiato all’interno del file system.
Se provate a controllare la documentazione Apple, noterete che le pagine di manuale o i file di inclusione riguardo FSEvents è vuota. Il motivo è che da quando è stato introdotto è stato assottigliato sempre più: anche se l’API rimane pubblica, ha solo tre fruitoti ufficiali:
- coreservicesd: è il daemon che supporta gli aspetti principali del sistema, come i servizi di lancio.
- mds: il server Spotlight, di cui avevamo parlato qui. Spotlight è un utente “pesante” per FSEvents, perchè si basa sulle notifiche per trovare e indicizzare nuovi file.
- fseventsd: è il daemon appena discusso, che è sepolto all’interno del framework CoreServices. (insieme a coreservicesd)
Sia applicazioni scritte in Objective C che Swift possono utilizzare le API CoreServices di FSEventStreamCreate. Questo framework è praticamente un sottile strato in cima al meccanismo attuale, che consente la conversione del modello degli eventi, da sincrono ad asincrono, basato quindi su eventi.
Anche per questo articolo è tutto. Per eventuali domande, curiosità o feedback potete lasciare un commento qui in basso, a presto!