Newsgroup: it.comp.os.linux.iniziare
Titolo: Slackware versione

Slackware si è fermata alla versione 14.2 ?

 Slackware si è fermata alla versione 14.2 ?
 
Sì.

 Slackware si è fermata alla versione 14.2 ?
 
infatti risale al 01.07.2016!
 
https://distrowatch.com/index.php?distribution=slackware&release=all&month=all&year=all
 
-- 
JB

 
 
Quindi quasi morta ?

 Quindi quasi morta ?
 
spero di no.
e' stabile e maestosa come una montagna.

 Quindi quasi morta ?
 
Spero proprio di no!!!!
Quale altra distribuzione è così robusta e così flessibile?
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

Il 02/05/19 14:21, Roby ha scritto:

Nel passato c'era Rama che ci aggiornava nel momento del rilascio della 
nuova versione, credo che più o meno a cadenza annuale ne usciva 
sistematicamente una nuova, da un pò non trovo suoi post, forse ha 
cambiato nickname od ha lasciato il gruppo, lui è un fans irriducibile 
di tale distro. Comunque ufficialmente è attiva, come risulta anche da 
distrowatch (
https://distrowatch.com/table.php?distribution=slackware
) 
ed anche su wikipedia portano la nuova versione in via di sviluppo, ma 
ignoro il motivo del ritardo.Io l'avevo installata nel 2014 e 2015.
Saluti
 
-- 
JB

 Io l'avevo installata nel 2014 e 2015.
 
Io la sto usando dal 1996 :-)


 Giovanni
 
Oddio, mi hai fatto venire in mente invece la mia prima distro : 
Mandrake, mi aveva colpito molto, credo nel 2002. Con Slackware ho 
temporeggiato molto ad installarla per via della presunta difficoltà, ed 
in effetti se non avessi saputo che bisognava digitare startx per 
avviare l'ambiente grafico, sarei stato colto dal panico!  Invece nel 
1996 ancora non conoscevo Linux...
 
-- 
JB

 Giovanni
io nel '94, trovata nel cd in una rivista, ero un ragazzino
che casino ho combinato! (ad installarla), prima distro linux, per
configurare X si doveva mettere le frequenze del monitor!
 
come mi sento vecchio
 
-- 
Ciao!
Nobuteru
Jabber ID 
nobu...@jabber.org
 
Download free Jabber client from 
www.jabber.org
 


Il fatto che non venga rilasciata una versione “stabile” dal 2016,
non significa che lo sviluppo sia stato interrotto. Infatti se dai
un’occhiata al changelog del ramo stable vedrai che l’ultimo
aggiornamento  di sicurezza risale a pochi giorni fà:
----------------------------
Fri Apr 26 18:55:10 UTC 2019
patches/packages/bind-9.11.6_P1-x86_64-1_slack14.2.txz: Upgraded.
       This update fixes a security issue:
       The TCP client quota set using the tcp-clients option could be exceeded
       in some cases. This could lead to exhaustion of file descriptors.
       For more information, see:
 
https://kb.isc.org/docs/cve-2018-5743
 
 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5743
 
       (* Security fix *)
-------------------------
Quindi: «Eppur si muove...».
http://www.slackware.com/changelog/stable.php?cpu=x86_64
 
 
 
Inoltre se dai un'occhiata al ramo di sviluppo “current”, troverai
che il progetto è attivo e il lavoro procede con continui rilasci:
Pat ci sta lavorando anche in questi giorni...
 
http://www.slackware.com/changelog/current.php?cpu=x86_64
 
 
 
 
Inoltre, nonostante quasi tre anni siano un periodo effettivamente
troppo lungo, almeno per una destinazione d’uso desktop, tutto
sommato con la mia attuale 14.2 installata non rilevo grossi problemi
o limitazioni.
Poi ovvio che se vuoi compilarti l’ultima versione di alcuni software
che si appoggiano all’ultima versione di alcune librerie, magari
incorri in qualche problemino. Ma per un utilizzo non troppo “esotico”
del sisitema, e grazie al monumentale lavoro che fanno su slackbuilds,
il parco software non manca e a meno che appunto non serva davvero
qualche programma in versione all’ultimo grido, diciamo che non ci si
può lamentare.
AlienBob in qualche post del suo blog suggeriva a qualcuno che
si lamentava del ciclo di rilascio troppo lento, di passare alla
versione “current”. Francamente sì in quel modo si ha un sistema base
molto più recente, però si potrebbero avere problemi di stablità
del sistema (alla fine è sempre una versione di sviluppo da testare)
e inoltre il parco software ufficiale di slackware è piuttosto ristretto
rispetto a quelle che possono essere le necessità di un uso desktop
e per la current si trovano molti meno slackbuilds e molti meno
pacchetti precompilati da terze parti: 
ottenere quindi un sistema corredato di tutte le applicazioni che
servono, partendo da una base current non è così liscio come nel
caso della stabile (per la quale si trova tutto pronto e testato
grazie a reopsitories come quello di alien o appunto SBo).
 
