Usare il lettore di smart card Manhattan su Linux

Per lavoro mi sono imbattuto nel dover far funzionare con Linux un lettore di smart card marchiato Manhattan (cod. 172844).

Post imageUn lettore per smartcard è utile per effettuare la firma elettronica ma anche per leggere la tessera sanitaria (TS-CNS) ai fini dell'accesso al proprio fascicolo sanitario elettronico o per ottenere una utenza SPID.

Continua a leggere »

Cosa c'è da migliorare nel mondo GNU/Linux

MI sono fatto una idea di alcuni aspetti da migliorare nelle distribuzioni GNU/Linux per avere un sistema pronto out-of-the-box e usabile in ambienti lavorativi.

  • Gestione SmartCard. Nelle pubbliche amministrazioni si sta diffondendo la firma eletronica per mezzo di SmartCard e mentre su Windows XP basta collegare il lettore e basta, su Linux esistono più di un programma per la gestione del lettore e per la gestione delle varie codifiche delle SmartCard, insomma, un macello! Quello che serve è un unico sistema che gestisca il lettore e dia una interfaccia unica per la gestione delle varie codifiche di schede, il tutto interfacciato con HAL (o il futuro DeviceKit) così da essere usato con semplicità da qualunque programma.
  • Periferiche di gioco. Non si capisce più a chi fare riferimento per gestire i vari controller HID individuati come joystick. Il nuovo driver evdev pare segna tutto come mouse, infatti su HAL abbiamo che un joystick ha come capability input.mouse. Ora se io faccio un gioco come faccio a rilevare se un joystick è stato inserito mentre il gioco è già in esecuzione? Inoltre i device indicato da HAL non è accessibile con i normali diritti di utente ma richiede l'utente root, ed è giusto altrimenti potremmo fare keylogger a randa! Poi vengono create le interfacce /dev/input/js0-9, ma che mi avverte di ciò? Nessuno. Devo andare io manualmente a scansionare la cartella ogni poco e caricare il tutto. In definitiva per accedere ai joystick esiste, evdev, il driver joystick e libjsw (libreria orfana che comunque usa il driver joystick ma almeno non si deve usare le ioctl.
  • D-Bus. Rendere la creazione di un server D-Bus in C più semplice, sarò duro ma non ho ancora capito come esporre dei metodi e segnali sul bus. Non si poteva fare qualcosa di semplice come la connessione dei segnali in GTK+?
  • Gestione dei livelli audio. Adesso abbiamo 3 o 4 livelli di volume per una sorgente, volume interno dell'applicazione, volume di PulseAudio per lo stream dell'applicazione, volume PCM e volume generale. Un po' troppi mi pare. Intanto un volume potrebbe essere tolto quando l'applicazione si connette a Pulse Audio regolando direttamente il volume di PulseAudio, in questo modo rimangono sempre due slider ma almeno regolano lo stesso stream. Anche il volume PCM andrebbe tolto, facendo gestire tutti gli ingressi da PulseAudio. Peccato che tutto quanto probabilmente sarà accente da Ubuntu Jaunty e, secondo me, creerà panico tra gli utenti che non capiranno una mazza dove regolare l'audio.
  • Supporto ai dispositivi WiFI 802.11n. Non ci siamo proprio, al momento dei lavori non esiste una scheda PCI o USB che collegata a Linux funzioni subito. Quando va bene occorre scaricare dei driver, compilarli e installarli, così da avere il modulo giusto. Quando va male occorre andare nel sorgente per modificare il driver, e magari una volta creato il modulo non supporta manco alcune feature del protocollo. E la situazione rischia di essere identica con Jaunty. Il problema è stata la rapida diffusione sugli scaffali dei negozi di apparecchi compatibili con la seconda bozza del protocollo 802.11n che dovrebbe garantire fino a 300Mb/s quando va bene. Alcune volte i driver open ci sono, vanno solo inclusi nel kernel...
  • X.org. Al momento il server grafico predefinito di ogni distribuzione GNU/Linux è la più grande limitazione per la reattività del sistema, i metodi che i vari toolkit grafici usano per velocizzare alcune funzioni di disegno sono quelli di scavalcare il server grafico per usare direttamente la scheda grafica, quindi o qualcuno riscrive X.org oppure occorre un nuovo server grafico più performante.
  • Meno divisioni e meno seghe mentali. Il concetto è semplice, evitare di reinventare la ruota e non crogiolarsi troppo su questioni etiche. Vedi come la nuove licenza GPLv3 limita in modo considerevole lo sfruttamento commerciale del software libero.

E voi cosa ne pensate? Siete d'accordo con i punti elencati o ne aggiungereste altri?

CC BY-NC-SA 3.0 2004-2020 Daniele Napolitano — Per informazioni sulla licenza leggere le Note legali