Slackware è Linux


Come riportato qui:

Essendo stata concepita per essere più unix-like possibile, Slackware è considerata un’ottima distro per imparare il funzionamento di Linux, tanto che i suoi estimatori usano dire: “When you know Slackware, you know Linux… when you know Red Hat, all you know is Red Hat.” (“Quando conosci Slackware, conosci Linux… quando conosci Red Hat, conosci solo Red Hat.”)
Slackware è la distro che più di tutte aderisce al motto KISS (ovvero “Keep It Simple and Small”, ovvero “Mantienilo semplice e piccolo”), perchè inserire pesanti interfacce grafiche per eseguire delle configurazioni che possono essere tranquillamente eseguite a mano?
Slackware è conosciuta per essere una distro veloce e stabile, queste caratteristiche derivano proprio dalla scelta di non includere tool grafici di configurazione. Scelta che ha consentito anche di ottenere una distro altamente configurabile, al contrario di certe distro user-friendly nelle quali è assai difficile modificare un impostazione per la quale non è stato previsto un tool grafico.
Inoltre, l’utilizzo di un kernel vanilla (cioè privo di patch, eccezion fatta per la patch speakup – utile per i diversamente abili – che peraltro si può scegliere di non installare in fase di installazione) rende molto più semplice la ricompilazione dello stesso rispetto ai kernel profondamente patchati di altre distro.

Aggiungiamo anche che:

Spesso Slackware Linux viene additata come una distro difficile da installare, configurare ed utilizzare. Questa critica è principalmente dovuta al fatto che Slackware Linux non fornisce tool grafici di configurazione, in realtà, dopo aver appreso come utilizzarla, si rivela una distro molto semplice da utilizzare al meglio, in grado di regalare grandi soddisfazioni.
Inoltre, l’utilizzo di un vanilla-kernel (cioè privo di patch) rendono molto semplice la ricompilazione del kernel. In ogni caso Slackware non è la distro più indicata per un neofita di GNU/Linux, soprattutto se arriva dal mondo Windows™.
Per imparare ad utilizzare questa distro è molto utile consultare il libro Slakware for Dummies di Mauro Sacchetto, reperibile sul sito http://www.slacky.eu, che guida passo passo ad una corretta installazione e configurazione del sistema.

