Slackware 4 dummies 4 edizione: richiesta di samiel

[samiel]

Mi sa che ce ne sarebbe da lavorare per mesi...

Configurare xfce è un'ottima proposta, e in effetti
sarebbe utilissimo soprattutto a chi non ha risorse
per usare KDE o Gnome.

L'idea di analizzare Perl (a allora perché no PHP
o Java?) mi lascia un po' perplesso,
per il fatto che ci si allontana troppo da Slackware,
al di là del fatto che non sono affatto ferrato sul tema
(mi avete preso per Giacomini?).
Altrimenti, per dire, qualcuno potrebbe volere
una sezione su LaTeX o sui CSS...

Slack per gestire un piccolo webserver... Interessante!

Beh, continuate, io cercherò di trovare un equilibrio
fra le mie competenze e lo spirito dell'opera.
Certo, forse bisognerebeb pensare a 2 guide
distinte: una per chi vuole semplicemente
essere operativo con Slackware in tempi ragionevoli,
una per gli utenti più smaliziati. Ad esempio:
nella prima il lungo capitolo che già c'è
sulla compilazione da sorgenti potrebbe essere omessa,
nella seconda diventerebbe essenziale.

Per il wireless: sono d'accordo con chi osserva
che si tratta di una lacuna, sempre più vistosa
data la diffusione che ormai ha raggiunto
questo tipo di harware. L'unico problema
p che io non ne possiedo e non ho mai scritto
qualcosa che non avessi studiato e verificato direttamente.

Lasciatemi qualcosa per la quinta edizione,
o regalatemi, chessò, un router wireless

M.

[Bart]

L'idea di analizzare Perl (a allora perché no PHP
o Java?) mi lascia un po' perplesso,
per il fatto che ci si allontana troppo da Slackware,
al di là del fatto che non sono affatto ferrato sul tema
(mi avete preso per Giacomini?).
Altrimenti, per dire, qualcuno potrebbe volere
una sezione su LaTeX o sui CSS...

Per lo stesso motivo che ti ha portato a parlare di bash. In molti libri che trattano di linux vedi questi linguaggi interpretati e non per questo sono libri di programmazione. Certamente non sono argomenti chiave, anche se omessi cambiano poco, ma visto che tu hai chiesto delle idee io te ne sto buttando lì alcune

Certo, forse bisognerebeb pensare a 2 guide
distinte: una per chi vuole semplicemente
essere operativo con Slackware in tempi ragionevoli,
una per gli utenti più smaliziati. Ad esempio:
nella prima il lungo capitolo che già c'è
sulla compilazione da sorgenti potrebbe essere omessa,
nella seconda diventerebbe essenziale.

Per me non ha senso. S4D, titolo a parte, non è proprio una mini guida da leggere in 24 ore per essere subito operativi. Io la vedo più come un'opera di riferimento per chi si avvicina o comunque utilizza slackware. Fare due guide mi sembra come togliere importanza a questa tua opera che invece potrebbe diventare un vero e proprio punto di riferimento.

[alessiodf]