Per news e info varie di prima mano o quasi si può far riferimento
al forum 
linuxquestions.org
 nella sezione slackware. Lascio qua sotto
un link, tanto per fare un esempio, in cui discutono sul tema.
 
https://www.linuxquestions.org/questions/slackware-14/is-slackware-dying-4175642766/page8.html#post5979812
 
 
Il punto è che slackware dipende dal suo leader maximo Volkerding e
solo lui sa quando la prossima stabile verrà rilasciata.
Ovviamente l’aspettativa cresce dopo 2 anni emmezzo, ma alla fine
anche il ciclo di rilascio di debian stabile ad esempio non mi pare
sia troppo più rapido. Certo in quel caso hanno anche il ramo testing
parecchio più attivo e manutenuto dalla community che ricompila tutto
il set di pacchetti e li testa anche sul ramo di sviluppo...
In estrema sintesi, slackware assomiglia più ad una “cattedrale”,
debian è invece fortemente sviluppata sul modello “bazar”. Altri
come arch hanno modelli di rilascio rolling, quindi “continui”.
Insomma ogni modello di sviluppo/rilascio ha i suoi pro e i suoi contro,
slackware può sembrare morente se ci si ferma alle tempistiche di
rilascio delle nuove versioni stabili, però basta dare un’occhiata
ai changelog per capire che non è così:
 
- il ramo stable è mantenuto con frequenti aggiornamenti di sicurezza
 
- il ramo current è costantemente sviluppato con l’introduzione di
  nuovi software, eliminazione di altre scelte precedenti, ecc ecc...
 
A corollario di tutto ciò credo di non sbagliare scrivendo che
anche quando Pat dovesse smettere di sviluppare slackware, ne
nascerebbe subito un fork che ne porterebbe avanti la “filosofia”:
poca automazione, semplicità del sistema di pacchettizzazione,
semplice accessibilità a quanto balla sotto il cofano, stabilità
del sistema ufficiale anche a costo di rilasci un po’ più diluiti.
 
Saluti e...
Good Slack!

 
 
possiamo solo aggiungere che
 
"se conosci slackware allora conosci linux"
 


Già... Poi magari non conoscerai così bene systemd o altre
“sovrastrutture” diaboliche, ma pazienza.  :D


 
Si pazienza, ma quali sono i vantaggi di systemd?
 
È solo una complicazione da mettere in piedi e da gestire.  Ho solo 
avuto esperienze negative ad usarlo.  Va bene se sei un esperto che 
lascia fare tutto in automatico.  Sei per caso un utente di windows?


 lascia fare tutto in automatico.  Sei per caso un utente di windows?
 
Mi fido...
Sì a volte mi capita di dover usare anche windows. Ma tra le prime
cose che faccio, se me lo lasciano fare è configurare quel che si
può in manuale (gli automatismi non mi vanno a genio...).
Sul mio pc mi sono ricavato una installazione XP in macchina virtuale,
visto che lo uso di rado ci può anche stare...
Altre volte mi capita di mettere le mani su qualche pc non mio che
monta sistemi windows, ma sono tutto tranne che esperto, mi arrangio
e quando non riesco e non trovo info, rompo le scatole chiedendo in
giro per la rete.

>
 
Purtroppo systemd c'e' .
non so quante persone lo vogliano, ma purtroppo c'e'.

 Giovanni
 
Saluti!
^Bart

 Giovanni
 
Saluti!
^Bart

e a gestione pacchetti come sta' messa adesso?

 faccio ben volentieri! :)
 
Non voglio convincere nessuno ad usare la Slackware, ma fin dall'inizio 
ho usato linux per supportare ambienti di sviluppo sia sul lavoro sia in 
ambiente casalingo.  La flessibilità di Slackware è impagabile per 
questo scopo e le lamentele che sento su questa distribuzione è che 
sarebbe poco supportata non mi hanno mai preoccupato molto.
 
In realtà sulle mie macchine non c'è una Slackware al 100% ma la 
distribuzione è solo una base su cui io ricreo alcuni pacchetti sia per 
adeguarli alle mie esigenze, sia per mantenere alcune scelte fatte più 
di 20 anni fa.  Il kernel stesso è normalmente aggiornato o anche 
semplicemente ricompilato per includere solo il minimo indispensabile 
per l'hardware presente.
 
