Slackware to Archlinux

[notsafe]

Quotando Bart vorrei chiedere se slackware è una buona distro per un server e perchè?

forse per un semplice LAMP senza pretese.Ma in ambito enterprise e/o di produzione "serie",no,Slackware non è una buona scelta

[pino_otto]

perche' non e' una buona scelta?

[ilmich]

forse per un semplice LAMP senza pretese

secondo me va bene pure in un contesto cloud.. però li' in effetti il sistema deve soddisfare esigenze diverse

[notsafe]

a parte i "soliti noti" (assenza di tool di gestione "veloci&comodi&potenti",assenza di un package manager evoluto,assenza di PAM etc), ci sono alcuni altri aspetti che hanno un importanza notevole in sistemi di produzione,ad esempio il sistema di "security update": Pat rilascia sempre l'ultima versione stabile,non eseguendo (se non in rari casi) un backport patching;questo è potenzialmente "pericoloso" in quanto aumenta la possibilità di trovarsi in situazioni di incompatibilità (soprattutto se il server è configurato ad hoc per un certo tipo di applicazione/servizio)

[ilmich]

Pat rilascia sempre l'ultima versione stabile,non eseguendo (se non in rari casi) un backport patching;questo è potenzialmente "pericoloso" in quanto aumenta la possibilità di trovarsi in situazioni di incompatibilità (soprattutto se il server è configurato ad hoc per un certo tipo di applicazione/servizio)

Offtopic: potresti farmi un esempio pratico per favore?!?! te lo chiedo perchè sto lavorando ad un applicazione web distribuita fatta da tanti server con slackware 12.1 (questa versione per ora passa il convento.. magari quando passeremo a nodi reali e non virtuali le cose saranno diverse) e vorrei capire meglio in che guai mi posso trovare, visto che comunque pensavo che dove non arriva il buon Pat, ci posso arrivare io compilando le versioni aggiornate

[Plaoo]

Offtopic: Stiamo andando troppo OT ho deciso di aprire un altra discussione, visto che a quanto pare, l'argomento è interessante. Thread viewtopic.php?f=3&t=34716

[fgcl2k]

Pat rilascia sempre l'ultima versione stabile,non eseguendo (se non in rari casi) un backport patching;questo è potenzialmente "pericoloso" in quanto aumenta la possibilità di trovarsi in situazioni di incompatibilità (soprattutto se il server è configurato ad hoc per un certo tipo di applicazione/servizio)

Offtopic: potresti farmi un esempio pratico per favore?!?! te lo chiedo perchè sto lavorando ad un applicazione web distribuita fatta da tanti server con slackware 12.1 (questa versione per ora passa il convento.. magari quando passeremo a nodi reali e non virtuali le cose saranno diverse) e vorrei capire meglio in che guai mi posso trovare, visto che comunque pensavo che dove non arriva il buon Pat, ci posso arrivare io compilando le versioni aggiornate

Cosa intendi per "situazioni di incompatibilità" se "il server è configurato ad hoc per un certo tipo di applicazione/servizio"? Anche secondo me un esempio renderebbe più chiaro il concetto.

[notsafe]

ho riportato un esempio sulla nuova discussione.

[sunreal]

Nell' ultimo mese ho provato arch, sia i686 che x86_64. L'installazione rispetto a quella di slack è abbastanza più complessa, io per lo meno ho dovuto sempre installare il sistema base, perchè tutte le volte che provavo ad aggiungere altre cose non riuscivo a risolvere tutte le dipendenze, poi una volta installato il sistema base ho dovuto installare alsa, xorg, i driver nvidia e xfce. Su 4 installazioni una volta ho avuto il problema che xorg non si avviava. Poi ho iniziato a utilizzare il sistema e debbo dire che la fase di boot è stupefacente (grazie anche a networkmanager che avvia la scheda di rete in un decimo del tempo del tool di default) il pc parte a razzo e debbo dire che ho notato differenze di prestazione tra la versione i686 e la 64bit (su slack no). Poi, però, sono iniziati i problemi, le tre stampanti che ho e che su slack funzionano regolarmente su arch invece funzionano 1 su tre sempre, la seconda che in una installazione precedente era riconosciuta con un driver ancora più preciso di quello di slack, l'ultima volta non c'era nell' elenco delle stampanti anche se cups la trova regolarmente. L'altra un epson che ha bisogno dei drivere avasys non viene affatto rilevata da cups. Per installare picasa ho dovuto installare kde (questo forse potrebbe avvenire anche su slack, non ho mai provato). Ad un certo punto se modificavo l'icona di default di una applicazione (tipo libreoffice calc o konsole) quella applicazione mi scompariva dal menu principale. Thunar non riconosce nessuna delle partizioni che ho sul pc, fortuna che uso krusader. Insomma problemi che con slack non ho mai avuto. In compenso pacman e/o yaourt sono fantastici, ed il sistema anche se non l'ho usato moltissimo non ha mai dato la sensazione di barcollare è sembrato bello solido.Per non parlare del fatto che in pratica non ci sarà mai bisogno di aggiornare tutto il sistema, BELLISSIMO!!! Ma c'è una cosa che in tutti questi anni mi ha tenuto legato a slackware e che nessuno possiede SLACKY.EU!!!! Purtroppo la disponibilità e la competenza di questo forum, archlinux.it se la può scordare, e per un principiante (di archlinux) la cosa non è di poco conto. Comunque secondo me arch è la miglior distribuzione che ho provato, ad eccezione di slackware, e pur essendo per molti aspetti migliore, per ora sono tornato all'ovile caldo e sicuro di slack.
Ciao.