io direi di mantenerla, aggiornarla e fare qualche aggiunta vedi ssh, ftp, iptables (quasto non e' proprio 4dummies!)

Il resto come programmazione, lo vedo troppo 4GuRu!

comunque te sei proprio un grande!

[danix]

mi accodo alla discussione sperando di apportare qualcosa di utile...
Fermo restando che io ho sempre interpretato il "4 Dummies" come il target a cui è diretto il libro, e non il livello degli argomenti trattati... io, da buon dummy ho sempre desiderato in S4D una lista completa delle applicazioni che non richiedono X e che sono, già di default, installate nella slack... parlo ad esempio dei lettori mp3, di manipolatori di immagini come convert della suite ImageMagik... una lista del genere ridurrebbe ad esempio tutti quei post (come i miei) in cui un utente chiede come far fare al proprio pc una determinata cosa per poi vedersi rispondere "con l'applicazione XYZ..."
Ovviamente sono consapevole che una cosa del genere potrebbe essere un'impresa titanica vista la mole di programmi installata con Slackware, ma ritengo che sarebbe davvero utile a chi si avvicina per la prima volta a Slackware o a Linux in genere....

Giusto per lasciare il mio parere anche su ciò che è stato detto prima, concordo sull'estendere bash, sull'includere un'introduzione ad Apache, ma non sull'includere altri linguaggi, al massimo si può dare delle indicazioni sul fatto che esistano altri metodi per fare una determinata cosa, e indicare il linguaggio o la guida a cui fare riferimento (se la conosci)... del resto Perl, PHP, Python ecc ecc 4 dummies esistono già...
Poi mi chiedevo, hai intenzione di parlare di GSlacky??

Ancora buon lavoro samiel...

[samiel]

Se vedi uno dei miei post precedenti, quello che volevo fare
è proprio una lista di programmi del tipo che dici tu.
Vuoi mandare una e-mail senza entrare in X?
Hai mail, pine e mutt. E a seguire una scheda
su come configurarli per l'uso immediato.
Chiaro che non descriverò tutte le 17.598 opzioni di Mutt,
ma lo stretto indispensabile per mandare e ricevere una mail.

GnomeSlacky ovviamente ci sarà

M.

[danix]

si, ma avevo capito che volessi fare una lista solo per quanto riguarda le cose principali, come appunto inviare una mail, o editare un file di testo ecc, una cosa del genere per capirci:

azione --> programma1, programma2...
altra azione --> programma1

io invece ti dicevo un po' il contrario...

programma1 = azione
programma2 = azione
...
programmaN = azione

Ho reso l'idea??
In questo modo basterebbe dare una letta all'elenco per scoprire una miriade di programmi che non si conoscono... Io credo che sarebbe utile, però capisco anche che può risultare difficile riportare tutti i programmi che ci sono, quindi qualunque strada deciderai di seguire sarà benaccetta...

A presto...

[Bart]

Si forse a pensarci bene tutti quei linguaggi non sono tanto 4 dummies. Io credo che le cose che hai indicato (se vuoi anche il capitolino su come settare un server web) e un aggiornamento complessivo siano un ottimo passo avanti per la nuova versione. Poi magari nella quinta ci metti il wireless e altre novità/correzioni. Anche perché non sono poi tanto poche e la mole di lavoro non è piccolissima
Samiel questo libro dovrebbe diventare la guida ufficiale!

[umaga]

Io vorrei aggiungere questo: se c'è qualche argomento interessante e utile alla maggior parte di utenti e mi riferisco soprattutto al wireless (richiestissimo a quanto leggo), ma samiel non ha esperienza in questo campo, anziche regalargli un router, qualcuno che è ferrato in materia, e ha il tempo e la voglia, potrebbe buttar giù un capitolo da aggiungere al libro di samiel....
penso sarebbe una buona idea

Ciao e grazie davvero per la guida

[ekxius]

Io vorrei aggiungere questo: se c'è qualche argomento interessante e utile alla maggior parte di utenti e mi riferisco soprattutto al wireless (richiestissimo a quanto leggo), ma samiel non ha esperienza in questo campo, anziche regalargli un router, qualcuno che è ferrato in materia, e ha il tempo e la voglia, potrebbe buttar giù un capitolo da aggiungere al libro di samiel....
penso sarebbe una buona idea

Ciao e grazie davvero per la guida

quoto, ad esempio io ho detto a samiel che se vuole anche copiare parola per parola la mia guida sui driver ati che ho fatto qui nel wikislacky non cè problema, perchè ho visto che quella di s4d è un po' datata ormai... così lo sgraviamo da un po di lavoro perchè in effetti ce nè un macello

grazie anche da parte mia a samiel

ekxius

[albatros]

@danix85:
Secondo me è meglio l'impostazione di Samiel...

Cosa c'è nei singoli pacchetti lo puoi vedere:
1) mentre li installi (io all'inizio feci così, prendendo nota di quello che installavo)
2) con pkgtool
3) guardando in /var/log/packages i singoli pacchetti con less o cat o anche con uno scriptino tipo:
cd /var/log/packages
for i in $(dir -1); do head -n 16 $i; echo; read a; clear; done