Su Virtualbox ho ancora un ambiente di sviluppo per ricompilare 
pacchetti (e ricreare pacchetti adeguati per una Slackware 12.1 - estate 
2013 circa) per un paio di macchine con cpu 486 che ora uso solo per 
divertimento.  Per qualche tempo su quelle macchine ha girato SCO UNIX. 
Integrato in rete ho anche un 286 (anno 1989) su cui gira Minix in 
versione 2000 circa e che mi era servito per sviluppare il filesystem di 
un apparato per il GSM.
 
Da qualche anno, assieme ad un amico che è li docente, seguo la 
manutenzione di un server dell'università.  Su questa macchina vi è una 
Debian ma trovo che non vi è la flessibilità di installare e/o rimuovere 
pacchetti che non siano quelli già presenti nella release installata. 
Proprio perché sono abituato a costruirmi una installazione adeguate 
all'hardware ed ai servizi che mi servono trovo che la rigidità delle 
Debian sia un problema per me.
 
Naturalmente ho installato una Debian prima su virtualbox poi su disco 
ma poi ho rinunciato a questa ultima installazione perché fare prove in 
quell'ambiente è per me troppo distruttivo.  Specialmente systemd è 
difficile da domare (non lo conosco abbastanza probabilmente).  È più 
facile cancellare un file e ricreare la VM che ogni volta reinstallare 
su disco e reintegrare l'installazione nell'ambiente di boot che ho creato.
 
Come vedi la mia conoscenza di linux è iniziata molto tempo fa e la 
Slackware era l'unica scelta disponibile a quei tempi.  Ricordo di aver 
provato una Debian 0.x e una Mandrake che però erano ancora troppo 
immature ed offrivano una scelta di servizi molto ridotta.  Solo qualche 
anno dopo il supporto aziendale concesse l'installazione sui PC 
aziendali in multiboot con Windows delle Mandrake di cui avevano 
acquistato il supporto ma oramai mi ero abituato a Slackware e mi sono 
rifiutato di cambiare perché potevo gestirmelo.  Ne avevo addirittura 
creata una versione che faceva il boot via network e montava un file 
system via nfs per la scheda e la cpu che equipaggiava il sistema per 
gsm su cui lavoravo.  In seguito quella attività ha portato a sviluppare 
le procedure per il caricamento da remoto del sistema.
 
Ripeto non voglio convincere nessuno ad usare la Slackware ma lasciami 
difendere la sua flessibilità e lasciami dire che per un server od un 
ambiente di sviluppo rimane ancora la migliore distribuzione - hem.. 
forse sono un poco partigiano :-)
 
< 
http://giovanni.homelinux.net/
 >


 trovo info, rompo le scatole chiedendo in giro per la rete.
 
La tua esperienza è come la mia.  Forse perché conosco poco Window e 
systemd ho avuto l'impressione che systemd sia fatto per utenti Windows 
che passando a Linux devono trovare tutto pronto in automatico e mai ci 
metteranno le mani lasciando fare tutto all'installer.
 
< 
http://giovanni.homelinux.net/
 >


 forse sono un poco partigiano :-)
 
forse :-)
 
diciamo dipende da che server vuoi fare e quale ambiente di sviluppo vuoi 
ottenere. nella maggior parte dei casi che mi sovvengono senza una 
pacchettizzazione adeguata ci sarebbe solo da mettersi le mani nei 
capelli. vent'anni fa si poteva fare ma era anche un altro mondo.
 

 Si pazienza, ma quali sono i vantaggi di systemd?
 
Dal punto di vista concettuale (non implementativo)
e` sicuramente un passo avanti rispetto ad avere un
mucchio di script scorrelati che devono essere gestiti
a mano, costringendo a sapere esattamente dipendenze,
condizioni varie e simili.
Nel caso di "systemd" tutto e` molto piu` pulito e
lineare, nonche` piu` flessibile.
 
Il problema di systemd, pero`, e` l'implementazione,
o meglio gli sviluppatori.
Questi, spesso e volentieri, credono (o credevano) di
avere la verita` rivelata, per cui diventa difficile,
se non impossibile, far cambiare cose che, per tutti
gli altri utenti non vanno bene, ma sono "giuste" per
gli sviluppatori.
 
Ho avuto una discussione, tempo addietro, al riguardo.
 
Uno di questi se ne e` uscito con frasi "meglio perdere
la storia della shell (NDR: il file .bash_history)
piuttosto che avere uno shutdown lento (NDR: user experience)".
 
Ovviamente con gente che fa ragionamenti simili non si
puo` certo pensare di avere "systemd" come dovrebbe essere.
 