[Infrid]

Anche io usavo Slackware.

La usavo perché per ogni cosa c'era sempre qualcosa da imparare, e mi piace questo. Però volevo sempre l'ultima versione del software, inconsciamente volevo una rolling e un buon package manager che mi aiutasse nella cosa.

Arch mi è sembrata la scelta più naturale per le mie esigenze, per ogni cosa c'è da imparare qualcosa e in più posso godere delle ultime versioni dei software.

Ma ora qualcuno può dire Non potevi installare una slackware current?
Si avrei potuto ma non avrei avuto gnome, mi sarei dovuto affidare a progetti di terze parti seguendo le loro tempistiche. Il che trovo sia un po' brutto per una distribuzione...

Però sono anche del parere che c'è una distro per ogni tipo di lavoro e non userei arch su una postazione di lavoro, non voglio correre il rischio di vedermi esplodere tutto per un upgrade, questa distro la tengo solo sul pc di casa. In ufficio ho una Debian perché ho bisogno di software stabile, non necessariamente aggiornato e che si installi senza troppi problemi.

Non ho nulla da rimproverare a Slackware, è una distribuzione con una sua identità, e questo vi assicuro è un grandissimo pregio. Sono le mie esigenze col tempo ad essere cambiate.

[Communico]

Anche io sono passato ad arch definitivamente da due anni, l'unico vero vantaggio rispetto a slackware è la gestione dei pacchetti, i pacchetti più usati li si trova tutti nei repo, quelli più "esotici" esiste un repo (AUR) che contiene dei file che consentono di compilare in maniera automatica i pacchetti, insomma si ottiene un incrocio fra Slackware e Gentoo...Questa secondo me è una funzionalità che andrebbe introdotta anche qui su slacky, invece di ricompilare tutto il repository ad ogni versione si potrebbe mettere su un repo di soli slackbuild che effettuano automaticamente il download dei sorgenti, compilano, pacchettizzano ed installano...In questo modo bisognerebbe ricompilare solamente i pacchetti più famosi, mentre gli altri basta creare una volta lo slackbuild e si sta a posto per la vita, in caso qualche utente abbia problemi lo segnala e si aggiorna lo SB...Secondo me bisognerebbe pensarci...

[tom]

Anch'io sono passato ad Archlinux. Per chi ha dubbi, ecco cosa ha di importantissimo archlinux che a slackware manca:

1) una community UFFICIALE: è una cosa a dir poco fondamentale. Qui siamo solo degli utenti che ci aiutiamo l'un l'altro, lì c'è la community ufficiale, con i packager ufficiali e i creatori della distro.

2) risorse online CENTRALIZZATE: in conseguenza del punto 1. Niente Archy.eu o ArchBuild.org (spero che la battuta si sia capita . ). Solo il repository UFFICIALE: tutto il resto, se manca, va su AUR (Arch User Repository). No linee guida da dover adattare per ogni community che trovi, per creare i pacchetti, per usarli, per configurarti il sistema, ecc...

3) Un wiki UFFICIALE. Qualisasi cosa, QUALSIASI, ha una pagina wiki ufficiale che ti spiega esattamente cosa fare. Molte pagine sono tradotte pure in italiano, dalla community ufficiale italiana. Su questo punto slackware non regge proprio il confronto.

4) Installazione di software di esterno ai repository immediata con tool tipo yaourt o packer. Chi non li ha mai provati non potrà mai capire.

