{"id":103819,"date":"2022-04-19T15:36:59","date_gmt":"2022-04-19T13:36:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/dvizhenie-po-vklyucheniyu-proprietarnyh-proshivok-v-postavku-debian"},"modified":"2022-04-19T15:36:59","modified_gmt":"2022-04-19T13:36:59","slug":"dvizhenie-po-vklyucheniyu-proprietarnyh-proshivok-v-postavku-debian","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/dvizhenie-po-vklyucheniyu-proprietarnyh-proshivok-v-postavku-debian","title":{"rendered":"Movimento per l'inclusione di firmware proprietari nella distribuzione di Debian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Steve McIntyre, che per diversi anni ha ricoperto il ruolo di leader del progetto Debian, ha lanciato un'iniziativa per ripensare il modo in cui Debian gestisce la fornitura di firmware proprietari, attualmente non inclusi nelle immagini ufficiali di installazione e forniti in un repository separato non libero. Secondo Steve, il tentativo di raggiungere l'ideale di fornire solo software open source porta a difficolt\u00e0 aggiuntive per gli utenti, che spesso devono installare firmware proprietari per ottenere il funzionamento completo dell'hardware. <\/p>\n
I firmware proprietari sono collocati in un repository separato non libero, insieme ad altri pacchetti distribuiti non sotto licenze aperte e libere. Il repository non libero non \u00e8 ufficialmente parte del progetto Debian e i pacchetti in esso non possono essere inclusi nelle immagini di installazione e live. Per questo motivo, le immagini di installazione con firmware proprietari vengono raccolte separatamente e classificate come non ufficiali, sebbene formalmente la loro sviluppo e supporto siano gestiti dal progetto Debian. <\/p>\n
Cos\u00ec, nella comunit\u00e0 \u00e8 stato raggiunto un certo status quo, in cui si combina il desiderio di fornire solo software open source nel distribuito con la necessit\u00e0 degli utenti di avere firmware. Esiste anche un piccolo insieme di firmware liberi, che \u00e8 incluso nelle compilazioni ufficiali e nel repository principale, ma questi firmware sono molto pochi e non sono sufficienti nella maggior parte dei casi. <\/p>\n
L'approccio adottato in Debian crea molti problemi, tra cui l'inconveniente per gli utenti e il consumo di risorse per la compilazione, il test e la distribuzione di compilazioni non ufficiali con firmware chiusi. Il progetto presenta come principali compilazioni raccomandate le immagini ufficiali, ma questo confonde solo gli utenti, poich\u00e9 nell'installazione si trovano di fronte a problemi di supporto hardware. L'uso di compilazioni non ufficiali porta involontariamente alla popolarizzazione di software non libero, poich\u00e9 l'utente insieme ai firmware ottiene anche il repository non libero collegato con altro software non libero, mentre se i firmware fossero offerti separatamente, senza includere il repository non libero, si potrebbe fare a meno di esso. <\/p>\n
Negli ultimi tempi i produttori ricorrono sempre pi\u00f9 all'uso di firmware esterni caricati dal sistema operativo, piuttosto che fornire firmware memorizzati nella memoria permanente dei dispositivi stessi. Questi firmware esterni sono necessari per molti moderni adattatori grafici, audio e di rete. Tuttavia, \u00e8 discutibile quanto i firmware possano essere considerati requisiti per la fornitura di software libero, poich\u00e9 essenzialmente i firmware sono eseguiti su dispositivi hardware, e non nel sistema, e sono parte dell'hardware. Con lo stesso successo, sui moderni computer, anche quelli dotati di distribuzioni completamente libere, vengono eseguiti firmware integrati nell'hardware. L'unica differenza \u00e8 che alcuni firmware vengono caricati dal sistema operativo, mentre altri sono gi\u00e0 incorporati nella ROM o nella memoria Flash. <\/p>\n
Steve ha portato alla discussione cinque principali opzioni per la consegna dei firmware in Debian, che saranno sottoposte a votazione da parte degli sviluppatori: <\/p>\n
Lasciare tutto com'\u00e8, fornendo firmware proprietari solo in singole build non ufficiali.\n
Interrompere la fornitura di build non ufficiali con firmware non liberi e allineare la distribuzione all'ideologia del progetto di fornire solo software libero.\n
Trasformare le build non ufficiali con firmware in build ufficiali e fornirle parallelamente e in un unico luogo con le build che includono solo software libero, semplificando cos\u00ec la ricerca del firmware necessario da parte dell'utente.\n
Includere i firmware proprietari nelle build ufficiali standard e rinunciare alla fornitura di singole build non ufficiali. Lo svantaggio di questo approccio \u00e8 l'inclusione del repository non-free per impostazione predefinita.\n
Separare i firmware proprietari dal repository non-free in un componente distinto non-free-firmware e fornirlo in un altro repository, che non richiede l'attivazione del repository non-free. Aggiungere alle regole del progetto un'eccezione che consenta di includere il componente non-free-firmware nelle build di installazione standard. In questo modo, sar\u00e0 possibile rinunciare alla creazione di singole build non ufficiali, includere i firmware nelle build standard e non attivare il repository non-free agli utenti.\n
Steve stesso sostiene l'adozione del quinto punto, che consentir\u00e0 al progetto di non allontanarsi eccessivamente dalla promozione del software libero, pur rendendo il prodotto comodo e utile per gli utenti. Nell'installer si propone di separare chiaramente i firmware liberi da quelli non liberi, fornendo all'utente la possibilit\u00e0 di fare scelte consapevoli e informandolo su quali firmware liberi supportano l'hardware attuale e se ci sono progetti per creare firmware liberi per i dispositivi esistenti. Durante la fase di avvio, si prevede anche di aggiungere un'opzione per disabilitare il pacchetto con firmware non liberi. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"