Slackware: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Aggiunto citazione web. |
m typo |
||
Riga 95:
==== Controllo delle dipendenze e flessibilità ====
La filosofia progettuale di Slackware affida all'amministratore del sistema la responsabilità di verificare che tutte le dipendenze siano soddisfatte. Ciò garantisce un'elevata flessibilità,<ref name='Daniël de Kok, Zach Loeber, "Slackware Package Management"' /><ref name='Jack Wallen, "10 reasons why you should give Slackware Linux a chance"' /> tuttavia questa caratteristica ha dato vita in passato a discussioni fra gli estimatori di questa soluzione e coloro i quali, più vicini a distribuzioni come Debian o Red Hat, ritengono indispensabile per l'utente medio non solo il controllo delle dipendenze da parte del sistema, ma pure un'ampia [[:en:Software repository|repository]] di software già [[Compilazione|compilato]], a cui attingere con facilità mediante un sistema automatizzato. Per questi ultimi, Slackware sarebbe inoltre poco adatta all'ambito aziendale, poiché includerebbe una quantità troppo limitata di software e non permetterebbe un'efficiente amministrazione del sistema soprattutto in contesti caratterizzati da un elevato numero di computer.<ref name='Caitlyn Martin, "Slackware 12.1 First Impressions"' /><ref name='Caitlyn Martin, "Slackware 12.1 - The Newest Version of the Oldest Surviving Linux Distribution"' /><ref name='Caitlyn Martin, "Slackware Linux 13.0 - the oldest Linux distro gets a major overhaul"' />
D'altra parte va precisato che, di fatto, Slackware permette di compilare e di installare qualsiasi programma esistente che sia compatibile con l'installazione di base, proprio grazie alla neutralità garantita dall'assenza di un complesso sistema di controllo delle dipendenze legato a una repository centralizzata.<ref name='Jack Wallen, "10 reasons why you should give Slackware Linux a chance"' /><ref name='Daniël de Kok, Zach Loeber, "Slackware Package Management"' /> L'apertura e l'estendibilità di <tt>slackpkg</tt> rendono inoltre possibile la creazione di repository dedicate, locali o remote, contenenti il software che si ritiene necessario per le proprie esigenze e che non è incluso nella distribuzione di base. Queste repository possono essere gestite in modo trasparente mediante <tt>slackpkg</tt>, alla pari della repository ufficiale, definendo con precisione le priorità dei pacchetti che dovessero trovarsi contemporaneamente in più di una repository. Ciò è possibile grazie a un'estensione per <tt>slackpkg</tt> denominata <tt>slackpkg+</tt>, creata da Matteo Rossini con il contributo e il sostegno di altri sviluppatori, tra cui Eric Hameleers.<ref name="www.slakfinder.org - Slackpkg+, a slackpkg plugin for third-party repositories">{{cita web| url=http://www.slakfinder.org/slackpkg+.html| titolo=www.slakfinder.org - Slackpkg+, a slackpkg plugin for third-party repositories| accesso=16 novembre 2013}}</ref><ref name='Eric Hameleers, "Introducing slackpkg+, an extension to slackpkg for 3rd party repositories"'>{{cita web| url=http://alien.slackbook.org/blog/introducing-slackpkg-an-extension-to-slackpkg-for-3rd-party-repositories/| titolo=Introducing slackpkg+, an extension to slackpkg for 3rd party repositories| accesso=15 novembre 2013 | autore=Eric Hameleers}}</ref><ref name="www.linuxquestions.org - slackpkg vs. third-party package repository">{{cita web| url=https://www.linuxquestions.org/questions/slackware-14/slackpkg-vs-third-party-package-repository-4175427364/| titolo=www.linuxquestions.org - slackpkg vs. third-party package repository| accesso=15 novembre 2013}}</ref> Grazie alla possibilità di impartire i comandi attraverso un'interfaccia a riga di comando, le caratteristiche appena descritte permettono l'integrazione del sistema di gestione dei pacchetti in script creati ''ad hoc'', offrendo così un ampio ventaglio di possibilità tra cui l'automatizzazione degli aggiornamenti e la gestione razionale, anche via rete, di più sistemi.
| |||