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.
In Windows ogni tanto compare la tristemente famosa finestra che dice "questo programma ha compiuto una operazione non lecita e verrà terminato"!
In casi del genere, molti utenti Linux scoppiano a ridere, ma non si rendono conto che la finestra di Windows equivale al classico (e umiliante) segmentation fault di Linux; la differenza sta nel fatto che Windows almeno mostra la finestra (con tanto di dump della memoria), mentre Linux non mostra un emerito c**** e l'utente deve arrangiarsi!
Il segmentation fault è (spesso) una violazione della modalità protetta; in pratica, un programma ha tentato di invadere un'area riservata ad un altro programma o al sistema operativo.
Ecco un esempio pratico che mi è capitato da poco.
Ho scaricato il sorgente di Scilab 4.0 e l'ho ricompilato con
./configure --with-gtk2 & make all
Eseguendo il programma, ho scoperto che aprendo la Graphic Windows e cliccandoci sopra, Scilab va in crash con l'inesorabile segmentation fault; con Scilab 3.x questo non succedeva.
Per fortuna è presente l'opzione -debug che permette di lanciare Scilab dall'interno del debugger gdb; in questo modo ho scoperto che il crash si verifica nella funzione locator_button_release nel file scilab-4.0/routines/graphics/periGtk.c
In tale funzione ho scoperto un errore madornale; guardate bene il codice:
static gboolean locator_button_release(GtkWidget *widget, GdkEventButton *event, BCG *gc)
{
static GdkDisplay *display=NULL;
/* to compile with gdk<2.4 */
#if GTK_MAJOR_VERSION==2 && GTK_MINOR_VERSION>=4
int display_double_click_distance = display->double_click_distance;
#else
int display_double_click_distance=5;
#endif
if ( display == NULL)
display=gdk_display_get_default();
..........................................
In pratica, se la versione di GTK2 è maggiore o uguale a 2.4, alla variabile display_double_click_distance viene assegnato display->double_click_distance; peccato però che il puntatore display stia puntando a NULL!!!!!!!!!!
Ovviamente, il modo corretto di scrivere il precedente codice è (se siete sicuri di avere GTK2 2.4 o superiore):
Ora, io sono un programmatore dilettante, però di queste ca***** non ne ho mai fatte; mi sembra incredibile poi che chi ha scritto l'interfaccia grafica di Scilab non abbia notato il problema!
Purtroppo, in ambiente Linux sono veramente troppi i programmi che vanno in crash per problemi di questo genere; ciò accade anche perché parecchio software viene scritto da ragazzini che credono di essere dei grandi hackers.
Sarebbe meglio cominciare a sviluppare il software con criteri un po più seri; se non cambia l'andazzo, non so per quanto tempo durerà la pazienza degli utenti.
P.S. Lo so benissimo che Scilab è un programmone; ma ovviamente non mi riferivo a chi ha scitto la parte matematica.
Come al solito emerge l'omertà dei Linuxiani; basterebbe leggere i messaggi su questo forum per rendersi conto che 9 utenti su 10 hanno seri problemi di stabilità con i programmi.
Essere utenti Linux significa prima di tutto contribuire a correggere eventuali errori ...... anziché nasconderli!
Caro phobos3576,
premetto che non sono un programmatore, anche ho un po' di basi che mi consentono di scrivere qualche programmino o qualche script di shell, e che non sono neanche un utente esperto: diciamo che so quel che serve per le mie esigenze e che ogni tanto mi diverto a "smanettare" un po'.
Premetto anche che non ho presente al momento la licenza di Scilab, che ho provato tempo addietro insieme a Mupad per un breve periodo, ma che è tanto che non uso più, le considerazioni che seguono si riferiscono quindi al modello di sviluppo del software libero tipico dell'ambiente linux.
Vengo ora alle considerazioni che hai fatto, con le quali mi trovo in larga parte in disaccordo.
Secondo il mio punto di vista, è vero che talvolta occorrerebbe un po' più di autocritica prima di lasciarsi andare a facili commenti su altri sistemi operativi o su applicativi vari se non si ha una solida preparazione informatica, è vero che talvolta nel programmare vengono commessi errori grossolani che una maggiore attenzione potrebbe evitare, è vero che ci può essere qualcuno che sopravvaluta le proprie capacità, è vero che se vogliamo che un certo software venga apprezzato e sia competitivo bisogna puntare sulla qualità, MA, sempre a parer mio:
-non credo siano, come ha detto anche twister, che gli applicativi che "crashano" siano tanti: a me sono capitati abbastanza di rado
-con programmi di cui non disponi del codice sorgente, e questi sono assai più diffusi in ambiente windows che non linux e *BSD, non puoi correggere da solo l'errore, ma lo deve correggere, quando vorrà, che ti ha fatto il programma
-il modello di sviluppo del software libero prevede che chi lo usa, se ne ha le capacità, come è stato nel tuo caso, aiuti a migliorarlo, correggendo eventuali errori: se segnalerai l'errore al gruppo che cura lo sviluppo di Scilab, da domani questo errore non ci sarà più
-il software libero ti viene fornito senza alcuna garanzia di funzionamento, per cui, se il tuo è un incoraggiamento a fare di meglio, come spero e credo, ben venga, se invece fosse una lamentela e basta, la troverei fuori luogo
-i "ragazzini" che chiami in causa, ammesso che siano tali, si stanno sforzando di imparare e mettoni disinteressatamente a disposizione di tutti il risultato dei loro sforzi. Non so se si credano degli hackers, può darsi che però questi "ragazzini" hackers lo siano già, se usiamo l'accezione del termine cara a Stallman e altri per cui è un hacker colui o colei al quale piace capire come funzionano le cose e sperimentare, cercare vie alternative e originali. Forse, dirai, se non hanno capacità tecniche comprovate, sarebbe bene tenerli fuori da progetti di grande importanza: ebbene, non sono d'accordo, perché credo sia di grande stimolo per loro lavorare a un progetto di produzione, del quale, magari, viene curata appunto la parte grafica e non quella relativa agli algoritmi matematici, ben più impegnativa.
-non so la pazienza degli altri, la mia durerò ancora a lungo, credo che finirà se e solo quando avrò le capacità e il tempo per rimboccarmi le maniche e dare anch'io un contributo che vada oltre la semplice occasionale donazione
Spero di non essere stato in nessun punto duro o provocatorio, anche se non mi pare. La mia intenzione non è quella di avviare flames o scontri vari: semplicemente, pur capendo le tue ragioni, volevo mettere in luce alcuni punti che ritengo fondementali e che, a parer mio, vanno considerati nella prospettiva di un'analisi più serena ed equilibrata.
Ti ringrazio per il tuo intervento e ti saluto tanto, insieme a tutti quelli che ci avranno letto.
Caro phobos3576,
leggo ora il tuo secondo post.
Forse non ci avrò fatto caso, forse sarà perché non seguo sempre il forum o perché scelgo solo alcuni argomenti e non li leggo tutti, ma non ho visto questa percentuale così elevata (90%) di utenti che hanno seri problemi di stabilità con i programmi, ho visto semmai problemi di configurazione di varia natura...
Può darsi che ci sia chi nasconde le pecche di un programma, sono d'accordissimo con te che bisogna mettere in luce gli errori per correggerli e non nasconderli, ma questa grande omertà, inerzia e malafede, almeno nelle percentuali che sostieni tu, sinceramente non la vedo...
Grazie, in ogni caso, per il tuo contributo e di nuovo tanti saluti.
Pure io sono tra quelli che non perderanno mai e poi mai la pazienza!
Per me Linux è il massimo che si possa pretendere su un computer; non a caso, Windows ormai è un ricordo del passato (non come certi utenti di questo forum che usano Windows e Explorer).
La mia preoccupazione è rivolta a quegli utenti che provengono da Windows e si imbattono in un mondo che, anziché semplificarsi, sta diventando sempre più complesso e sempre più rivolto a pochi esperti.
A me questa situazione può anche andare bene; se si pretende il massimo dal proprio computer bisogna studiare, studiare, studiare.
Sappiamo però che il 95% degli utenti Windows sono totalmente digiuni di informatica e utilizzano il computer per lavorare, non certo per compilare, ricompilare, configurare, riconfigurare ...... all'infinito.
Come possiamo pretendere che si avvicinino al mondo Linux?
Tornando al problema che ho sollevato, Linux offre potentissimi strumenti per gli sviluppatori; con simili strumenti è possibile pianificare e razionalizzare il pesante lavoro di programmazione. Purtroppo però, imperversano certi pseudo-hackers che continuano ad utilizzare EMACS (se non VI) per scrivere migliaia di linee di codice delle quali, ad un certo punto, perdono regolarmente il controllo.
Persino gli sviluppatori di Xorg hanno ammesso che ormai non è più possibile controllare le 16.000.000 di linee di codice C del server X monolitico; adesso, con enorme ritardo, si rendono conto che è meglio suddividere X in tanti moduli in modo da facilitare la ricerca degli errori.
Lo sviluppatore di K3b scrive sul suo stesso sito che forse sta esagerando con i bugfix; in effetti, sarebbe meglio distribuire una nuova release ogni 3 o 4 mesi, con un bel po di bug risolti, anzichè annunciare un nuovo bugfix ogni 2 giorni. Un tale comportamento è sinonimo di disordine e mancanza di criterio!
E' una situazione folle che fa solo del male a Linux.
Posso essere d'accordo con te, ma bisogna considerare che per utenti che migrano da windows ci sono altre distribuzioni molto più semplici, basti pensare alla Mandrake o alla Mandriva, che per quanto ne so io la maggior parte delle volte rilasciano solo pacchetti stabili... mi sbaglio?
D'altronde ci sono distribuzioni e distribuzioni, e credo sia per quello che il mondo linux può funzionare: a ognuno la sua a seconda di semplicità, controllo e qualità grafica.
Io personalmente, ad esempio, ho scelto Slackware perchè posso imparare molto di più e avere il controllo completo della macchina... Ma ad amici che sono migrati ho installato Mandrake e non si sono mai lamentati...
Curiosità: Io uso sempre emacs, ma in una prospettiva di miglioramento personale, tu cosa mi consiglieresti?
phobos3576 ha scritto:In Windows ogni tanto compare la tristemente famosa finestra che dice "questo programma ha compiuto una operazione non lecita e verrà terminato"!
Si, anche a me è capitato
In casi del genere, molti utenti Linux scoppiano a ridere, ma non si rendono conto che la finestra di Windows equivale al classico (e umiliante) segmentation fault di Linux; la differenza sta nel fatto che Windows almeno mostra la finestra (con tanto di dump della memoria), mentre Linux non mostra un emerito c**** e l'utente deve arrangiarsi!
Anche questo mi è capitato, ma non mi sono mai sentito umiliato...
Il segmentation fault è (spesso) una violazione della modalità protetta; in pratica, un programma ha tentato di invadere un'area riservata ad un altro programma o al sistema operativo.
Mi fido sulla parola
Ecco un esempio pratico che mi è capitato da poco.
Ho scaricato il sorgente di Scilab 4.0 e l'ho ricompilato con
./configure --with-gtk2 & make all
Eseguendo il programma, ho scoperto che aprendo la Graphic Windows e cliccandoci sopra, Scilab va in crash con l'inesorabile segmentation fault; con Scilab 3.x questo non succedeva.
Per fortuna è presente l'opzione -debug che permette di lanciare Scilab dall'interno del debugger gdb; in questo modo ho scoperto che il crash si verifica nella funzione locator_button_release nel file scilab-4.0/routines/graphics/periGtk.c
In tale funzione ho scoperto un errore madornale; guardate bene il codice:
static gboolean locator_button_release(GtkWidget *widget, GdkEventButton *event, BCG *gc)
{
static GdkDisplay *display=NULL;
/* to compile with gdk<2.4 */
#if GTK_MAJOR_VERSION==2 && GTK_MINOR_VERSION>=4
int display_double_click_distance = display->double_click_distance;
#else
int display_double_click_distance=5;
#endif
if ( display == NULL)
display=gdk_display_get_default();
..........................................
In pratica, se la versione di GTK2 è maggiore o uguale a 2.4, alla variabile display_double_click_distance viene assegnato display->double_click_distance; peccato però che il puntatore display stia puntando a NULL!!!!!!!!!!
Ovviamente, il modo corretto di scrivere il precedente codice è (se siete sicuri di avere GTK2 2.4 o superiore):
Non discuto su come hai intitolato il messaggio, trovo che un altro titolo appropriato potrebbe essere "Ecco un esempio di come funziona il software libero".
Se ti va, potresti spedire la correzione all'autore del programma...
Pure io sono tra quelli che non perderanno mai e poi mai la pazienza!
Per me Linux è il massimo che si possa pretendere su un computer; non a caso, Windows ormai è un ricordo del passato (non come certi utenti di questo forum che usano Windows e Explorer).
Penso che tutti possano decidere cosa usare, e credo che tu sia concorde in questo.
Come possiamo pretendere che si avvicinino al mondo Linux?
phobos3576 ha scritto:In Windows ogni tanto compare la tristemente famosa finestra che dice "questo programma ha compiuto una operazione non lecita e verrà terminato"!
In casi del genere, molti utenti Linux scoppiano a ridere, ma non si rendono conto che la finestra di Windows equivale al classico (e umiliante) segmentation fault di Linux; la differenza sta nel fatto che Windows almeno mostra la finestra (con tanto di dump della memoria), mentre Linux non mostra un emerito c**** e l'utente deve arrangiarsi!
ma perche' la gente chiacchiera e chiacchera senza sapere un emerito c****? mai sentito parlare di "core dump"? il fatto che in molte distro la creazione del file core sia disabilitata per default (cosa imho ottima visto che il 99% degli utenti non saprebbe cosa farsene dei core e gli intaserebbero solo il disco alla lunga) non significa che tu non possa abilitarla quando ne hai bisogno con un semplice ulimit -c grandezza_del_file_core_in_KB
Adesso gli argomenti mi trovano un po' più d'accordo, anche se ho un giudizio un po' diverso sulla situazione.
Quando si ha che fare con un'utenza non sempre esperta, se si vuole che Linux e l'universo di cui fa parte siano sempre più diffusi e apprezzati, organizzare il metodo di sviluppo è fondamentale, è fondamentale tenere una linea stabile e una linea di sviluppo ben distinte, bisogna creare interfacce grafiche facili da usare e funzionali, senza limitare le possibilità di personalizzazione (vedi il dibattito fra Linus e il gruppo di Gnome di poco tempo fa), bisogna che i programmi siano facili da installare e che funzionino senza tanti intoppi o senza bisogno di tante configurazioni preliminari.
Dire che certe cose si possono fare solo con la linea di comando disorienta sicuramente chi è abituato a lavorare in un ambiente grafico.
E, per certi versi, queste persone hanno anche ragione, perché il computer è anche uno strumento da usare, non è fine a se stesso, e l'informatica è un interesse come tanti, ci sono tanti lavori che richiedono di per sè grande impegno e dedizione, non si può chiedere ad una persona come ad esempio al mio medico curante che spesso lavora dalle 8:00 alle 23:00, di passare il sabato pomeriggio e la domenica a cercare di far funzionare un programma...
E' come se a me, che non so quasi nulla di motori, mi dicessero che c'è una macchina spettacolare che ha prestazioni eccezionali e non si guasta mai, però bisogna montare il motore, fare da soli la manutenzione e si guida in maniera diversa dalle altre, chessò, sdraiati anziché seduti...
Non so se la userei anche se me la regalassero...
Ti dò quindi ragione quando dici che, se si ha a cuore la diffusione di Linux, bisogna curare maggiormente la facilità d'uso e la stabilità e che il paradigma "release early, release often" non si può applicare a un utenza "di massa".
Mi pare però che, col passare del tempo, anche se progetti come X.org, che hai giustamente citato, hanno avuto bisogno di una riorganizzazione per la difficoltà di gestione che avevano, le cose vadano migliorando anziché peggiorando...
I problemi che hai evidenziato credo siano ben presenti a tanti e mi pare che ci si stia adoperando per trovare soluzioni, sia separando in maniera netta linea stabile e linea di sviluppo, sia lavorando a livello di distribuzioni (vedi Ubuntu, Mandriva, Suse, RedHat) per sempilificare il processo di installazione e amministrazione del sistema.
E' vero che c'è ancora tanto da fare e che le dimensioni del codice, per via delle novità tecnologiche e delle nuove features, stanno aumentando a un ritmo vertiginoso, però mi sembra che ci si stia già muovendo nella direzione giusta.
Un buon compromesso riguardo ai bugfix mi pare sia stato raggiunto col kernel, con un'ulteriore sottonumerazione che può sì confondere all'inizo, ma che una volta compresa è facile e lineare e consente di avere sempre il meglio a disposizione.
Fra l'altro, appunto nel kernel, mi pare che Linus stia testando parecchio prima di annunciare le release stabili, forse per evitare i problemi avuti con i primi kernel della serie 2.6.
E anche le distribuzioni, dopo il caso di RedHat 7 con gcc, mi pare stiano più attente alla stabilità dei programmi.
Di k3b non posso dir nulla, uso mkisofs e cdrecord da linea di comando perché li ritengo più pratici e veloci.
Per portarti altri esempi, con kppp è oggi facilissmo impostare una connessione dialup, ricordo che io, qualche anno fa, agli inizi con linux, ci persi un paio di settimane fra script e stringhe at di inizializzazione (più un collegamento con fili di rame sui circuiti del modem interno, fatto malissimo, ma funzionante) prima di riuscire a collegarmi...
Anche le prime versioni di Openoffice erano molto pesanti e piene di difetti, ma oggi mi pare sia un prodotto decisamente buono, anche se con ampi margini di ulteriore miglioramento...
Per un uso senza tante pretese, credo che oggi con kde usare una linux box già configurata sia facile come usare windows o MacOs...
Bachi e difetti ci sono poi anche in altri sistemi e ambienti, non mi pare che le prime versioni di windows 98 e millennium edition fossero particolarmente brillanti...
Ma non mi piace parlar male degli altri sistemi e delle scelte di altre persone, è assai meglio concentrarsi su quello che si può fare per migliorare Linux e i suoi applicativi e lavorare affinché sia appunto possibile scegliere un'Os o un'altro senza che la scelta sia univoca perché dettata da scarsa conoscenza delle alternative o da un corredo software difficile e scomodo da usare per in non addetti.
Un problema è poi di ordine "culturale" o "psicologico", secondo i punti di vista, ovvero è il bisogno irrefrenabile, di cui confesso anch'io sono stato talvolta, soprattutto in passato, di avere sempre novità e prodotti all'ultimo grido, con il risultato di spingere sviluppatori e distribuzioni ad assecondare tale tendenza proponendo software non sufficientemente stabili e testati.
La Debian stable, che propone software leggermente più datati, ma testati a fondo, mi pare sia stata più volte criticata per questa sua caratteristica; pochi giorni fa ho letto un post di un utente che si lamentava dei ritardi con cui Patrick ha inserito l'ultima release di kde e il fatto che ancora Slackware usi linux 2.4.31 di default...
Sul fatto di usare Emacs o Vi(m) non ci vedo nulla di male, anch'io, con le mie modestissime capacità, preferisco Vim per la sua velocità, comodità e flessibilità ...
Se poi mi dici che il lavoro va organizzato meglio, posso essere d'accordo, in effetti uno dei grandi meriti di Linus è stato appunto aver creato un'organizzazione del lavoro (e tool per gestirlo come il recente git, scritto apposta dopo le polemiche con bitkeeper) molto efficiente.
Se mi dici che un po' più di umiltà in generale non farebbe male, anche su questo posso essere d'accordo, è sempre un bene riflettere su quali siano le proprie reali capacità.
Però, questi pseudo-hackers, come li definisci tu, contribuiscono pur sempre allo sviluppo di Linux, se certi loro atteggiamenti sono controproducenti occorre indurli a meditare sulle conseguenze delle loro azioni, non bisogna tuttavia scoraggiarli, ma vanno presi, come si suol dire "per il verso del pelo", perché, più che la presunzione, credo sia l'entusiasmo che li spinge a fare e, qualche volta, forse a strafare...
Personalmente preferisco comunque rischiare di avere qualcosa fuori posto, ma un ambiente vivo e frizzante, che un sistema perfetto, ma stanco e rigido, senza per questo, ovviamente rinunciare ad una sana autocritica e alla ricerca di strategie migliori.
Ringrazio per l'attenzione, mi scuso per la prolissità e auguro a tutti, in particolare a phobos3576, una buona giornata.
Vero, masalapianta ha ragione.
Nella prima distribuzione che ho usato, una RedHat 6, quando un'applicazione crashava produceva il suo bravo file core, con il quale un utente esperto quale non ero e non sono, anche se qualcosina in più di allora la so, poteva esaminare la situazione e trovare l'errore.
Anch'io ho a suo tempo settato a zero la dimensione massima per il file core, perché non avrei saputo sfruttarlo e mi toccava ogni tanto rimuovere i file core disseminati qua e là.
Le informazioni che il core dump dà all'utente inesperto sono praticamente zero, per cui trovo giusto non averlo di default, così come di default, quando compilo dei programmi, preferisco l'install-strip o la rimozione dai Makefile del flag -g con un piccolo script.
In effetti anche alcune applicazioni per windows elencavano i valori dei registri, ma il punto non è nel messaggio di errore o meno, perché, secondo me, serve a poco un messaggio che ti dice che il programma è andato in crash quando in fondo lo vedi già da solo...
La grande forza di linux è che, se ne hai le capacità, hai la possibilità e gli strumenti che ti occorrono per aggiustare le cose, possibilità spesso assente o esplicitamente vietata in ambienti proprietari...
Eppoi, da un bel po' di tempo a questa parte, ho personalmente notato pochissimi crash...
Un piccolo invito: anche se non mi scandalizzo affatto e non mi importa di vedere censurate le parolacce con gli asterischi, supponendo di essere in mezzo a gente civile e predisposta a un dialogo costruttivo, non si potrebbe cercare di usare un linguaggio e uno stile meno aggressivo? Credo di possa far valere la propria opinione anche con un po' più di "fai play"...
Scusate per quest'ultima proposta, ma nei giorni scorsi ho letto alcuni forum di punto informatico e sono rimasto disgustato.... Anche se qui la situazione è di gran lunga migliore, credo che usare toni pacati renda più piacevole la lettura del forum e agevoli lo spirito di collaborazione e, appunto, di comunità.
Lo sviluppatore di K3b scrive sul suo stesso sito che forse sta esagerando con i bugfix; in effetti, sarebbe meglio distribuire una nuova release ogni 3 o 4 mesi, con un bel po di bug risolti, anzichè annunciare un nuovo bugfix ogni 2 giorni. Un tale comportamento è sinonimo di disordine e mancanza di criterio!
mai sentito "release early release often" ? è alla base del metodo open source...