29 thoughts on “Slackware è Linux

  1. Pingback: Slackware è Linux

  2. dopo un paio di mesi con mandrake passai a slackware
    ho imparato l’80% di quanto so su linux in vari anni di piacevole uso di slack
    il restante 20% l’ho imparato facendo il setup di gentoo😉

  3. @Mario Vanoni:
    No, KISS sta per “Keep It Simple, Stupid” come si puo’ notare dalla wikipedia[1] e jargon file[2]

    @Articolo:
    > Slackware è conosciuta per essere una distro veloce e stabile, queste caratteristiche derivano proprio dalla scelta di non includere tool grafici di configurazione.

    E in che modo il _non_ include tool di configurazione renderebbe una distro stabile e veloce?😐

    > Scelta che ha consentito anche di ottenere una distro altamente configurabile, al contrario di certe distro user-friendly nelle quali è assai difficile modificare un impostazione per la quale non è stato previsto un tool grafico.

    Anche qua, in che modo dei tool grafici impedirebbero di modificare le configurazioni a mano? :||

    > Inoltre, l’utilizzo di un kernel vanilla rende molto più semplice la ricompilazione dello stesso rispetto ai kernel profondamente patchati di altre distro.
    LoL questa affermazione e’ semplicemente ridicola, in che modo delle patch renderebbero la ricompilazione piu’ difficile?

    @Wiki:

    Interessante come la critica piu’ pesante rivolta a slackware ( cioe’ la non gestione delle dipendeze ) non e’ messa neanche nelle critiche e viene risolta con un “a noi va bene così.” …

    [1] http://en.wikipedia.org/wiki/KISS_principle
    [2] http://www.catb.org/~esr/jargon/html/K/KISS-Principle.html

  4. @asd:
    “E in che modo il _non_ include tool di configurazione renderebbe una distro stabile e veloce?😐 ”
    Non ho detto tool di configurazione, ma tool grafici: veloce perché non devi caricare X e l’ambiente grafico. Slackware non parte di suo in grafica.

    “Anche qua, in che modo dei tool grafici impedirebbero di modificare le configurazioni a mano? :|| ”
    Quando vai a toccare un file di configurazione sotto il dominio di un tool grafico perdi le modifiche fatte quando lo riconfiguri in grafica. Un esempio: la SuSE 9 faceva così. Ammetto che l’articolo riportato non sarà attualissimo però ho visto personalmente quell’effetto.

    “> Inoltre, l’utilizzo di un kernel vanilla rende molto più semplice la ricompilazione dello stesso rispetto ai kernel profondamente patchati di altre distro.
    LoL questa affermazione e’ semplicemente ridicola, in che modo delle patch renderebbero la ricompilazione piu’ difficile?”

    Ridicola? Beh raccontalo a cose come Fedora, dove se usi un kernel vanilla rischi di non fare più funzionare il 40% dei servizi di sistema che sono molto, ma molto legati alle patch applicate a un kernel.

    “Interessante come la critica piu’ pesante rivolta a slackware ( cioe’ la non gestione delle dipendeze ) non e’ messa neanche nelle critiche e viene risolta con un “a noi va bene così.” …”
    Le dipendenze vengono risolte con slapt-get per i pacchetti non di sistema. L’articolo non ha analizzato tutti gli aspetti di slackware, ma solo quelli importanti e fondamentali. Non è un approfondimento. Ho certi pensieri per la testa che già è tanto che ho tolto il tuo commento dalla moderazione e risposto… Tra l’altro con un nick anonimo e un’email altrettanto anonima. Non ho (al momento) voglia di fare articoli dettagliati e tecnici. Se qualcuno mi paga lo farò pure…

  5. Premetto che non avevo e non ho la minima intenzione di offendere o scatenare un flame🙂
    Detto questo:

    > Non ho detto tool di configurazione, ma tool grafici: veloce perché non devi caricare X e l’ambiente grafico. Slackware non parte di suo in grafica.
    _Qualsiasi_ distribuzione puo’ essere configurata in questo modo

    > Quando vai a toccare un file di configurazione sotto il dominio di un tool grafico perdi le modifiche fatte quando lo riconfiguri in grafica. Un esempio: la SuSE 9 faceva così.
    Premettendo anche qua che la suse e’ _il male_🙂 1) un tool che si comporta in questo modo e’ pensato male 2) in ogni caso rimane la possibilita’ di non utilizzarlo, un tool grafico e’ solo uno strumento in piu’ ( poi, come ho detto prima, se e’ progettato bene e’ utile, altrimente e solo di impaccio🙂

    >Beh raccontalo a cose come Fedora, dove se usi un kernel vanilla rischi di non fare più funzionare il 40% dei servizi di sistema che sono molto, ma molto legati alle patch applicate a un kernel.
    Anche qua, la “ricompilazione” di un kernel patchato e uno vanilla hanno la stessa difficolta’ (salvo applicare le patch), per quanto riguarda fedora: interessante, e quali sarebbero questi servizi? le uniche cose che mi vengono in mente sono legate alla virtualizzazione , anche se ormai i kernel vanilla non dovrebbero avere piu’ problemi in quanto e’ stato incluso (quasi) tutto in upstream.

    >Le dipendenze vengono risolte con slapt-get per i pacchetti non di sistema.
    slapt-get che non e’ il tool ufficiale per la gestione dei pacchetti.
    Quindi perche’ non viene integrato e reso ufficiale visto che ormai e’ utilizzato da praticamente tutti gli slackwaristi ( tutti quelli che conosco🙂 ?

    > Ho certi pensieri per la testa che già è tanto che ho tolto il tuo commento dalla moderazione e risposto…o_O Ci mancherebbe, la moderazione nei blog e’ nata per eliminare lo spam e toglire i commenti del tutto fuori logo, ora si sta trasformando sempre di piu’ in forma di censura, le mie sono critiche _non gratuite_ e argomentate.

    > Tra l’altro con un nick anonimo e un’email altrettanto anonima.
    un nick anonimo e una mail anonima rendono meno importante o meno vero cio’ che dico? Se insisti ti posso dare la mia e-mail , ma ti faccio notare che per me kslacky e’ un nick altrettanto anonimo che “asd”🙂

    > Non ho (al momento) voglia di fare articoli dettagliati e tecnici.
    Questo sta solo a te deciderlo🙂

    Senza nessuna intenzione di offendere o generare flame, ASD🙂

  6. @asd:
    tutte le tue osservazioni nascono dal non conoscere a fondo Slackware è la filosofia che c’è dietro. Chi frequenta questo blog e legge gli articoli ci trova precise connotazioni di chi sono e cosa ho fatto, compreso nome, ecc…

    “_Qualsiasi_ distribuzione puo’ essere configurata in questo modo” e io ripeto: Slackware nasce così, per le altre distro devi riconfigurare. Se afferri il concetto KISS allora ti rispondi da solo alle domande. Chi ha creato Slackware (Pat) ci tiene molto a ogni dettaglio della distro e a mantenerla in un certo modo: senza uno strumento che gestisce le dipendenze, senza l’ambiente grafico che parte in automatico, con il kernel vanilla e tutte le applicazioni con meno patch possibili in assoluto… Troppe patch alle applicazioni possono (in alcuni casi) non far compilare più le applicazioni partendo dal sorgente non patchato. Non ricordo quali servizi di Fedora che non andavano, ma in genere compilare un kernel in una distro patched-oriented non è semplice, dove per uno che usa slackware da anni è banale compilare un kernel vanilla. Secondo me… Quindi non c’è nulla su cui dibbattere. Sono punti di vista. Potremmo dibbattere all’infinito, ma la parola è una sola: KISS e proprio punto di vista.

  7. Credo che le cose dette da asd non siano fuori luogo. Il fatto di usare Slackware rimane una questione di feeling come con tutte le altre distribuzioni.

    Se uno vuole imparare può farlo con tutte le distribuzioni. Se uno invece ha tempo e voglia a perdere a risolvere le dipendenze può farlo con la Slackware.

    Io steso l’ho usata, l’ho trovata molto stabile. Tuttavia dover usare pacchetti non ufficiali per la maggior parte dei pacchetti che non sono supportati l’ho trovato una perdita di tempo.

    Se uno non si fida se li deve compilare a mano e risolvere le dipendenze a mano.
    Oppure ti cerchi gli script slackbuild. A questo punto allora trovo l’approccio Archlinux molto più intelligente (ABS).

    Slapt-get è un tool usato ma che non viene incluso nella distribuzione perchè Patrick non vuole cosi. Ho l’impressione che chi usa Slackware e slapt-get non stia poi cosi comodo con la Slackware. Perché se non avrebbe bisogno di usare un tool per soddisfare le dipendenze automaticamente se non perché questo tipo di compito è noioso e più adatto alle macchine.

    Oggi preferisco produrre con la macchina e delegarle i più compiti possibile. Per questo a Slackware preferisco Archlinux che trovo mi da libertà e non mi appesantisce con lavori inutili come dipendenze.

    Vorrei sapere che cosa ne pensi kslacky…

  8. scusate l’orrore di ortografia ^^
    Volevo dire:
    Ho l’impressione che chi usa Slackware e slapt-get non stia poi cosi comodo con la Slackware.
    Trovo che non avrebbe bisogno di usare un tool per soddisfare le dipendenze automaticamente se non perché questo tipo di compito è noioso e più adatto alle macchine.

  9. @passante:
    beh che ti devo dire. Uno strumento interno alla distribuzione Slackware stessa che facesse un po’ di cose nello stile slapt-get e come avviene per FreeBSD coi ports sarebbe utile, addirittura si potrebbe pensare di non compilare le applicazioni ma di avere dei depositi distribuiti esterni dove puoi prendere direttamente il binario (anche di una current di una certa data) se non vuoi compilare. Avere la current è di grande comodità perché con il fatto che tutto viene tenuto semplice, gli aggiornamenti quotidiano non portano rischi di aggiornamento. Funziona da anni che non formatto più il pc e aggiorno sempre e ho software davvero aggiornato. E se uso Slackware è perché mi piace con le sue potenzialità e coi suoi limiti e si avvicina di più a quello che fa per me. Se esistesse pure lo strumento che ti dicevo sarebbe perfetto.

    Chi usa una distribuzione differente da Slackware continuasse a usare altro non è che devo difendere Slackware sia ben chiaro🙂 Se vi incuriosisce Slackware e volete provarla fatelo pure. Io ho espresso una sintesi dei fondamenti di Slack.😀

  10. Come ho detto altre volte riguardo questo argomento, NON sono per niente daccordo.
    Slack e’ stata la mia prima distribuzione, abbandonata definitivamente in favore di debian, perche’ mi ero decisamente rotto le p… di avere a che fare manualmente con tutti i casini delle dipendenze. Detto questo, se uno conosce la shell, conosce GNU/Linux. Al massimo ci sara’ qualche differenza tra le varie distribuzioni su dove mettono particolari file di configurazione. Ma la sostanza e’ quella. Se poi vogliamo dirla tutta, le distribuzioni che aderiscono alla LSB (Linux standard base) sono quelle basate su quel cesso di rpm.
    Alla fine di tutto se proprio uno vuole imparare GNU/Linux, si installa Linux From Scratch (LFS), e ti assicuro che avra’ da divertirsi un mondo…
    Se uno ci deve lavorare con GNU/Linux, non puo’ stare dietro alle varie dipendenze. Forse e’ anche per questo che utenti di slack hanno inventato slap-get? Ed e’ tutto dire, visto che notoriamente gli “slackwaristi” sono ostili proprio verso i “debianisti”.
    Il tutto senza nessuna voglia di scatenare un flame senza fine.
    Ciao

  11. Sono capitato qui per caso, (dall’articolo di un blogger che seguo) ho letto l’articolo e mi sono fatto un’idea di quello che tu, kslacky, volessi dire, e di quello che i tuoi detrattori volessero dire. Posso capire tutte e due le posizioni, veramente, credetemi. Semplicità per la macchina o semplicità per l’utente? (Alla fine non è di questo che si parla?) Tutte e due le soluzioni secondo me funzionano. E se veramente Slackware fosse LA distribuzione, non vorresti che rimanesse tale, evitando la distribuzione di massa? (strada che ha intrapreso Canonical ora e Red Hat ai tempi…, ma solo per fare due nomi.)
    Ma non è per questo motivo che ho deciso di postare un commento. Di solito sono uno di quei “lurker” che si guarda bene dal postare commenti in blog che si visitano per la prima volta. Il vero motivo per cui ho postato questo commento è che leggendo l’articolo e i commenti, mi sono imbattuto in un’infinità di errori grammaticali, sintattici e anche ortografici. Non nell’articolo, ovviamente, ma soprattutto nei commenti, dove si spazia da _piu’_, _e’_, _possibilita’_ con l’apostrofo, anziché con l’accento, l’uso di _è_ al posto della congiunzione _e_, consecutio sbagliate in modo plateale e altre bestialità che non mi va di riprendere. Questo mio commento non vuole essere una critica, ma piuttosto un consiglio (ovviamente non solo a te, ma soprattutto a chi scrive nei commenti), poiché se presentiamo le nostre idee in una forma scadente, la gente non penserà che anche le nostre idee siano scadenti? Un mio professore una volta mi disse “Il Contenuto non può prescindere dalla Forma”. Aveva ragione, e non sai quanto.
    Scusami ancora per questo commento un po’ insolente (davvero non è nelle mie corde), ma sentivo di doverlo scrivere, perchè a mano a mano che leggo cose scritte da persone che si ritrovano nel vostro (e in futuro anche mio) ambiente di lavoro, leggo cose di questo genere, e mi dispiace molto, perché la nostra reputazione dipende _anche_ da questo.
    Ciao, luke.

  12. @lukewebsurfer:
    idee scadenti? Non ho capito se è riferito all’articolo che è sintetico, ai commenti o alle risposte dei commenti…

  13. @lukewebsurfer
    Per quanto che mi riguarda il tuo commento non aggiunge nulla di interessante.
    Buon per te se riesci a scrivere come Manzoni.
    La prossima volta resta sulla scia dell’argomento.

    @lukewebsurfer
    Semplicità per la macchina o semplicità per l’utente?

    Che cosa vuol dire “Semplicità per la macchina”.
    La macchina esegue istruzioni allo stesso modo…che siano complicate o semplici.
    Al livello di assembly per la macchina non cambia nulla se il gestore di pacchetti risolve le dipendenze o meno. Al massimo un gestore di pacchetti come apt o pacman avrà un numero di istruzioni assembly più numerose rispetto ad un pkgtool. Per la macchina questo significa solo più tempo visto che il numero di istruzioni è maggiore. Ma oltre il fattore tempo mi spieghi che cosa cambia per la macchina?

    Se un gestore di pacchetti risolve le dipendenze o meno alla macchina non cambia nulla….cambia all’essere umano che deve svolgere un compito in più.

  14. @peracotta: non è riferito all’articolo, che è ben fatto, né ai commenti, ma in generale. Se tu parlassi con un genio della scienza, e lui parlasse in malo modo, senza farsi capire, diresti ancora che è un genio? Quella frase è solo per far capire che la gente percepisce il concetto che esprimiamo nel MODO in cui lo esprimiamo: cioè o male o bene.

    @passante: l’idea di fondo è che non bisogna scrivere come Manzoni (arcaico e desueto ormai) ma in Italiano (ove possibile) corretto (sempre). E dovrebbe essere la regola, non l’eccezione.
    Per quanto riguarda l’aspetto tecnico, hai afferrato proprio quello che volevo dire: per macchina non intendo il livello assembly, tutti sappiamo che a livello assembly non cambia nulla, ma proprio quelle cose che stanno tra l’assembly e il livello più alto. Chiamalo gestore di pacchetti, chiamalo compilatore, chiamalo come vuoi, ma è quello che deve tradurre dal nostro linguaggio di livello superiore, al linguaggio della macchina. E allora, alleggerire questo livello intermedio per renderlo più semplice da gestire, oppure appesantirlo per rendere la macchina più semplice da usare? Sono le due opzioni che distinguono, in tutti i campi, non solo nei computer, i professionisti dagli amatori.

  15. Per quello che riguarda la lingua non voglio aggiungere altro.

    Non c’entra con questo topic e io credo che sia meglio evitare di continuare a battere il chiodo.
    Come ho scritto nel post precedente buon per te che hai appreso bene la lingua italiana.

    Stiamo in-topic quindi.

    Te la sentiresti di dare dell’amatore a James Gosling?

    Java ha una complessità incredibile al livello intermedio, come interprete, eppure permette di sviluppare velocemente e comodamente come pochi altri linguaggi.

    L’idea è di delegare alla macchina cose che in altri linguaggi come il C devi fare tu stesso (es. gestione memoria). Con java programmare diventa molto più facile ed il codice è facilmente mantenibile, ergo più comodo e veloce per l’essere umano.
    Certo ogni linguaggio ha il suo perché e non sto sputando sul C.

    Anche per i gestori di pacchetti, che devono svolgere operazioni complesse, puoi usare un linguaggio di alto livello e facile da mantenere.

    Questo si traduce in codice mantenibile ma ricco di funzionalità. Non sto dicendo che un gestore di pacchetti andrebbe fatto in java. Ci sono altri linguaggio, compilati o interpretati che si prestano bene al compito.

    Secondo te i professionisti per essere tali devono sempre reinventare la ruota? Oggi il livello intermedio non lo vedi se sei un sviluppatore di applicativi.
    Altro discorso se sei uno sviluppatore di e framework. E anche li ci sono eccezioni…vedi Ruby on Rails.

  16. Mi scuso, ho mangiato una parola nell’ultima frase…volevo dire:

    Altro discorso se sei uno sviluppatore di linguaggi e framework. E anche li ci sono eccezioni…vedi Ruby on Rails.

  17. Scusami, ma allora non ci siam capiti.
    Cosa intendi per “Secondo te i professionisti per essere tali devono sempre reinventare la ruota?” ?
    Non credo assolutamente che Gosling sia un amatore, anzi! Ma quel paragone c’entra come i cavoli a merenda.
    Ho solo detto in termini informatici quello che in un linguaggio meno tecnico suonerebbe come “Il mondo è bello perché è vario”. Intendendo dire che ognuno si ritrova più comodo con cose che ad altri sembrano scomode e viceversa, ovviamente.
    Infatti, Java è sicuramente più user-friendly (che brutta parola, comincio ad odiarla) che C. E, quando dici questo, vieni della mia idea.
    Ma come dici poi in seguito, il “non vedere il livello intermedio” a livello di programmazione di applicativi, non implica che chi programma applicativi non sappia nulla del livello intermedio. Anzi, probabilmente lo deve conoscere meglio di chi programma linguaggi, per farci girare il suo applicativo.
    Certo, poi ci sono le eccezioni come Ruby, e va beh, lo dice la parola stessa, è un’eccezione.
    Per Java e su Java mi piacerebbe dire due cosine, ma non è questo il posto.
    Ciao, spero di averti fatto capire che, a parte piccoli particolari, stiamo dicendo la stessa cosa.


  18. @lukewebsurfer
    E allora, alleggerire questo livello intermedio per renderlo più semplice da gestire, oppure appesantirlo per rendere la macchina più semplice da usare? Sono le due opzioni che distinguono, in tutti i campi, non solo nei computer, i professionisti dagli amatori.

    Ho scritto il post precedente per via di questa frase.

    Che cosa intendi esattamente?
    Quale approccio sceglierebbe l’amatore e quale il professionista?
    È abbastanza ambiguo non trovi?

    Il tizio che ha inventato java ha deciso di aumentare la complessità intermedia per dare la possibilità a chi sviluppa di concentrarsi sul problema e non su come implementare la soluzione. Java nasce dall’esigenza di non doversi preoccupare troppo dei processi della macchina. Ci pensa la macchina virtuale a questo. Se java non ti piace mettici sopra il nome di qualsiasi linguaggio interpretato o compilato just in time.

    Questo è un approccio da amatore?


    @lukewebsurfer
    Ma come dici poi in seguito, il “non vedere il livello intermedio” a livello di programmazione di applicativi, non implica che chi programma applicativi non sappia nulla del livello intermedio. Anzi, probabilmente lo deve conoscere meglio di chi programma linguaggi, per farci girare il suo applicativo.

    Non metto in dubbio che chi programma applicativi non abbia le conoscenze sul funzionamento della macchina a basso livello.
    La realtà è che chi sviluppa in java o in qualsiasi linguaggio interpretato di solito…non ha le conoscenze di chi ha sviluppato l’interprete. O comunque questo è abbastanza raro.

    Questo lo rende amatore o professionista?

    La mia posizione è:
    – La macchina deve fare il lavoro al posto mio. Se devo fare un lavoro ripetitivo e noioso faccio uno script e lo do in pasto alla macchina. Anche la gestione dei pacchetti, dato che è un compito noioso e ripetitivo, va fatta dalla macchina….questo senza che il programma che gestisce i pacchetti ostacoli le scelte dell’utente.

    Forse sono io che non ho capito una mazza ma rileggendo i tuoi commenti non vedo che stai dicendo la stessa cosa. Anzi…mi sembra che non ti sei proprio sbilanciato sulla questione.

  19. @passante: Per intenderci, rispondo secco.

    Alla tua prima domanda: “Questo è un approccio da amatore?” (sul Java)
    Risposta: No, è una soluzione da professionista che rende la vita più facile ad altri professionisti. Non c’entra l’amatore.

    Alla tua seconda domanda: “Questo lo rende amatore o professionista?” (sulle conoscenze di un programmatore di applicativi)
    Risposta: Se ha quelle conoscenze è un professionista serio. Se non le ha è un “bagalone”, come si dice in emiliano🙂

    La mia posizione riguardo a cosa devo fare io e cosa la macchina è uguale identica alla tua.
    Invece, parlando di gestione dei pacchetti la vedo un po’ diversamente, ma di base sono in accordo con te.

    Spero di essere stato chiaro, questa volta. Ciao.

  20. Guarda che la maggior parte degli sviluppatori per software aziendali Java non sanno nulla sul funzionamento di quest’ultimo. Magari dal punto di vista progettuale invece sono dei mostri della madonna. Magari hanno una capacità di astrazione che io e te ci sognamo solamente. A gente cosi tu daresti del “begalone”? Mah…

  21. Ho usato slackware per quasi 5 anni e non posso non essere d’accordo con il post, il modo migliore per imparare le cose è sbatterci la testa fino a farla sanguinare, e slackware è l’ideale per farlo😀
    dopo essermi sbattuto per i primi 4-5 mesi (non poco, direi) il resto è stato tutto in discesa, tanto che ero arrivato a scrivermi i miei slackbuild personalizzati…
    Per quanto riguarda la gestione delle dipendenze, fintanto che ho usato slackware non mi sono mai sognato di utilizzare tool come slapt-get (li vedevo come un controsenso), preferivo perdere tempo a risolverle tutte a mano, poi quando il tempo è iniziato a scarseggiare sono passato a gentoo.
    Tuttavia io concordo con Volkerdig nel non voler mettere un tool per la gestione delle dipendenze, l’esperienza con portage di gentoo mi dice che riuscire a gestire in maniera affidabile le dipendenze è qualcosa di estremamente complesso (non a caso in gentoo ci sono tool come revdep-rebuild per controllare dipendenze rotte da aggiornamenti del sistema), quindi mi sembra sensata l’idea di prediligere la stabilità ad un gestore delle dipendenze che per quanto buono possa essere avrà sempre dei difetti (che andranno a discapito della stabilità generale del sistema).

  22. @doppiavu

    uso Archlinux da diversi anni ormai. Pacman risolve le dipendenze che è una meraviglia. Non ho mai avuto problemi di stabilità o dipendenze rotte. I diffetti li avrà anche pacman come ogni altro software scritto da essere umani. Io comunque non li ho ancora trovati.

    @lukewebsurfer

    Scusami…evidentemente ho perso il senso di misura. ^_______________^

  23. @passante:
    beato te, io con portage spesso e volentieri mi ritrovo a dover ri-emergere mezzo sistema… (anche se la cosa non mi pesa granchè, visto che ci pensa lui…)

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...