Tra l'altro, questa e`, o spero era, la mentalita` del
gruppo di "freedesktop", che se ne veniva fuori anche con
discussioni similari (avere "gdm", il login manager, che
dipende dal package manager andava bene perche` "the desktop
is a complex web of applications").
 
bye,
 
-- 
 
piergiorgio


 
Tanto per farti un esempio il mio server casalingo.  Ci troverai installato:
1) il web server in firma ed in forma più estesa servizi solo in lan per 
controllo dei log-files
2) mail server per la mia lan che raccoglie tutte le mail da e/o a 
utenti locali - servizio smtp/pop3/imap con accessi ssl e webmail
3) servizio dns per la lan e caching per il mondo esterno, by-passando 
cosi dns pubblici o del provider
4) servizio dhcp (connesso con il dns) per la lan
5) news server accessibile solo da utenti in lan e limitato a news 
groups che devo autorizzare.
6) multimedia server per il TV casalingo
7) samba server per quando il nipote usava Windows
8) servizio ftp per scambiare file (anche se sto pensando di 
disattivarlo verso il mondo esterno)
9) servizio di backup di alcune aree di altri PC (purtroppo mi si è 
guastato il tape drive vecchio di più di venti anni)
 
Come già scritto sto anche lavorando con debian su un server 
all'università e installare openVPN è stato un problema.  Per non 
parlare della configurazione di exim dove ho trovato solo configurazioni 
prestabilite senza possibilità di intervento su certi dettagli che 
volevo implementare per le esercitazioni degli studenti e accessi 
limitati solo dalla rete universitaria.
 
Dopo aver sperimentato con debian (releases dopo la 8) rimango convinto 
che non avrei potuto costruire un server come descritto senza la slackware!


 slackware!
 
stai scherzando, spero :-) ovviamente si può fare, non solo con debian ma 
con tutte le distribuzioni. 
 

 lineare, nonche` piu` flessibile.
 
Più flessibile?  Beato te che lo trovi più flessibile.


 Più flessibile?  Beato te che lo trovi più flessibile.
 
Guarda, io avevo un daemon (servizio) installato
manualmente e fatto partire con i classici script
di SysV.
 
Uno volta funzionante, ho deciso di provare con
"systemd".
Inizialmente ho dovuto capire come si facessero
questi file .service, ma dopo qualche prova, test,
debug, etc., mi sono convinto che sia molto, ma
molto piu` pratico di SysV.
Molto piu` facile e, come scritto sopra, piu`
flessibile.
 
L'attuale file .service e` 1/4 dello script originale,
tanto per dirne una.
 
Certo, bisogna imparare una cosa nuova, ma sicuramente
ne vale la pena, se si devono gestire servizi.
 
bye,
 
-- 
 
piergiorgio

 Più flessibile?  Beato te che lo trovi più flessibile.
 
direi proprio di sì. mi viene in mente ad esempio i servizi user, per me 
utilissimi sulle workstation.
per inciso se preferisci gli script init.d si possono far lanciare e 
gestire a lui.

 ne vale la pena, se si devono gestire servizi.
 
Occhio, stai chiedendo di imparare cose nuove ad uno che ragiona che Slackware
è lo stato dell'arte di Linux e tutto il resto serve a scimmiottare Windows
 
Enrico

 lineare, nonche` piu` flessibile.
 
Oddio, flessibile fino ad un certo punto. Mi dicevano[1] che Systemd ha grossi
problemi a gestire correttamente GFS, tanto che pure IBM ha dovuto alzare 
bandiera bianca[2]
 
Enrico
[1] e me lo diceva gente con le palle, non il primo schiacciatasti qualsiasi
[2] oddio, in realtà non so com'è finita, di sicuro avranno trovato una quadra,
ma di fatto il problema è nato a causa di systemd

 bandiera bianca[2]
 
Punto primo, questo problema e flessibilita`
sono due cose diverse.
 
Secondo, come scritto in precedenza, il vero
problema di "systemd" e` il fatto che gli
sviluppatori pensano di avere sempre ragione.
 
Immagino gia` che vi sia un problema con GFS
e quelli di "systemd" lo dismettano dicendo
che e` un "corner case".
 
bye,
 
-- 
 
piergiorgio

 sono due cose diverse.
 
Tecnicamente no, perché è proprio a causa della mancanza di flessibilità di
systemd che si è presentato il problema (da quello che mi ricordo della storia,
che ricordo mi è stata raccontata da gente Che Ne Sa™, c'era un problema a
causa di come systemd gestiva l'ordine dei mount, che con sysvinit non si
presentava per ovvi motivi)
 
Enrico

 presentava per ovvi motivi)
 
Mah, non so nulla al riguardo, ma come fatto
gia` notare da altri, systemd puo` richiamare
gli script SysV, quindi dubito che il problema
sia cosi` semplice.
 
Senza sapere i dettagli diventa difficile capire
se si tratti proprio di "mancanza di flessibilita`"
od altro.
 
Credo anche, ma non sono sicuro, che RedHat abbia
GFS e credo con systemd.
Magari anche no, non saprei.
 
bye,
 
-- 
 
piergiorgio