Per i singoli comandi puoi vedere le pagine man, sono state fatte apposta...
E' più difficile fare il contrario, ovvero trovare il programma giusto per fare una certa cosa...
Senza contare che i programmi sono migliaia e molti di essi di solito non interessano a chi è alle prime armi (es. groff o ldd o lsof): secondo me lo sforzo sarebbe sproporzionato rispetto ai risultati...

Venendo ai suggerimenti per Samiel, forse si potrebbe:
-spendere qualche parola per hal+dbus
-fare una introduzione alla virtualizzazione (qemu, xen, vmware, kvm)
-fare una introduzione ai filesystem crittati (dm-crypt)
-fornire link e bibliografia per approfondimenti (es. all'abs piuttosto che scrivere una guida per bash, per il latex, tutorial per gimp, eccetera).

Grazie e complimenti, Samiel, per il tuo grande impegno!

[twister]

One man distro, one man dummies
Se ognuno aggiunge capitoli si perde l'identita' di s4d anche perche' Samiel ha un approccio molto buono anche con chi non capisce nulla di linux, approccio che magari noi non avremmo...
Se facciamo lo slacky day italiano te lo regalo io un router wireless, me ne avanza giusto uno

[ekxius]

One man distro, one man dummies
Se ognuno aggiunge capitoli si perde l'identita' di s4d anche perche' Samiel ha un approccio molto buono anche con chi non capisce nulla di linux, approccio che magari noi non avremmo...
Se facciamo lo slacky day italiano te lo regalo io un router wireless, me ne avanza giusto uno

non sono d'accordo. se esiste già lavoro fatto da altri, perchè samiel deve essere caricato di lavoro che è già stato fatto?

magari può adattarlo con la semplicità di linguaggio che caratterizza la sua s4d questo sì, comunque tutto ciò sempre IMHO.

ciao a tutti

[masalapianta]

Se qualcuno ha altri temi da proporre,
valuterò se inserirli nella 4° edizione.

piu' che di questo o quell'argomento particolare il "dummies" che approccia a *nix ha bisogno di metodo e forma mentis, che detto cosi' pare una bazzecola ma e' una cosa molto difficile da insegnare, soprattutto senza entrare nel dettaglio di millemila cose partendo da bassissimo livello, ma qualcosa si puo' fare; ad esempio insegnare un metodo per quel che gli anglofoni chiamano troubleshooting:
se hai un problema prima devi cercare di capire cosa esattamente dovrebbe fare la cosa che non ti funziona e in che ordine dovrebbe farlo (va a leggere dei file di dati o configurazione? dialoga via rete con altri accrocchi? ecc..), magari aiutandosi con tool come strace/ltrace, tcpdump/ethereal, ecc.., dopodiche' seguire tutto il flusso dall'inizio alla fine (ho visto spesso molta gente andare a casaccio, magari tu controlli l'operazione A e l'operazione C ma in mezzo c'e' la B che e' proprio lei a dar problemi) per trovare l'intoppo; non e' necessario essere dei guru, il 99% delle volte non serve conoscere gli internals del kernel o gdb a menadito ma basta avere un'idea di cosa sia una syscall e quali siano quelle piu' usate su *nix, avere un'idea di come funzioni il tcp/ip, ecc..
(certo a volte questo non basta e ad esempio devi leggerti i sorgenti ed eventualmente ficcarci codice di debug, oppure ti tocca scrivere un LKM o una libreria in preload che hooka alcune syscall per capire perche' $maledetto_accrocco_chiuso_e_proprietario_che_se_messo_sotto_ptrace_fa_simpaticamente_una_exit_e_buonanotte_ai_debugger non funziona, ma son situazioni rare per fortuna).
L'obiettivo e' insegnare al "dummies" un approccio alla risoluzione dei problemi (possibilmente con esempi pratici di problemi e del metodo passo-passo utilizzato per risolverli), in modo che, quando se ne trova davanti uno, possa seguire tale metodo, analizzando quanto piu' possibile nel dettaglio tutto il flusso che segue l'applicazione che non funziona; se poi non riesce comunque a risolvere (raro, se adotta correttamente l'approccio di cui sopra), facilita moltissimo la vita a quelli cui chiedera' aiuto, fornendogli dati utili su tutta l'analisi fatta; anziche' un semplice "aiutooo! pippo non funziona" o al massimo "aiutooo! pippo non funziona, mi da quest'errore...".

[stan]

Se qualcuno ha altri temi da proporre,
valuterò se inserirli nella 4° edizione.

piu' che di questo o quell'argomento particolare il "dummies" che approccia a *nix ha bisogno di metodo e forma mentis, che detto cosi' pare una bazzecola ma e' una cosa molto difficile da insegnare, soprattutto senza entrare nel dettaglio di millemila cose partendo da bassissimo livello, ma qualcosa si puo' fare; ad esempio insegnare un metodo per quel che gli anglofoni chiamano troubleshooting:
se hai un problema prima devi cercare di capire cosa esattamente dovrebbe fare la cosa che non ti funziona e in che ordine dovrebbe farlo (va a leggere dei file di dati o configurazione? dialoga via rete con altri accrocchi? ecc..), magari aiutandosi con tool come strace/ltrace, tcpdump/ethereal, ecc.., dopodiche' seguire tutto il flusso dall'inizio alla fine (ho visto spesso molta gente andare a casaccio, magari tu controlli l'operazione A e l'operazione C ma in mezzo c'e' la B che e' proprio lei a dar problemi) per trovare l'intoppo; non e' necessario essere dei guru, il 99% delle volte non serve conoscere gli internals del kernel o gdb a menadito ma basta avere un'idea di cosa sia una syscall e quali siano quelle piu' usate su *nix, avere un'idea di come funzioni il tcp/ip, ecc..
(certo a volte questo non basta e ad esempio devi leggerti i sorgenti ed eventualmente ficcarci codice di debug, oppure ti tocca scrivere un LKM o una libreria in preload che hooka alcune syscall per capire perche' $maledetto_accrocco_chiuso_e_proprietario_che_se_messo_sotto_ptrace_fa_simpaticamente_una_exit_e_buonanotte_ai_debugger non funziona, ma son situazioni rare per fortuna).
L'obiettivo e' insegnare al "dummies" un approccio alla risoluzione dei problemi (possibilmente con esempi pratici di problemi e del metodo passo-passo utilizzato per risolverli), in modo che, quando se ne trova davanti uno, possa seguire tale metodo, analizzando quanto piu' possibile nel dettaglio tutto il flusso che segue l'applicazione che non funziona; se poi non riesce comunque a risolvere (raro, se adotta correttamente l'approccio di cui sopra), facilita moltissimo la vita a quelli cui chiedera' aiuto, fornendogli dati utili su tutta l'analisi fatta; anziche' un semplice "aiutooo! pippo non funziona" o al massimo "aiutooo! pippo non funziona, mi da quest'errore...".

Sono d'accordissimo.
@masalapianta: se samiel e' occupato non e' che riusciresti a scriverlo tu? Magari ne puo' uscire un nuovo documento da affiancare a S4D. Io sarei sicuramente interessato e mi pare che tu possa essere la persona adatta a scriverlo.

[samiel]

Adesso rifletto un po', faccio uno schema e quello che
in editoria si chiama preventivo mole. Considerate che
la mia guida è dedicata a Slackware, gli "Appunti di
informatica libera" esistono e comunque ne sarei in grado
di scrivere l'1 % o poco più. Per cui alcune cose ci
saranno, altre invece no. E comunque tutto questo significherà
non meno di un centinaio di pagine un più.

Inoltre, la mia guida non vuole e non può essere l'unica
onnicomprensiva guida. Per ben vengano ekxsius
e masala e quant'altri a scrivere nuova documentazione.
Ciascuno ha un suo stile, un suo approccio e questa
è una ulteriore ricchezza per i lettori.

Intanto grazie della collaborazione;
mi ritiro per deliberare

M.