5) possibilità di tornare indietro, in un attimo, dopo un errore imprevisto che ti ha sballato il sistema. Questa è una cosa che non tutti gli utenti di arch sanno: esistono dei repository "congelati" alla data che desideri, e con pacman puoi tornare indietro e avere il tuo software alla data esatta, se qualche aggiornamento ti sballa il sistema. Questo procedimento su debian si chiama Pinning, ebbene è possibile anche su arch. No su slackware (puoi effettuare il downgrade di qualche pacchetto, sempre che riesci a identificare il pacchetto incriminato, ma non di tutta la distro, specie se hai appena aggiornato l'intera distro alla versione successiva).


Insomma in ultima analisi possiamo discutere su parecchie cose. Ma una cosa che ha arch e che slackware non ha è la centralizzazione delle risorse e degli utenti, i quali per qualsiasi cosa (pacchetto, malfunzionamento, configurazione, ecc) hanno un punto di riferimento, UNO SOLO.
Qua su slackware siamo invece tutti liberi come cani sciolti. Ognuno ha le sue regole, ognuno i suoi consigli, ognuno i suoi pacchetti. Si deframmentano le risorse, gli utenti sono spaesati, gli utenti lasciano slackware.

[Bart]

... gli utenti lasciano slackware.

Però siamo sempre qui a parlarne...

[Blallo]

1) una community UFFICIALE: è una cosa a dir poco fondamentale. Qui siamo solo degli utenti che ci aiutiamo l'un l'altro, lì c'è la community ufficiale, con i packager ufficiali e i creatori della distro.

E questa è una cosa buona

2) risorse online CENTRALIZZATE: in conseguenza del punto 1. Niente Archy.eu o ArchBuild.org (spero che la battuta si sia capita . ). Solo il repository UFFICIALE: tutto il resto, se manca, va su AUR (Arch User Repository). No linee guida da dover adattare per ogni community che trovi, per creare i pacchetti, per usarli, per configurarti il sistema, ecc...

Credo dipenda dal fatto che hanno una community. Slacky.eu è si un punto di riferimento per Slackware, ma non ha "ufficialità", quindi è normale che Arch non l'abbia.

3) Un wiki UFFICIALE. Qualisasi cosa, QUALSIASI, ha una pagina wiki ufficiale che ti spiega esattamente cosa fare. Molte pagine sono tradotte pure in italiano, dalla community ufficiale italiana. Su questo punto slackware non regge proprio il confronto.

Qui concordo con te, ma ritorna sempre al discorso di community.

4) Installazione di software di esterno ai repository immediata con tool tipo yaourt o packer. Chi non li ha mai provati non potrà mai capire.

Li ho provati, hanno la comodità della gestione delle dipendenze, ma ho avuto cattive esperienze nel modificare dei file che venivano insieme al PKGBUILD (es: un config.h per dwm), che makepkg non compilava perchè non corrispondevano (giustamente) gli md5. A quel punto preferisco compilarmelo a mano a parte. Un errore e ti salta tutta la coda di compilazione. Ha quindi pro e contro. Personalmente preferisco la versatilità degli SlackBuilds.

5) possibilità di tornare indietro, in un attimo, dopo un errore imprevisto che ti ha sballato il sistema. Questa è una cosa che non tutti gli utenti di arch sanno: esistono dei repository "congelati" alla data che desideri, e con pacman puoi tornare indietro e avere il tuo software alla data esatta, se qualche aggiornamento ti sballa il sistema. Questo procedimento su debian si chiama Pinning, ebbene è possibile anche su arch. No su slackware (puoi effettuare il downgrade di qualche pacchetto, sempre che riesci a identificare il pacchetto incriminato, ma non di tutta la distro, specie se hai appena aggiornato l'intera distro alla versione successiva).

È un po' la filosofia di Slackware: devi sapere sempre cosa fai

Insomma in ultima analisi possiamo discutere su parecchie cose. Ma una cosa che ha arch e che slackware non ha è la centralizzazione delle risorse e degli utenti, i quali per qualsiasi cosa (pacchetto, malfunzionamento, configurazione, ecc) hanno un punto di riferimento, UNO SOLO.
Qua su slackware siamo invece tutti liberi come cani sciolti. Ognuno ha le sue regole, ognuno i suoi consigli, ognuno i suoi pacchetti. Si deframmentano le risorse, gli utenti sono spaesati, gli utenti lasciano slackware.

Io personalmente non la lascerò mai, se non per una Slack-based. Però si, almeno per certe regole guida è meglio avere un qualcosa di centralizzato.