Considerazioni su Slackware e alternative

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3257
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Considerazioni su Slackware e alternative

Messaggio da joe »

Ciao a tutti,
forse vi sarete trovati anche voi a fare i conti con un sistema per uso desktop ormai un po' troppo datato. Ovviamente mi riferisco a slackware-14.2 che uscita se non ricordo male nel 2016 ha più di 3 anni. Sì, è stata nel frattempo manutenuta, un po' aggiornata ecc ma contiene parecchi programmi e librerie in versione un po' vecchiotta.
Ora, magari qualcuno di voi si sarà trovato a voler provare un certo software in versione recente e si sarà imbattuto nell'impossibilità di compilarlo o farlo girare sulla nostra slackware stabile.
A me è capitato di recente con Scribus ad esempio, che richiederebbe una versione CMake non supportata da slackware 14.2. Ma è solo un esempio.

Perché allora non utilizzare la "current"?

Fondamentalmente perché se qualcosa non funziona, si fa presto a dire: c'era da aspettarselo da una versione pensata per lo sviluppo slackware.
Ma a livello pratico, il problema è che per la current manca un parco software adeguato all'uso desktop. Soprattutto facendo riferimento a repositories terzi come in particolare SBo, i cui script sono testati e pensati per la versione stabile, e non è assolutamente detto che funzionino sulla current, soprattutto quando la current attuale è di 3 anni più recente rispetto all'ultima stabile.

Ho sempre apprezzato il fatto che slackware stabile viene rilasciata quando è pronta.
Però, a sto giro mi pare evidente che alla battuta sopra sarebbe davvero necessario appendere un corollario, ovvero viene rilasciata quando è pronta... ma se dopo due anni non è ancora pronta serve un piano B, sempre parlando di uso desktop/workstation.

Quale potrebbe essere questo piano B?

Un'idea che però non dipende dall'utente ma da Pat e dal suo gruppo, potrebbe essere quella di puntare a rilasci più frequenti, magari comprimendo il parco software ufficiale, ad esempio lasciando perdere KDE plasma o altri software troppo incasinati per essere integrati senza creare problemi e allungare i tempi, e "appaltare" questa roba a sviluppatori che magari gestiscono già repo esterni, come ad esempio Alien e chi vi contribuisce.

