incredibile, questa ve la devo raccontare...

[xfulviox]

debian 3.0 funzionante da marzo senza un minimo errore, alcun calo di prestazioni, quasi noiosa oserei dire... avevo aperti nicotine, amule, xmms, gaim... apro firebird, digito l'url di linux laptop per care alcune info sul mio portatile... schermo nero.. e consoles inaccessibili, luce harddisk fissa...
che può essere stato?

[#!/bin/sh]

usi qualche driver closed? a volte fanno cose magnifiche....

[VICIUS]

mi ricorda alcuni blocchi che mi sono capitati con i nuovi driver nvidia closed.
blocco totale del sistema in momenti completamente casuali.

ciao

[xfulviox]

no, nessun driver closed... uso quelli nativi del kernel... anche se... a pensarci bene oggi ho installato i gatos... non sono closed, ma potrebbero aver alterato la stabilità di X....

[#!/bin/sh]

su linux non succede mai niente per caso.

[VICIUS]

Originariamente inviato da xfulviox
no, nessun driver closed... uso quelli nativi del kernel... anche se... a pensarci bene oggi ho installato i gatos... non sono closed, ma potrebbero aver alterato la stabilità di X....

avevo installato i gatos su un portatile con una ati m4 che non era supportata da X. a volte quando guardavo un film con mplayer sullo schermo apparivano degli strani artefatti viola/verdi. forse sono proprio loro la causa del blocco.

ciao

[elypepe]

un virusssss !!!!!!!!!!!!!!!!!!!!!!!!!!!!! :

[Allusivo]

Originariamente inviato da #!/bin/sh
su linux non succede mai niente per caso.

è una regola che vale per tutto, mica solo per linux.

[michele.t]

Originariamente inviato da VICIUS
mi ricorda alcuni blocchi che mi sono capitati con i nuovi driver nvidia closed.
blocco totale del sistema in momenti completamente casuali.

ciao

una cosa simile è successa a me, dopo aver lanciato fgl_glxgears, schermo bloccato, luce hdd fissa, riavvio, tutto incasinato, non funzionava nulla. è per questo che voglio sbarazzarmi il prima possibile della mia radeon (bellina come scheda, ma usare linux con driver close dopo quest'esperienza mi sembra una contraddizione. Se ati vorrà che le compro la radeon 100000 dovrà fornirmi in qualche modo dei drivers open).

[#!/bin/sh]

Originariamente inviato da Allusivo
è una regola che vale per tutto, mica solo per linux.

vale per i sistemi *nix

[franklar]

Originariamente inviato da Allusivo
è una regola che vale per tutto, mica solo per linux.

tu non hai mai usato Windows 95, evidentemente

[michele.t]

Originariamente inviato da franklar
tu non hai mai usato Windows 95, evidentemente

e tu evidentemente non hai mai usato windows me!

[Allusivo]

Originariamente inviato da #!/bin/sh
vale per i sistemi *nix

perchè per gli altri sistemi non accade?
ora iniziamo con i flame.. vuoi farmi credere che sui sistemi che non abbiano un kernel unix-like accadono cose inspiegabili degne di x-files? oppure ti riferivi che sia più stabile di uno con beos, o di qualsiasi altro real-time?

Originariamente inviato da franklar
tu non hai mai usato Windows 95, evidentemente

si che l'ho usato per anni, e son stato uno dei primi a cestinarlo, lui e quella porcheria immonda del 98/ME. Windows2000 già dalla metà del 1999 e ho potuto utilizzare proficuamente la macchina.

[Allusivo]

Originariamente inviato da michele.t
e tu evidentemente non hai mai usato windows me!

lol windows MErd

[franklar]

WInME è praticamente uguale a Win98, solo che usa quei 30 MB di ram in più per motivi che sfuggono all'umana comprensione. Però tutto sommato a saperlo tener bene si riusciva ad usarlo.

Win95 invece no, crashava in modo più casuale di un generatore di numeri random a rilevazione di rumore termico un SO davvero entropico


prima di entrare nel flame, secondo me #!/bin/sh voleva dire che in un sistema operativo completamente grafico è più difficile risalire alla causa dell'errore, rispetto ad uno con una potente console. I criptici messaggi d'errore di Windows, i suoi Blue screen of death ormai sono arcinoti. In *NIX un bel cat /var/log/syslog, o un dmesg fanno già un bel pò di luce in più.
My 2 cents è chiaro.

[Allusivo]

Originariamente inviato da franklar
secondo me #!/bin/sh voleva dire che in un sistema operativo completamente grafico è più difficile risalire alla causa dell'errore, rispetto ad uno con una potente console. I criptici messaggi d'errore di Windows, i suoi Blue screen of death ormai sono arcinoti. In *NIX un bel cat /var/log/syslog, o un dmesg fanno già un bel pò di luce in più.
My 2 cents è chiaro.

detta così assume un altro significato, sicuramente avevo travisato le sue parole

[Jøhñ Ðøë]

Originariamente inviato da Allusivo
detta così assume un altro significato, sicuramente avevo travisato le sue parole

vabbeh era chiaro che intendeva questo. In informatica non succedono le cose "a caso". Solo che se vengono disabilitati gli errori per dare l'idea di un OS puiù stabile, non hai modo di recuperare gli errori. Sta di fatto che al primo errore con win la cosa _più veloce_ da fare è formattare... cosa che ha portato nel tempo alla creazione di una massa di ignoranti informatici wizard_addicted che non sanno niente e si sentono pure "poweruser", e se gli sposti il bottone nella release nuova dicono che la release fa schifo

vabbeh, lasciamo stare che si scatta nel flame...

John

p.s. non è riferito a nessuno iin particolare. Semplicemente ne conosco troppa di sta gnte, sia in real che sui forum

[Allusivo]

Originariamente inviato da Jøhñ Ðøë
Solo che se vengono disabilitati gli errori per dare l'idea di un OS puiù stabile, non hai modo di recuperare gli errori.

Non è del tutto esatto, ci sono molti sistemi per risalire alla causa dell'errore. Con le ultime release di XP patchato ho avuto solo una volta una schermata blu, e la causa (il controller raid) era alla luce del sole.

Sta di fatto che al primo errore con win la cosa _più veloce_ da fare è formattare...

Non mi far fare il paladino di MicrozoZ.. ma se tu affermi una cosa del genere scusami ma.. il poweruser sei tu.
Cosa c'entra velocità con risolvibilità di un problema?

[#!/bin/sh]

Originariamente inviato da Allusivo
perchè per gli altri sistemi non accade?
ora iniziamo con i flame.. vuoi farmi credere che sui sistemi che non abbiano un kernel unix-like accadono cose inspiegabili degne di x-files? oppure ti riferivi che sia più stabile di uno con beos, o di qualsiasi altro real-time?

Centriamo il discorso che forse è meglio. Quando parlo in generale mi riferisco agli unici mondi che conosco: quello window$ e quello *nix. Purtroppo non ho tempo per guardarmi anche altre cose, altrimenti mi piscerebbe anche gurdarmi quello che mi manca. Non mi permetterei mai di fare osservazioni su cose che non conosco. Mi riferivo al fatto che in generale i sistemi *nix hanno un comportamento deterministico: tu fai qualcosa e accade qualcosa. Tu lanci un programma e e il programma fa qualcosa. Con un editor di testo puoi andare a spulciarti tutti i log che vuoi ed eventualmente risalire alla causa del problema. Con un editor di testo puoi andare a cambiare i file di configurazione che grazie al cielo non sono fatti come il registro di window$, ma hanno un verso. Con il nostro caro amico uindovs non lo puoi fare. Wincoz non ha un comportamento deterministico. L'intenzione non era quella di aprire un flame. Mi scuso se ho detto cose che potevano essere male interpretate, ma molto spesso uno non ha il tempo/voglia di scrivere un papiro.

[#!/bin/sh]

Originariamente inviato da Allusivo
Non è del tutto esatto, ci sono molti sistemi per risalire alla causa dell'errore. Con le ultime release di XP patchato ho avuto solo una volta una schermata blu, e la causa (il controller raid) era alla luce del sole.
Non mi far fare il paladino di MicrozoZ.. ma se tu affermi una cosa del genere scusami ma.. il poweruser sei tu.
Cosa c'entra velocità con risolvibilità di un problema?

Che casistica hai tu di utilizzo di window$xp? Io ti posso dire che per mestiere faccio il tecnico e ogni giorno con ${qualunqueversionediwin} ho dei problemi incredibili. Ti posso anche dire che molti non sono direttamente risolvibili e nel mio lavoro spesso non puoi formattare per vari motivi:
- comp con dentro i dati che non puoi aprire
- applicativi custom che il cliente ha pagato ma che non puoi/puo' reinstallare direttamente.
Molte volte si prova anche ad agire direttamente sul registro di window$ in quanto se cerchi su technet ti viene proposta come soluzione ad un dato problema, ma anche qui in qualche caso la soluzione non funziona. E poi ogni intervento sul registro di win è sconsigliato da m$ stessa. E' triste da ammettere, ma ha ragione john: con wiin l'unica soluzione percorribile in tempi ragionevoli è formattare.