Slackware 12.1 RC2, a giorni il rilascio finale
pubblicato: martedì 22 aprile 2008 da Hispanico in: OS GNU/*/Linux Slackware Linux 
Ultimo passo per il progetto di sviluppo della nuova versione della famosa distribuzione che, a detta di Patrick Volkerding, con questa RC2 dovrebbe ricalcare esattamente quanto si vedrà nell’ormai imminente rilascio finale.
I cambiamenti rispetto alla prima release candidate sono pochi, il che conferma il fatto di come ci troviamo dinanzi ad un buonissimo lavoro svolto; da segnalare la scelta del kernel 2.6.24.5 e l’introduzione dell’ultima versione del ramo di sviluppo di KDE 3.
Infine, come si può leggere dall’ultimo changelog, è ora possibile installare Slackware anche via rete attraverso i protocolli HTTP e FTP.
Via | Distrowatch
Articoli simili
Argomenti Simili
Gallerie Correlate
Commenti dei lettori
(Inserisci un commento - Nascondi commenti anonimi)
In evidenza
Salvatore 'antirez' Sanfilippo,… 24 feb 2010
Panopticlick, quanto siete unici… 31 gen 2010
I giochi di ossblog
Chi ha il merito di aver diffuso… 17 giu 2008
La distro migliore! 16 giu 2008
Ultime Segnalazioni
Vedi tutte le segnalazioniRSS syndication
Iscriviti al feed rss di ossblog
I più commentati della settimana
I più letti della settimana
Pubblicità
Sei interessato a promuovere la tua attività su ossblog?
Pubblicità su Blogo.it.
Archivi
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967
© 2004-2010 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su ossblog contattare la concessionaria esclusiva DadaAd. Il performance advertising è gestito da Simply.com.
Musica in mp3 su Dada, hosting e domini su Register.it, aziende.it
hellview
22 apr 2008 - 11:18 - #1ho tenuto la slack aggiornata alla current per tutto il passaggio alla nuova versione e devo dire che è veramente stabile, grande patrick !!
lampyris
22 apr 2008 - 16:53 - #2peccato la mancanza di un gestore pacchetti.
Al di là delle critiche che riceverò con questa affermazione, credo sia uno strumento indispensabile, soprattutto in ambito produttivo, dove non hai molto tempo da perdere
acrive
22 apr 2008 - 19:13 - #3Io oramai ho abbandonato slack per Archlinux. Non se ne può più di sporcare il sistema con pacchetti creati da piccole (ma validissime) comunità.
Provate pacman i PKGBUILD e abs…. altro che swaret e slackbuild…
hellview
22 apr 2008 - 20:08 - #4@acrive basta farsi i pacchetti da soli e bene …
lampyris
22 apr 2008 - 20:08 - #5@acrive: ho usato arch per molto tempo, non so se ora la situazione sia cambiata, ma fino a poco fa metà pkgbuild in abs non compilavano. E in stable passavano pacchetti corrotti, rimanendo in stable per circa 2 mesi dopo ripetute segnalazioni (e parlo di xfce, non di sw secondari)
Infrid
23 apr 2008 - 08:14 - #6@lampyris
è sempre stato così :D
il mondo è bello perché vario, ci sono tante altro distribuzioni lì fuori con i migliori gestori di pacchetti :)
hellview
23 apr 2008 - 08:42 - #7imho la gestione dei pacchetti su slackware va benissimo cosi com’è
acrive
23 apr 2008 - 08:42 - #8Ma perchè dovrei farmi i pacchetti da solo? In arch esiste un bel repository centralizzato dove tutti i pkgbuild (migliori per la gestione delle dipendenze) hanno un fattore comune, e non sono personali interpretazioni.
E poi… in slack la gestione dei pacchetti avviene ancora via software di script in bash con tutta la lentezza del caso a differenza di pacman.
A ognuno il suo. Per le mie esigenze a questo punto preferisco Arch.
passante
23 apr 2008 - 10:15 - #9acrive…io condivido il tuo punto di vista.
Io ho usato per qualche tempo Slackware ma dover risolvere le dipendenze e le dipendenze delle dipendenze a mano non fa per me.
In Arch ho trovato anche io l’equilibrio che hai trovato tu. ABS è una manna per le ottimizzazioni.
Pacman semplice ed efficace. Mai avuto problemi di dipendenze o rotture. Slapt-get e Swaret li ho provati entrambi…ma nessuno dei due è all’altezza di pacman.
Agli utenti Slackware la distribuzione va bene cosi…amen…l’importante è poter scegliere.
gegbdbv
23 apr 2008 - 10:19 - #10anche arch dovrebbe usare bash per la gestione dei pacchi.
almeno cosi leggevo tempo fa quando mi interessava arch.
passante
23 apr 2008 - 10:36 - #11@gegbdbv
in realtà visto che il fondatore (Judd Vinet che ha anche scritto pacman) della distribuzione si è ritirato si era aperta una discussione sul refactoring di pacman. Pacman è scritto in C ma si pensava di adottare un’altro linguaggio per facilitare lo sviluppo. Bash era uno dei suggerimenti, qualcuno ha suggerito anche python. Io credo che Judd abbia fatto bene a scegliere C. Io non mi affiderei a linguaggi interpretati per un gestore di pacchetti. Almeno si ha un eseguibile che non dipende da nessun interprete. Ma queste sono scelte progettuali con vantaggi e svantaggi. Io spero che mantengano il C o comunque che rimanga un programma compilato.
gegbdbv
23 apr 2008 - 11:53 - #12@passante: vero, non ci avevo mai pensato, ma in effetti è bene che il package manager sia un programma a sé, forse potrebbe essere bene linkarlo pure staticamente, cosi’ si è sicuri che va e vada sempre.
(magari ho detto una stupidaggine, non sono un esperto di ste cose)
ciao a tutti.
passante
23 apr 2008 - 12:08 - #13non capisco perché mi abbiate assegnato punti negativi…
^________________^ la cosa mi fa sorridere….
Non mi sembra di essere stato maleducato…ho espresso il mio punto di vista in maniera molto pacata e civile. Solo acrive mi batte in quanto a punti negativi…che sia perché la pensa come me?
Dai coraggio…potete fare di meglio. Voglio almeno un -5.
Senza rancore…sto solo scherzando…capito? ;)
passante
23 apr 2008 - 12:12 - #14@gegbdbv
no problem…nessuna stupidaggine…bash era una delle proposte ;)
gegbdbv
23 apr 2008 - 12:44 - #15notavo anche io la cosa dei punteggi, secondo me è una cosa ridicola.
non servono a molto, e per di più spesso sono dati in maniera molto infantile, ho dei negativi anche io e nel mio commento non dicevo nulla se non un “mi pare…”
per me si potrebbero benissimo togliere.
oplix
23 apr 2008 - 13:04 - #16 (nascondi)Ma che senso ha usare ancora Slackware da quando c’è Ubuntu?
hellview
23 apr 2008 - 14:26 - #17@oplix è uno scherzo ?
jimme
23 apr 2008 - 18:50 - #18Io credo che Judd abbia fatto bene a scegliere C. Io non mi affiderei a linguaggi interpretati per un gestore di pacchetti.
—
Anche Yum, il packet manager di RedHat/Fedora, è fatto in Python.
Tralasciando il discorso sulla produttività, la facilità di estenderlo e di mantenerlo, il punto è che statisticamente hai molte piu possibilita tu di scrivere errori facendo tutto il packet manager in C che non di trovare un errore nell’interprete di Python.
L’interprete è uno e uno soltanto, viene usato e controllato da molti occhi, se c’è un errore basta coreeggerlo una volta ed è corretto per sempre e per tutti.
Mentre quando inizi un programma in C devi ricominciare daccapo ogni volta, e in C è molto piu facile commetetre errori che non inn Python.
Inoltre, cosi come ritieni plausibile la possibilità di trovare un bug sull’interprete Python, allo stesso modo dovresti temere di trovarne uno sul compilatore C con cui compili il programma. Anzi, a maggior ragione,visto che un compilatore C è molto piu complesso di un interprete per un linguaggio di scripting, e quindi piu soggetto a bug.
passante
23 apr 2008 - 20:31 - #19@jimme
certo…anche il tuo è un punto di vista interessante. Dipende anche da come programmi non trovi?
Anche con python puoi fare errori e considera che hai anche il layer del interprete che può avere bachi.
Ci sono vantaggi e svantaggi in entrambe le scelte credo. Io preferisco che il package manager…che ricordiamolo è un pezzo importante di una distribuzione…non dipenda da interpreti ma sia indipendente il più possibile. Dal mio punto di vista è meglio, trovo.
Credo che anche Judd abbia scelto un linguaggio compilato per lo stesso motivo.
La scelta di programmi interpreti o compilati è un bel dibattito comunque.
passante
23 apr 2008 - 20:49 - #20@jimme
Poi…riguardo al compilatore….devo ammettere che non mi intendo tanto di compilatori da ammetere che siano più complessi di un interprete. Anche qui credo che dipenda molto.
Considera che la maggior parte del kernel linux è scritto in C ed è compilato con gcc e non mi sembra che abbiamo sti grandi problemi.
Altro esempio…estremo è vero…ma non so se sia più complessa una JVM o gcc.
Considera anche che l’interprete di python è scritto in C e quindi complato con gcc.
gegbdbv
24 apr 2008 - 07:26 - #21io pensavo la scelta fosse anche motivata dal fatto che se ti trovi un’installazione di python corotta, per un qualunque motivo, il packet manager non può può funzionare per risolvere quel problema e hai potenzialmente il sistema sotto scacco, o no?
passante
24 apr 2008 - 08:16 - #22@gegbdbv
con dipendere da un interprete intedevo anche quello…dipendere da un interprete equivale non poter usare il package manager se l’interprete ha qualche problema.
jimme
24 apr 2008 - 13:56 - #23E vero che anche in Python si possono comemttere errori, come in qualunque altro linguaggio, ma è anche vero che un linguaggio ad alto livello come Python gestisce in automatico centinaia di aspetti a basso livello, come la gestione manuale della memoria, che sono la causa principale della maggior parte dei bug. Buffer underflow, segmetation fault, sono solo brutti ricordi.
La complessita è da valutare caso per caso, l’interprete Python è molto semplice ed essenziale, ad esempio non usa il JIT e gestisce i thread come child del processo dell’interprete, per rendere piu semplici le cose, anche a scapito della velocità.
Gli sviluppatori di Python possiedono delle test suite per verificare se un’implementazione dell’interprete rispetta le specifiche di Python oppure no, se ci sono malfunzionamenti è molto probabile che vengano rilevati subito.
Le moderne versioni versioni dei compilatori GNU sono molto evolute, piene di funzionalità, pero sono anche molto complessi.
Per python devi sperare che non ci siano errori nell’interprete, e che sia installato correttamente.
Per C invece devi sperare che non ci siano errori nel compilatore e che le librerie standard del C siano installate correttamente (visto che non è una buona idea linkarle staticamente).
Ci sono pro e contro da entrambe le parti. In realta sia Python che GCC sono maturi e collaudati, entrambi hanno piu di 17 anni sulle spalle, per cui si puo andare sul sicuro con entrambi.
gegbdbv
24 apr 2008 - 14:36 - #24jimme grazie.
fedora mi incuriosisce sempre di più.
ero passato per redhat circa dieci anni fa :-)