Un'altra idea, ma non troppo lungimirante potrebbe essere quella di proporre ai vari sviluppatori di repo terzi tipo SBo, magari con l'appoggio anche di Pat, di prendere un certo rilascio di "current" (magari indicato come un po' più stabile di altri da Pat) e procedere al testing degli slackbuilds e dei pacchetti, in modo da avere anche per la current lo stesso set di software disponibile sul repo stabile di SBo. Il tutto a cadenza grosso modo fissa, ad esempio 1 anno. Così almeno l'utente potrà scegliere una slackware che seppure non stabile, sarebbe comunque pienamente usabile potendo attingere al vasto parco slackbuilds di SBo. Gli utenti che invece preferiscono la stabile, magari per uso server potranno tranquillamente attendere le tempistiche di Pat (che comunque potrebbe dire, ragazzi guardate che tra due mesi uscirà la prossima stabile, non state a sbattervi con rilasci intermedi). Anche in questo caso purtroppo il problema è che è solo un'idea, ma dipende dagli sviluppatori che contribuiscono al progetto SBo e simili.

Un'ulteriore idea, molto banale, potrebbe essere l'utilizzo di una distribuzione diversa da slackware. Questa seconda opzione è invece ovviamente in mano all'utente.
Sì ma quale diamine di distribuzione scegliere?
Dopo più di un paio di lustri di utilizzo e apprendimento di slackware girano un po' gli zebedei a dover reimparare la ruota. E poi slack gira così bene... è controllabile facilmente ecc ecc, non ha problemi con la creazione di pacchetti, gli slackbuild sono script bash...
E allora la domanda diventa: ma se uno dovesse mollare slack, con quale distribuzione si sentirebbe un po' più "a casa" rispetto ad altre?

ilmich
Master
Master
Messaggi: 1552
Iscritto il: lun 16 lug 2007, 17:39
Slackware: 14.2 64bit
Kernel: 4.19.46
Desktop: dwm
Località: Roma

Re: Considerazioni su Slackware e alternative

Messaggio da ilmich »

ciao è una domanda che mi sono posto anche io ultimamente... non tanto perché Slackware così com'è nn mi vada bene (con la 14.2 per le mie esigenze sono poche le rogne) ma perché ho il timore che prima o poi possa cessarne lo sviluppo (facciamo gli scongiuri del caso)
escludendo le derivate (che hanno poco senso per me) ho provato debian di recente ma da sviluppatore / utente pro ho trovato scomodo la suddivisione dei pacchetti (dev e non)... inoltre la trovo troppo automatica per i miei canoni...

probabilmente dovessi scegliere un giorno provero gentoo o comunque un qualcosa che ti porti in qualche modo ad ottenere un sistema quanto più semplice possibile.

pero fino a quel giorno Slackware nn si molla... per me è la migliore distro in circolazione per utenti avanzati.
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

Avatar utente
Rama
Linux 2.x
Linux 2.x
Messaggi: 368
Iscritto il: sab 29 mar 2008, 12:18
Slackware: current 15/8/20
Kernel: 5.8.2 preemptive
Desktop: KDE 4.14.38
Distribuzione: Debian Buster
Località: Novara, provincia

Re: Considerazioni su Slackware e alternative

Messaggio da Rama »

non avendo esigenze particolari la 14.2 per me va ancora bene, l'unico problemuccio che ho avuto è stato con Calibre: l'aggiornavo in continuazione finché non ha funzionato più e ho dovuto rinculare e fermarmi alla versione 3.47.1;
quanto all'alternativa, fino a qualche anno fa avevo lo strambo hobby di provare le distro e la migliore è risultata Debian stable, che uso ancora come distro di scorta, adesso non saprei, ricordo che le distro avevano la tendenza a migliorare (soprattutto in stabilità: i crash di sistema mi mandano fuori di testa) e Kubuntu era passata da inusabile a discreta/buona;

gian_d
Linux 2.x
Linux 2.x
Messaggi: 269
Iscritto il: mer 16 lug 2014, 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 5.4.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: Considerazioni su Slackware e alternative

Messaggio da gian_d »

Io sono ormai passato definitivamente alla current come sistema predefinito e non mi pento di questa scelta. Il software si aggiorna tranquillamente, l'unico problema che ho è il fatto di avere Qgis a scartamento ridotto perché ancora non sono riuscito ad integrare l'abilitazione di python in runtime. In ogni modo la current è una scelta obbligata dal momento che ormai ho nel sistema più pacchetti installati dagli slackbuilds che quelli rilasciati da slackware, dei cui oltre un terzo non installo neppure. Per il resto nessun problema a parte quello di impegnare un po' di tempo per la manutenzione ordinaria o di incontrare all'occorrenza degli intoppi nella ricompilazione di qualche pacchetto a seguito di aggiornamenti.
Penso che alla fine ci sia un congruo compromesso tra la stabilità della configurazione di una versione che è in continuo aggiornamento e l'aggiornamento stesso. Con altre distribuzioni, dove in teoria ci dovrebbe essere un compromesso migliore, c'è lo scotto da pagare e consiste nell'instabilità derivata da una scarsa conoscenza della distribuzione: quello che mi permetto di fare nella personalizzazione di una slackware è mille miglia più avanti rispetto ad altre distribuzioni e ogni volta che mi allargo un po' di più in un sistema debian like combino sempre pasticci che non riesco a riparare.
In ogni modo la distribuzione alternativa migliore che ho trovato è la debian, che uso anch'io come sistema "di riserva". Tuttavia ho acquisito una mentalità troppo legata alla slackware, per cui non riesco proprio a farne a meno. Quale sarà il futuro? mah, staremo a vedere. In fondo Patrick è più giovane di me di 7 anni quindi presumo che schiatterò prima che la slackware possa scomparire dal panorama delle distro :-D

rik70
Iper Master
Iper Master
Messaggi: 2191
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 64-current
Kernel: 5.4.x
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Considerazioni su Slackware e alternative

Messaggio da rik70 »

joe ha scritto:ma se uno dovesse mollare slack, con quale distribuzione si sentirebbe un po' più "a casa" rispetto ad altre?
Archlinux.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3257
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Considerazioni su Slackware e alternative

Messaggio da joe »

gian_d ha scritto: Io sono ormai passato definitivamente alla current come sistema predefinito e non mi pento di questa scelta. Il software si aggiorna tranquillamente, l'unico problema che ho è il fatto di avere Qgis a scartamento ridotto perché ancora non sono riuscito ad integrare l'abilitazione di python in runtime. In ogni modo la current è una scelta obbligata dal momento che ormai ho nel sistema più pacchetti installati dagli slackbuilds che quelli rilasciati da slackware, dei cui oltre un terzo non installo neppure. Per il resto nessun problema a parte quello di impegnare un po' di tempo per la manutenzione ordinaria o di incontrare all'occorrenza degli intoppi nella ricompilazione di qualche pacchetto a seguito di aggiornamenti.
Il software si aggiorna tranquillamente, dici. Ma a quale software ti riferisci? Pacchetti ufficiali o slackbuilds di terze parti?
Da dove ottieni gli slackbuilds? da SBo? Ma lì a parte il repo sperimentale di ponce sono scripts pensati e testati per la stabile, non è un problema farli digerire alla current? Se non altro un problema di tempistiche (anche tempo-uomo intendo, nel senso che lanci lo slackbuild e si intoppa facilmente qualcosa)?

Per capirci meglio sul tipo di utilizzo del sistema farei riferimento anche al numero di pacchetti installati, ufficiali e non. Quanti ne hai installato? Quanti non ufficiali?
Io basandomi sul fatto che i pacchetti non ufffciali di solito contengono il "build tag" alfabetico ho provato a fare così:

Codice: Seleziona tutto

:~$ find /var/log/packages/ -name "*SBo*"|wc -l
322

:~$ find /var/log/packages/ -name "*alien*"|wc -l
46

:~$ find /var/log/packages/|wc -l
1776

:~$ find /var/log/packages/ -name "*[0-9]"|wc -l
1391

:~$ find /var/log/packages/ -name "*[a-z,A-Z]"|wc -l
385

:~$ find /var/log/packages/ -name "*alien*"|wc -l
46

:~$ find /var/log/packages/|grep compat|wc -l
158

:~$ find /var/log/packages/ -name "*SBo*"|wc -l
322
In sintesi se non ho ceffato qualcosa, sul mio sistema ho:

- 1700 pacchetti in totale
- di cui 320 pacchetti compilati da slackbuilds di SBo
- circa 50 presi da AlienBob
- più circa 160 targati compat, dal repo multilib sempre di Alien

Ok, nel tuo/vostro caso come siete messi?

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3257
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Considerazioni su Slackware e alternative

Messaggio da joe »

Per quanto riguarda Arch, mi pare abbastanza distante da slackware nella gestione di init, c'è systemd (sì ho visto anche artix ma è troppo "piccola", poco parco software credo, poi anche quella è sempre sysv non init come la slack).
Anche la gestione della rete sarà un bel po' differente immagino, sempre visto che si passa per systemd.
Ti dirò per me non è che sia un gran problema alla fine, ci sarà inevitabilmente qualcosa da imparare.
Quello che però vorrei mantenere e questo sì mi pare che arch lo dichiari è una situazioni con pochi automatismi di default. E la possibilità di installare facilmente software anche pacchettizzato direttamente a mano e mi sembra anche in questo caso che PKGBUILD e makepkg di arch possano essere abbastanza facili. Anche se lì il discorso dipendenze va rispettato in modo un po' più preciso quando si crea un pacchetto rispetto ai nostri slackbuilds. Ma sotto questo punto di vista la "non gestione" delle dipendenze di Slack sembra essere un unicum nell'ecosistema linux (correggete se sbaglio).

Debian è ok se tutto fila liscio. Mi sono trovato anni fa a far funzionare una chiavetta internet mobile (mi pare fosse un'olicard o qualcosa di simile). Bé avevo dovuto modificare un modulo del kernel (applicandovi una patch) quindi ricompilarlo e infine installarlo, solo che la versione del kernel necesasria era più recente di quella disponibile sul ramo debian in uso. E allora ricordo che avevo dovuto fare un gran casino per venirne fuori... Con slackware sarebbe stato tutto più facile infatti avevo fatto funzionare quella stessa chiavetta quasi al volo in confronto.

Sia debian che arch hanno qualche rigidità maggiore rispetto a slackware in questo senso, anche se come stiamo vedendo adesso, siccome la Slack stabile è troppo datata anche qui ci scontriamo con una certa rigidità. (poi per carità qualche settimana fa ho messo l'ultimo scribus 1.5.5.qualcosa sulla 14.2, ma per compilarlo ho dovuto mettere una versione nuova di poppler in /opt, siccome su quella vecchia si basava gran parte del software in uso nel sistema. Immaginate bene che non ha funzionato alla prima, e alla fine mi sono ritrovato a chiedere in chat su freenode nel canale scribus e cmake... non esattamente comodissimo anche se alla fine sono riuscito... Ne valeva la pena, direi non esattamente! :D

Il fatto poi di avere un sistema rolling come arch, mi sta anche bene, ma non per aggiornare ogni giorno, e neanche ogni mese!
Non so se si possa usare non aggiornato... Del tipo aggiornarlo solo ogni 3 mesi. O ogni 6 mesi. Se poi si vuole aggiungere un pacchetto questo potrebbe funzionare solo sul sistema aggiornato no? Be' sarebbero domande da chiedere sul forum di arch immagino...
Il ciclo di sviluppo debian per contro non mi dispiace, ma per quel poco che ci ho avuto a che fare, mi è parso un sistema un po' fragile: nel senso che se usi solo precompilati con apt pescati dal repo ufficiale ok una mervaiglia ecc, ma quando devi abbandonare un po' i binari facilmente si incasina tutto e riparare ai danni non è facile come maneggiare degli script di slackware. So che sono stato generico e so che probabilmente i problemi incontrati derivano principalmente dalla mia ignoranza sul sistema debian, ma l'impressione che ho avuto è quella lì.

Come accennavo sarebbe interessante avere un rilascio tipo ogni sei mesi di una slackware current, chiamata per dire "slackware testing", potrebbe essere gestita dalla comunity di sviluppatori/utenti slackware in modo che Pat non ci debba perder tempo e possa star concentrato sulla current come sempre. Insomma un ramo intermedio para-ufficiale: ha come base di partenza una current ma della quale si trovano patch per risolvere bugs e un set di slackbuilds ad esempio su SBo, così da avere un parco software decente. Una cosa del genere porterebbe anche problematiche, forse rallenterebbe anche lo sviluppo della current se tanta gente si interessasse più a questa "testing" che a provare la current. Però tutto sommato potrebbe essere avere anche un senso: pacchetti recenti ma non troppo, sistema di base abbastanza recente da compilare roba nuova con la flessibilità e semplicità di un sistema slackware.

gian_d
Linux 2.x
Linux 2.x
Messaggi: 269
Iscritto il: mer 16 lug 2014, 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 5.4.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: Considerazioni su Slackware e alternative

Messaggio da gian_d »

joe ha scritto: Il software si aggiorna tranquillamente, dici. Ma a quale software ti riferisci? Pacchetti ufficiali o slackbuilds di terze parti?
Da dove ottieni gli slackbuilds? da SBo? Ma lì a parte il repo sperimentale di ponce sono scripts pensati e testati per la stabile, non è un problema farli digerire alla current? Se non altro un problema di tempistiche (anche tempo-uomo intendo, nel senso che lanci lo slackbuild e si intoppa facilmente qualcosa)?
La maggior parte di tratta di slackbuild del repository di Ponce così come sono, ma spesso li adatto per installare versioni più aggiornate. Alcuni li ho fatti io ex novo per installare moduli python richiesti come dipendenze per evitare di installarli con pip/pip3, in pratica riprendo lo slackbuild esistente di un modulo che ha una struttura sostanzialmente simile e lo adatto all'occorrenza. Alcuni pacchetti ufficiali sono installati ricompilando i sorgenti della current, come ffmpeg e QScintilla. Non installo mai pacchetti ricompilati da Alien, Ponce, ecc. perché ho notato che in passato mi davano problemi.
In generale ho qualcosa come quasi 300 pacchetti da slackbuild vari, tutti compilati sul sistema di default e circa un migliaio di pacchetti ufficiali (credo) della current: buona parte di a/ e ap/, tutti i pacchetti di d/, una buona parte di kde/, tutti i pacchetti di l/ (eccetto QScintilla, ricompilato, e ffmpeg installato da slackbuild riadattato), buona parte di x/ e solo una piccola parte di n/ e /xap

Il software grafico è principalmente basato su quello di KDE oppure installato da slackbuild: libreoffice e altro software per automazione office, vlc, blender, qgis, virtualbox, tesseract con gimagereader, audacity, inkscape, avidemux, ecc. alcuni front-end di sviluppo (codeblocks, poedit, bluefish), più vari applicativi che sono installati come dipendenze opzionali di blender, qgis e vlc (in pratica tutti o quasi).

I problemi incontrati sono relativamente pochi rispetto alla mole. Spesso riesco ad installare versioni più aggiornate rispetto al repository di ponce oppure se incontro problemi riesco spesso a superarli cercando individuando la causa e intervenendo con qualche patch fatta ad hoc oppure trovata in rete, eventualmente adattata. Chiaramente non è farina del mio sacco, quasi sempre mi appoggio a quello che trovo in rete oppure chiedo aiuto, ma solo dopo aver constatato di non riuscire solo con le mie risorse. Per fare questo lavoro ci metto un po' di pazienza, ma sono entrato nell'ottica dell'opensource: a fronte di un problema studio la struttura dei sorgenti e cerco di capirne la logica in modo da individuare i punti critici in cui intervenire. Ovviamente nei limiti delle mie competenze, che non sono granché. Ma per me è anche strumento di studio, dal momento che sto studiando C/C++ e sto iniziando a farmi intrigare da python.

Vale la candela? nella mia sfera direi di sì perché nell'ultimo anno, da quando ho fatto un salto razionale alla current, ho imparato molto di più di quello che ho imparato in oltre 15 anni di utente slackware. I problemi che incontro non sono più frustranti ma diventano una sfida. E con un po' di pazienza e di problem solving riesco in un modo o nell'altro a superarli uno dopo l'altro. Queste sono le ragioni per cui non ho alcuna intenzione di tornare al torpore della stabilità della 14.2 e tanto meno di smuovermi dalla slackware per ricominciare da capo con un'altra distribuzione, dato che finalmente ne ho acquisito pienamente la filosofia.

E tutto questo si svolge sul sistema che uso per il lavoro, per gli hobby, per l'intrattenimento e per il cazzeggio. Cosa affatto non trascurabile visto che stiamo parlando di una versione testing! Le altre distribuzioni installate, su partizioni dedicate o su macchina virtuale, le uso all'occorrenza solo per motivi di "studio".

gian_d
Linux 2.x
Linux 2.x
Messaggi: 269
Iscritto il: mer 16 lug 2014, 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 5.4.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: Considerazioni su Slackware e alternative

Messaggio da gian_d »

joe ha scritto: Il ciclo di sviluppo debian per contro non mi dispiace, ma per quel poco che ci ho avuto a che fare, mi è parso un sistema un po' fragile: nel senso che se usi solo precompilati con apt pescati dal repo ufficiale ok una mervaiglia ecc, ma quando devi abbandonare un po' i binari facilmente si incasina tutto e riparare ai danni non è facile come maneggiare degli script di slackware. So che sono stato generico e so che probabilmente i problemi incontrati derivano principalmente dalla mia ignoranza sul sistema debian, ma l'impressione che ho avuto è quella lì.
Abbiamo la stessa percezione. Debian è un signor sistema, ma se esci un po' dai suoi binari la incasini in pochi giorni. E una volta incasinata non ne esci più. Non parliamo delle derivate. Sul computer di mia moglie ho una ubuntu 14 personalizzata nell'interfaccia grafica per uscire da quella schifezza di unity, ma guai a fare una piccola modifica perché non ne esco più. Ho provato Mint ma in sostanza non cambia nulla, si tratta di una Ubuntu rivista nell'interfaccia grafica. Alla fine nulla a che vedere con la Debian in termini di benefici/costi almeno per chi ne mastica qualcosa. Con Fedora et similia ho chiuso molti anni fa, sia per le frustrazioni che ho accumulato con la Red Hat (anche se allora ero un niubbo) sia per una cavolata che mi aveva combinato Fedora sulla tabella delle partizioni in una installazione in dual boot. Arch e Gentoo sono universi a me sconosciuti perché non ho mai avuto a che farci.
joe ha scritto: Come accennavo sarebbe interessante avere un rilascio tipo ogni sei mesi di una slackware current, chiamata per dire "slackware testing", potrebbe essere gestita dalla comunity di sviluppatori/utenti slackware in modo che Pat non ci debba perder tempo e possa star concentrato sulla current come sempre. Insomma un ramo intermedio para-ufficiale: ha come base di partenza una current ma della quale si trovano patch per risolvere bugs e un set di slackbuilds ad esempio su SBo, così da avere un parco software decente. Una cosa del genere porterebbe anche problematiche, forse rallenterebbe anche lo sviluppo della current se tanta gente si interessasse più a questa "testing" che a provare la current. Però tutto sommato potrebbe essere avere anche un senso: pacchetti recenti ma non troppo, sistema di base abbastanza recente da compilare roba nuova con la flessibilità e semplicità di un sistema slackware.
Mah, da come la vedo io, il sistema attuale basato sulla current, sul repository di Ponce e sull'impianto grafico di base di KDE 4 è già stabile di suo. I problemi saltano fuori più che altro se si esce dai binari e si rincorre il software degli ultimissimi aggiornamenti. Gli slackbuild del repository sono basati su una configurazione sufficientemente stabile, perché il software che installano non è aggiornato all'ossessione: i vari mantainer si mantengono sufficientemente in linea con gli slackbuild del repository di SBo e gli adattamenti alla current non seguono perciò una corsa forsennata all'aggiornamento.

Per fare un esempio, la versione di Qt5 installabile dal repository di ponce è ancora ferma alla 5.9.8. So che David, il mantainer, sta lavorando su un aggiornamento alla 5.12.0, infatti mi ha chiesto di testare lo slackbuild, solo che non riesco a venirne a capo a causa di un errore in compilazione che non riesco a risolvere. D'altra parte sono riuscito a compilare senza troppi patemi la 5.13.2 aggiornando anche PyQt5 alla 5.13.2 e QScintilla alla 2.11.4 compatibilmente con la versione 4.19.20 di Sip. L'integrazione tra le librerie sembra OK, non sono passato all'aggiornamento definitivo solo perché salta fuori un errore di ricompilazione di Qt5-webkit a cui non voglio ora dedicarci tempo. Purtroppo lo sviluppo del software rilasciato da Riverbank e da Qt seguono una linea tutta loro creando non pochi problemi all'aggiornamento di tutto il software basato su queste librerie. Penso poi che qualche miglioramento ci sarà nei prossimi mesi quando alla fine la cessazione del supporto a Python 2 costringerà un po' tutti a passare definitivamente a Python 3.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3257
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Considerazioni su Slackware e alternative

Messaggio da joe »

Intanto ti ringrazio davvero per la tua spiegazione, era quello che mi serviva! :thumbright:
Direi che grosso modo anche io utilizzerei il sistema come te, almeno come numero di pacchetti ecc... Per cui potrei valutare la cosa. Se in più usi il sistema "in produzione", la tua testimonianza vale doppio.
Mi resta da appurare quanto tempo ti porta via la gestione dell'ambaradan, ma credo che se non aggiorni con eccessiva frequenza non si abbiano parecchi grattacapi una volta sistemato il sistema di base e installati i pacchetti extra da slackbuilds.

A questo proposito ti chiedo come ti relazioni ai frequenti aggiornamenti del ramo current:
  • ]
  • aggiorni a cadenza menisle, bimestrale, semestrale?
  • a cadenza settimanale?
  • resti sul pezzo e aggiorni nonappena Pat rilascia un aggiornamento in changelog?

gian_d
Linux 2.x
Linux 2.x
Messaggi: 269
Iscritto il: mer 16 lug 2014, 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 5.4.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: Considerazioni su Slackware e alternative

Messaggio da gian_d »

joe ha scritto:Intanto ti ringrazio davvero per la tua spiegazione, era quello che mi serviva! :thumbright:
Direi che grosso modo anche io utilizzerei il sistema come te, almeno come numero di pacchetti ecc... Per cui potrei valutare la cosa. Se in più usi il sistema "in produzione", la tua testimonianza vale doppio.
Mi resta da appurare quanto tempo ti porta via la gestione dell'ambaradan, ma credo che se non aggiorni con eccessiva frequenza non si abbiano parecchi grattacapi una volta sistemato il sistema di base e installati i pacchetti extra da slackbuilds.

A questo proposito ti chiedo come ti relazioni ai frequenti aggiornamenti del ramo current:
  • ]
  • aggiorni a cadenza menisle, bimestrale, semestrale?
  • a cadenza settimanale?
  • resti sul pezzo e aggiorni nonappena Pat rilascia un aggiornamento in changelog?
In media ogni 4-5 giorni, dipende dai periodi: in certi periodi quotidianamente, in altri periodi dopo al massimo una decina di giorni

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3257
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Considerazioni su Slackware e alternative

Messaggio da joe »

Quindi in pratica resti circa aderente alle tempistiche del changelog di Pat se ho ben capito... Ma con una frequenza così alta, ad ogni aggiornamento ricompili anche tutti i pacchetti installati con gli slackbuilds?
Immagino di no, e spero che nella maggior parte dei casi l'aggiornamento non mandi a scatafascio tutte le dipendenze dei pacchetti compilati sul sistema. Sbaglio?

gian_d
Linux 2.x
Linux 2.x
Messaggi: 269
Iscritto il: mer 16 lug 2014, 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 5.4.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: Considerazioni su Slackware e alternative

Messaggio da gian_d »

Immagini bene. La necessità di ricompilare capita soprattutto quando si aggiorna il kernel: in quel caso devo ricompilare i moduli di virtualbox e del driver nvidia (uso quello proprietario). In altri casi è necessario ricompilare quando si aggiornano determinate librerie e la cosa riguarda solo alcuni pacchetti.
In principio pensavo che fosse necessario ricompilare a cascata anche tutto il software dipendente, in realtà ho visto che spesso non è necessario. Ad esempio, di recente ho dovuto ricompilare qt5 in seguito all'aggiornamento di un pacchetto della current, non ricordo quale. Ovviamente tutto il software dipendente da Qt5 non girava più. Ma è bastato ricompilare Qt5 senza ricompilare tutto il resto. La ricompilazione è invece necessaria, ovviamente, quando si aggiorna la versione di una dipendenza.

Devo dire che in principio l'idea di questi aggiornamenti frequenti mi spaventava, soprattutto per la ricompilazione di pacchetti impegnativi come Qt5, opencv, wx-widget ecc. In realtà poi ho scoperto che la ricompilazione procede velocemente se nella precedente è stato usato ccache.

Per il resto, come hai detto, sto ai tempi del changelog di Pat: ogni giorno mi collego e vedo cosa è stato aggiornato e decido - a seconda del contesto - se scaricare oppure rimandare al giorno successivo. Faccio tutto a mano: download dal browser in una directory dedicata e al termine lancio il comando upgradepkg *txz
Se faccio quotidianamente, tutta l'operazione richiede in genere una decina di minuti al massimo. Mi ripropongo sempre di impostare un tool per l'automatismo, tipo slackpkg, ma alla fine mi sono abituato a fare così e per pigrizia persisto nel fare tutto a mano :-D

gian_d
Linux 2.x
Linux 2.x
Messaggi: 269
Iscritto il: mer 16 lug 2014, 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 5.4.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: Considerazioni su Slackware e alternative

Messaggio da gian_d »

ad esempio, mi sono collegato poco fa sul changelog e ho scaricato dieci pacchetti fra quelli rilasciati negli ultimi due giorni (27-28 dicembre) tra cui gli aggiornamenti del kernel. Quando scarico il kernel impiego un po' più di tempo perché non ho una connessione velocissima, comunque ho impiegato una decina di minuti. Adesso sta girando upgradepkg, anche in quel caso impiega un po' di tempo per il sorgente del kernel deve essere rimossa un bel po' di roba. In tutto c'è voluto circa un quarto d'ora. Adesso ci vorranno circa 5 minuti per ricompilare (in contemporanea) i moduli di virtualbox e del driver nvidia. In totale una ventina di minuti.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3257
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Considerazioni su Slackware e alternative

Messaggio da joe »

Bene, diciamo che non mi hai convinto troppo...
Soprattutto perché non ricordo quanta roba ha in meno il repo di Ponce rispetto al repo stabile di SBo.

Inoltre io sono approdato da troppo a tool come slackpkg+ che uso abitualmente per tenere aggiornati, cercare e aggiungere pacchetti ufficiali e di terze parti, nonché sbopkg e sqg per pescare da gli slackbuilds di SBo. Niente browser da anni!

Mi servirebbe un dual boot così da dedicarne una partizione alla current e vedere come mi ci trovo, se poi sono rose... fioriranno, altrimenti considererò fortemente la possibilità di provare Arch, che alla fine mi pare la più simile per tanti aspetti a Slack. E ho visto che i "rilasci" hanno la stessa cadenza dei rilasci dei kernel stabili, quindi tipo 2 o 3 mesi.
Il problema è che ho dei dischi un po' pienotti... e un solo SSD, ma fore dovrei riuscire a spostare della roba stoccata in un HDD da 2TB con un po' di spazio libero.
Vediamo...

Comunque vada grazie mille per le risposte e se avete qualche altra considerazione sarà senz'altro interessante leggervi! Non fate i timidi! :)

Rispondi