En tout cas, bizarrement, mon père qui a semble-t-il regardé l'entièreté de la cérémonie à la télé n'a rien vu ... toutefois, ça me ferait plaisir de savoir que ce n'est pas un fake :)
Pour le playback, rien de nouveau:
Les télés chinoises regorgent d'émission variétés pleines d'officiels et de chanteurs/euses dans leurs papiers qui viennent se montrer, et absolument tout ce qui est chanté est en playback, pour garantir que la cérémon... euh... l'émission se déroulera sans aucun accroc (comprendre pas de fausse note, il est évident que des "artistes" qui ont fait l'effort de se mettre bien devant les officiels du gouvernement et du parti n'iront pas faire une déclaration politique juste après...).
Donc, pour le playback, vous pouvez être sûr que personne n'a rien chanté pendant la cérémonie, il est même fortement probable que les musiques entendues ne viennent pas des instruments mais également d'un enregistrement.
S'ils réorganisent les JO dans 100ans, je pense qu'ils remplaceront tout le public et tous les artistes par des robots pour être encore plus sûrs de leur coup...
Quant à remplacer une enfant à cause de sa dentition, quand on pense à tout ce qui est fait n'importe comment juste pour "avoir la face" (c'est à dire qu'on se fout de tout pourvu que les apparences soient sauves), on n'est plus à ça près...
A titre d'anecdote, l'une des premières "mesures" prise pour lutter contre la pollution à Pékin a été de déplacer les capteurs qui mesurent la qualité de l'air: on vire ceux autour des usines, et on va les remettre très très loin en banlieue... enfin, voire à la campagne! Résultat spectaculaire: la qualité de l'air mesurée était bien meilleure!
C'est seulement après qu'ils se sont rendus compte qu'un nuage permanent ça se voit à l'oeil nu et surtout ça se sent...
> A titre d'anecdote, l'une des premières "mesures" prise pour lutter contre la pollution à Pékin a été de déplacer les capteurs qui mesurent la qualité de l'air: on vire ceux autour des usines, et on va les remettre très très loin en banlieue... enfin, voire à la campagne! Résultat spectaculaire: la qualité de l'air mesurée était bien meilleure!
Tiens c'est amusant, c'est exactement la méthode utilisée par la France pour « diminuer » la pollution astronomique de l'eau en Bretagne... Et pourtant, l'Europe avec Natura2000 nous tape bien sur les doigts.
Tous les systèmes plantent, la c'est juste arrivé au mauvais moment
En tant qu'utilisateur de linux au quotidien, j'ai eu aussi pas mal de kernel panic (vive les drivers vidéos)
Le problème de windows c'est pas vraiment les BSOD, c'est le reste
Tout à fait, mais niveau plantage incompréhensible, windows a une bonne longueur d'avance.
Après il est certain qu'un plantage à un moment "crucial" tel que la cérémonie d'ouverture des JO n'est pas du meilleur effet. <hs>Pour info les ordinateurs reliés aux projecteurs fonctionnaient sous xp, qui n'est qu'en beta 3 (également appelé "service pack 3").</hs>
Cela étant, le fait que nous n'ayons pas vu cela à la télévision (ou ailleurs que sur le net) ne signifie pas qu'il s'agisse pour autant d'un fake ou d'une censure "Made in China", mais peut-être simplement du fait que le spectacle était plus intéréssant au centre du stade que sur les plafonds de celui-ci, sur lequel il n'était que projeté des "vidéos d'ambiance".
Le spectacle se tenant d'avantage au centre de la piste, cela semblerai cohérent.
Il n'y a rien d'incomprehensible, que tu n'y comprennes rien c'est possible, ca veut pas dire que c'est incomprehensible.
C'est du code hein, le processeur fait pas des trucs magiques quand c'est Windows qui tourne, un minimum de connaissances de l'OS te permettent d'assez vite trouver l'origine (driver, OS, hw) d'un BSOD quand tu sais ce qu'il faut lire, tout comme avec un kernel panic.
Effectivement, mais c'est plutôt la logique "propriétaire" du code qui incite à la mauvaise qualité. L'OS peut être aussi bon qu'il veut, mais un gros binaire venant de nul part pour se greffer peut tout casser et on ne peut rien y faire. Tu me répondras qu'il existe des pilotes certifiés par Microsoft, mais combien de constructeurs le font réellement? D'ailleurs c'est amusant de voir du matériel faire planter systématiquement MS Windows (dernièrement une carte TV TNT low cost créant un BDOS à un démarrage sur 2) et un fonctionnement quasi parfait avec un noyau Linux.
Ah oui tiens, meme dans les drivers libres il y a des bugs.
Sur ma Debian SID (donc non recommandée pour les serveurs ni les postes de travails), j'ai effectivement ces kernel disponibles.
En Debian testing, il n'y sont pas encore... curieux, non? parce qu'ils n'ont pas encore été assez testés, et une fois que ce le sera, ils le seront encore avant de passer dasn Debian Stable.
Tu vois le principe?
Voilà pourquoi Linuix (Debian) est sibien, c'est parce que l'on choisi le niveau de fraîcheur/stabilité des paquets.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Le principe ? Oui oui, parce que ces bugs ils n'etaient pas dans le 2.6.0 qui est sorti hein ?
C'est connu, les kernels 2.2.0, 2.4.0 et 2.6.0 sont exempts de bugs, ils sont parfaits et les ameliorations qui sont faites par la suite ne servent a rien...
Je conseille a tous ceux d'entre vous qui croyez en la perfection du code libre et de Linux (ou du proprio d'ailleurs hein, c'est meme topo) de lire des bouquins sur les cycles de developpement (software development lifecycle, aucune idee de comment traduire ca autrement), ca risque de briser certains de vos reves, mais ca vous apprendra plein de trucs interessants.
Ou ? Mais c'est tres simple: RIEN jusqu'a aujourd'hui ne montre que les projets libres ont une qualite de code meilleure (ou pire hein) que les projets proprietaires.
Des bugs il y en a partout, et faire du code GPL ne signifie en rien qu'ils ont magiquement tout apparaitre et etre resolus. Cette phrase de "given enough eyes all bugs are shallow" a ete demontree comme une anerie par assez de softs GPL troues pour ne plus valoir un sou.
Je parle en pour moi, mais en effet je ne crois pas en un code libre parfait, je crois juste en un code libre et cela me suffit.
Content de savoir que le sp3 est dispo ;-)
le processeur fait pas des trucs magiques
On est tous d'accord là dessus, il est donc inutile de s'énerver...
Par contre, un système fermé et opaque empêche de trouver un plantage donc du coup, quand le plantage semble mystérieux, ça semble encore plus mystérieux...
Donc que Windows est pas top (au niveau technique et au niveau de l'accès à la connaissance -son, code source-), on le sait tous (même Toi), qu'il ne rend pas le proc magique, on le sait tous mais il est compréhensible et excusable que les plantages (parfois très absurdes) donnent lieu à une mauvaise expression...
Par contre, un système fermé et opaque empêche de trouver un plantage donc du coup, quand le plantage semble mystérieux, ça semble encore plus mystérieux...
Faux, il t'empeche de le corriger, pas de le localiser.
Donc que Windows est pas top (au niveau technique et au niveau de l'accès à la connaissance -son, code source-), on le sait tous (même Toi)
Parles pour toi mon cher.
mais il est compréhensible et excusable que les plantages (parfois très absurdes) donnent lieu à une mauvaise expression...
Un BSOD est tout aussi simple a comprendre qu'un kernel panic. Tu sais parfaitement qu'a la vue d'un kernel panic, quasiment personne ne va aller jeter un oeil aux sources pour essayer de comprendre le probleme, car tres tres peu de gens ont les competences necessaires pour faire du debugging niveau kernel.
Alors cette histoire que le manque de sources rend la chose pire sous Windows est une anerie, car sous Linux quasiment personne ne les regarde.
Un BSOD est tout aussi simple a comprendre qu'un kernel panic. Tu sais parfaitement qu'a la vue d'un kernel panic, quasiment personne ne va aller jeter un oeil aux sources pour essayer de comprendre le probleme, car tres tres peu de gens ont les competences necessaires pour faire du debugging niveau kernel.
Franchement, avec un minimum de connaissances en C, un kernel panic est compréhensible. OK, ça limite le public aux devs un minimum compétants, mais ça fait déjà pas mal de monde chez les utilisateurs de linux ... Un BSOD, personne ne pourra jamais le lire, on n'a même une backtrace avec le nom des symboles ...
Un kernel panic est comprehensible pour un developpeur C ? Tu me permettras d'en douter, faut non seulement connaitre le C, mais faut aussi savoir comment le kernel fonctionne si tu veux avoir un espoir de vraiment comprendre et corriger la chose sans tout foutre en l'air. Le developpement cote kernel c'est pas vraiment aussi simple qu'en user-mode.
Alors dev C + connaissances kernel ca fait combien de monde chez les utilisateurs Linux ? Voyons, ca fait quoi ? 1% des utilisateurs ? Au total ca fait donc 1% de 1% de la population, super...
Et le jour ou Linux sera repandu chez tout le monde et pas seulement les geeks ca sera quoi la proportion ? Ah oui, encore moins...
Heu, on parlait de comprendre le problème, pas forcément que _je_ le comprenne. Je peux aller le rapporter aux devs du noyau avec un truc du genre "j'ai un pointeur null qui se trouve passé en paramètre à telle fonction". J'aurais sûrement quelques retours qui me permetteront de tester qqch qui va permettre de bien identifier le problème.
Dis moi, combien de gens rapportent les "rapports" des BSOD chez MS ?
Beaucoup car c'est automatise ! Ils envoyent un dump aussi qui permet aux developpeurs de debugger la chose, et si je ne me trompes pas, il y a meme des options dans le systeme de notification pour acceder a plus d'infos (avec demande a l'utilisateur toujours) si les devs ont recu des dumps de ce BSOD avant et ont besoin de plus d'infos pour trouver le probleme.
Meme mieux, apres connection au serveur MS, si MS a deja sorti un correctif pour le probleme, ou si un driver update (NVidia, etc...) est sorti pour corriger le probleme, tu es averti et peux aller l'installer.
Oh et bien sur, quand le crash se trouve dans un element externe (driver d'autre societe, etc...) on les avertit et leur envoie l'information.
Ca a l'air assez bien comme système, mais je ne connais vraiment pas vu le temps depuis lequel j'ai quitté MS ... Mais bon, j'ai jamais entendu personne me parler de ça.
Par contre, la plupart des BSOD ne crachent pas tout le système, pour pouvoir envoyer le rapport ? Parce que si c'est un freeze du système, bon courage pour envoyer (ou même enregistrer) le rapport ...
C'est presque normal que tu n'en entendes pas parler, on essaye de faire ca de maniere aussi non-intrusive que possible. Ca s'appelle Online Crash Analysis et c'est dans l'OS depuis XP si je ne me trompes pas.
Pour ce qui est des BSOD, un BSOD c'est un crash, t'as un ecran bleu, dans ce cas la t'as un dump(parce que l'ecran bleu c'est le noyau qui l'affiche apres avoir realise qu'il y a qqe chose qui cloche, et en plus d'afficher ce joli ecran bleu il sauve le dump) et le systeme au prochain boot notifiera MS.
Pour les freezes (systeme tourne en boucle), effectivement ca ne gere pas ca, mais c'est un peu le meme probleme partout la (bien que l'utilisateur puisses le generer si ca le chante).
Heu, je ferais une différence entre "non intrusif" et "ne pas en avoir entendu parler" : ça fait quand même un peu genre on fait ça dans ton dos. Ca peut être non-intrusif tout en en informant l'utilisateur.
Merci pour la précision pour les BSOD, je pensais que c'était un crash vraiment "dur". Par contre, sous linux, j'ai déjà pris un kernal panic lors du déchargement d'un module, et mon système tournait toujours ; j'ai même pu recharger le module corrigé sans rebooter ...
Tout a fait, le systeme informe l'utilisateur avant d'envoyer quoi que ce soit et l'utilisateur peut jeter un oeil a ce qui est envoye, c'est pas fait en secret, mais c'est vraiment tout simple: une boite de dialogue qui apparait apres que tu aies reboote et qui te demande si tu veux envoyer l'info, c'est tout.
Par contre, un système fermé et opaque empêche de trouver un plantage donc du coup, quand le plantage semble mystérieux, ça semble encore plus mystérieux...
Faux, il t'empeche de le corriger, pas de le localiser.
(bien sûr localiser un truc dans le noir, c'est plus facile...)
à mettre en regard de
mais faut aussi savoir comment le kernel fonctionne si tu veux avoir un espoir de vraiment comprendre et corriger la chose sans tout foutre en l'air
Tu ne fais pas tout le temps les mêmes subtilités. Disons que parler avec Toi nous contraint à être très précis (vu que sinon c'est réponse au ton désagrable) alors que Toi non, Tu vas quand même pas Te contraindre de la même manière que ce que Tu demandes aux autres...
Alors cette histoire que le manque de sources rend la chose pire sous Windows est une anerie, car sous Linux quasiment personne ne les regarde.
Bon, passons sur la stupidité (faible et selon moi) de l'argument (qui permettrait de faire des lois scandaleuses si on l'appliquait)
Même sans compétences noyau, on peut *comprendre* les causes d'un crash en en parlant avec un ami (qui aura p-ê plus de compétences) ou sur le web (Tu sais sur le site d'un gars qui a plus de compétences) ou même peu à peu en commençant par des bugs reports sur son player de son par exemple (en montant en compétence si Tu veux)
Après, pour ce qui est de résoudre, c'est effectivement encore un autre problème. J'imagine que le fait que les gens en ait la *possibilité* Te passe au dessus vu que c'est bien connu personne ne le fait, il suffi t de le crier pour que ce soit vrai.
(Je parie que Tu n'as jamais parler de candyman à voix haute.)
(bien sûr localiser un truc dans le noir, c'est plus facile...)
Dans le noir ? Marrant, je me demandes comment les developpeurs de drivers font pour debugger leurs machines quand leur driver en developpement fait planter le systeme, parce qu'il faut comprendre le crash pour decouvrire le probleme dans le driver, et ce crash peut arriver ailleurs que dans le driver...
C'est un peu le probleme avec les gens qui parlent de Windows sans rien y connaitre, ils balancent leur prejuges, souvent faux, sans vraiment savoir de quoi ils parlent.
Par exemple ils te disent que tu bosses dans le noir car tu n'as pas acces aux sources, ils te disent que ta stack est illisible dans un BSOD, etc...
Alors que dans la realite, les symboles de debuggage sont disponible sur le site de MS (cf. http://www.microsoft.com/whdc/DevTools/Debugging/symbolpkg.m(...) par exemple) et le debugger kernel de Windows est des annees lumieres en avance de ce qui se fait niveau debuggage du kernel sous Linux, en offrant notamment une analyse du crash automatique dans bien des cas.
C'est un peu le probleme avec les gens qui parlent de Windows sans rien y connaitre, ils balancent leur prejuges, souvent faux, sans vraiment savoir de quoi ils parlent.
Par exemple ils te disent que tu bosses dans le noir car tu n'as pas acces aux sources
C'est fou ce que les ignorants osent dire.
Tu oublies qu'un Kernel Panic ou un BSOD c'est pas forcément un problème dans le Kernel, ça peut aussi être un problème matériel (c'est même très souvent la cause).
Dans ce cas précis, comparons les informations données par un Kernel Panic et un BSOD :
- Avec un Kernel Panic, j'ai droit à une backtrace. Si on est quelque peu expérimenté, on peut en déduire très rapidement où est le problème. Par exemple, récemment j'ai eu un problème matériel avec une carte réseau qui causait des Kernel Panics. J'ai su que ça venait de ma carte réseau parce que au vu du backtrace c'était évident : les fonctions dans lesquelles il se plantait commençaient par r8169_, qui est le nom du driver de ma carte réseau. J'ai donc pu prendre les actions nécéssaires pour pallier au problème.
- Avec un BSOD, j'ai droit à une seule ligne de texte cryptique et minimaliste (du style MACHIN_IRQ_BIDULE) avec des adresses mémoire qui bien évidemment ne signifient rien pour moi. Je n'ai aucun moyen de savoir d'où vient le problème.
Voilà pourquoi je suis bien plus avancé avec un Kernel Panic qu'avec un BSOD.
C'est un peu parler sans savoir là je pense et avec pas mal de mauvaise fois.
On peut retourner l'argumentaire dans l'autre sens :
Lors d'un kernel panic je vois des trucs bizarres qui s'affichent même que ça commence par r8169_ ce qui ne veut rien dire.
Lors d'un BSOD je vois marqué HP machin et je sais que c'est le pilote de cette marque toute pourrie d'imprimante qui m'a mis à plat mon beau windows tout parfait.
Pitié un BSOD ça s'analyse quand on sait le faire et c'est aussi utile qu'un laconique "guru meditation" pour le commun des mortels. Et un Kernel panic, ben c'est tout pile poil pareil.
Sans être un gourou, il faut admettre que dans un kernel panic linux, quand la pile n'est pas corrompue, on a une backtrace assez complète, ce qui permet, avec un peu de déduction, de deviner la source du problème. Pas besoin de chercher pendant des heures un débuggeur, des symboles de débuggage (tiens, ça marche comment avec du code de pilotes tiers ?) et la marche à suivre pour récupérer un dump.
En ce qui concerne la récupération automatique des kernel dumps, certaines distributions on mit cela en place de manière bien conviviale: après le reboot, une petite notification apparaît pour demander d'envoyer le dump à http://www.kerneloops.org/
Les symboles de debuggage sont en ligne, le debugger ira les chercher sur le serveur MS.
Quand au code de pilotes tiers, le debugger infere la stack, il est capable de te dire dans quel module c'est et tres souvent de te refaire la stack en dessous de ce module.
Notes que Watson t'affiche normalement la stack avec uniquement les noms de module sans debugger.
Avec un BSOD, j'ai droit à une seule ligne de texte cryptique et minimaliste (du style MACHIN_IRQ_BIDULE) avec des adresses mémoire qui bien évidemment ne signifient rien pour moi. Je n'ai aucun moyen de savoir d'où vient le problème.
Non, avec un BSOD t'as un dump complet stocke sur ton systeme, que tu peux loader dans WinDbg (dispo gratuitement sur le site de MS), et les symboles de deboggage dispo gratuitement sur le site de MS aussi.
Avec ca tu as :
a) Une stack trace avec les noms de fonction
b) Un debugger qui te permet d'analyser ton crash automatiquement dans bien des cas (!analyze -v dans le debugger) et te donner des infos qu'un non-initie serait incapable de trouver.
Tu trouves un BSOD incomprehensible parce que tu es habitue au kernel panic Linux et que tu ne sais pas quoi faire avec un BSOD, la realite c'est que t'as une quantite d'infos elevee qui t'es donnee, tu ne sais simplement pas ou les trouver car tu ne connais pas Windows autant que tu connais Linux.
Pasbill, es-tu un multi ? J'eus l'impression d'avoir eu affaire à une personne un peu moins de mauvaise fois avec des arguments techniques, sinon recevables, au moins valables. Les temps changent...
Non juste de l'experience dans le debuggage de kernel, c'est tres proche du cauchemard sur Linux(et Linus y est pour bcp avec sa longe opposition a avoir un kernel debugger), kgdb ameliore les choses mais il y a encore du boulot pour que ce soit un minimum agreable.
Tout à fait, mais niveau plantage incompréhensible, windows a une bonne longueur d'avance.
En même temps, je n'ai pas vu d'écran bleu sur un pc sous windows à moi depuis des années (l'arrivée d'XP). J'ai fortement l'impression que ça dépend de l'interface chaise-clavier et/ou de l'achat de périphériques buggés. Bref faut le chercher un minimum. A l'époque des win9x, la c'était plus drôle.
Bon maintenant je l'utilise bien peu donc c'est moins représentatif, mais je ne crois pas avoir vu mon vista planté une seule fois (ni même freezer)..
> En même temps, je n'ai pas vu d'écran bleu sur un pc sous windows à moi depuis des années
Je pensais comme ça jusqu'à la semaine dernière où lorsque je voulais imprimer un certain un document Word, j'avais un BSOD. et sur 3 PC différents. A priori un graphique visio qui était mal digéré par la chaîne d'impression.
Mais c'est quand même inacceptable qu'une impression foute le kernel en l'air.
Tous les systèmes plantent, la c'est juste arrivé au mauvais moment
C'est ce qu'on critique. Pas que ça plante, mais que ça plante au mauvais moment.
Que ça fasse un kernel panic au reboot, ce n'est pas grave. Ça arrive généralement quand tu as changé ta conf (tu sais donc ce que tu as fait), ou quand tu as utilisé des drivers moisis^W propriétaires^W privateurs (whatever, c'est synonyme tout ça).
Mais surtout ça arrive quand tu reboote. C'est quelque chose que je n'ai jamais compris perso cette comparaison entre les kernel panics et les BSOD. Le BSOD il peut arriver au moment d'un reboot certes, ou à l'ouverture d'une session, mais enfin ce n'est pas le plus courant, ni le plus gênant.
Le plus gênant, c'est quand ça arrive en plein milieu d'une phase de prod sur un distributeur de billets, en plein milieu d'une cérémonie d'ouverture des JO, en plein milieu d'une présentation de MS du nouveau Windows top stable et sicioure, dans les bornes SNCF, etc.
À ma connaissance il n'y a pas souvent (du tout?) de kernel panics en plein milieu d'une utilisation. À la limite des oops en cas de matériels défectueux. Mais c'est tout.
des "oops" c'est un vrai terme ou pas ? Perso, j'ai fait tombé mon laptop et de temps en temps j'ai écran noir, puis ça revient mais avec X tout pété et je dois rebooter, donc je soupçonne la carte graphique d'avoir pris un coup... enfin bref, je pourrais dire aux autres que je fais des oops ?
À ma connaissance il n'y a pas souvent (du tout?) de kernel panics en plein milieu d'une utilisation. À la limite des oops en cas de matériels défectueux. Mais c'est tout.
Ca m'arrive assez souvent que ca freeze complètement (même pas d'accès possible par SSH) avec les drivers ATI libres, quand je lance des programmes qui utilisent la 3d
Ca me le fait aussi sur un PC avec une i810 quand je redémarre le serveur X
Le problème de stabilité de windows c'est pas les BSOD qui arrivent très rarement, c'est que tout l'applicatif est troué de bugs (qui n'entrainent pas tout le temps de plantages)
J'ose espérer que ça s'est amélioré, mais le support du chinois par les distributions GNU/Linux n'était pas il y a peu tel qu'on pouvait les installer sans savoir un mot d'anglais.
La plupart des Chinois ne parlent pas et lisent encore moins l'anglais ; ça fait très longtemps (depuis presque le début ?) que Windows est piratable dans cette langue, et que les Chinois piratent massivement tous les logciels qui leur passent sous la main pour l'avantage compétitif immédiat que ça procure, sans craindre aucune répression.
# rss
Posté par Maxime (site web personnel) . Évalué à 0.
[^] # Re: rss
Posté par Rémi baudruche . Évalué à 3.
j'ai trouvé d'autres articles :
http://www.theinquirer.fr/2008/08/12/lecran_bleu_de_la_mort_(...)
http://www.smh.com.au/news/off-the-field/bills-blue-screen-o(...)
[^] # Re: rss
Posté par Elfir3 . Évalué à 1.
[^] # Re: rss
Posté par benja . Évalué à 5.
[^] # Re: rss
Posté par M . Évalué à 6.
[^] # Re: rss
Posté par liperon . Évalué à 8.
http://www.chine-informations.com/actualite/jo-la-chanson-de(...)
[^] # Re: rss
Posté par vincent_k (site web personnel) . Évalué à 6.
[^] # Re: rss
Posté par Maclag . Évalué à 7.
Les télés chinoises regorgent d'émission variétés pleines d'officiels et de chanteurs/euses dans leurs papiers qui viennent se montrer, et absolument tout ce qui est chanté est en playback, pour garantir que la cérémon... euh... l'émission se déroulera sans aucun accroc (comprendre pas de fausse note, il est évident que des "artistes" qui ont fait l'effort de se mettre bien devant les officiels du gouvernement et du parti n'iront pas faire une déclaration politique juste après...).
Donc, pour le playback, vous pouvez être sûr que personne n'a rien chanté pendant la cérémonie, il est même fortement probable que les musiques entendues ne viennent pas des instruments mais également d'un enregistrement.
S'ils réorganisent les JO dans 100ans, je pense qu'ils remplaceront tout le public et tous les artistes par des robots pour être encore plus sûrs de leur coup...
Quant à remplacer une enfant à cause de sa dentition, quand on pense à tout ce qui est fait n'importe comment juste pour "avoir la face" (c'est à dire qu'on se fout de tout pourvu que les apparences soient sauves), on n'est plus à ça près...
A titre d'anecdote, l'une des premières "mesures" prise pour lutter contre la pollution à Pékin a été de déplacer les capteurs qui mesurent la qualité de l'air: on vire ceux autour des usines, et on va les remettre très très loin en banlieue... enfin, voire à la campagne! Résultat spectaculaire: la qualité de l'air mesurée était bien meilleure!
C'est seulement après qu'ils se sont rendus compte qu'un nuage permanent ça se voit à l'oeil nu et surtout ça se sent...
[^] # Re: rss
Posté par jm trivial (site web personnel) . Évalué à 3.
Tiens c'est amusant, c'est exactement la méthode utilisée par la France pour « diminuer » la pollution astronomique de l'eau en Bretagne... Et pourtant, l'Europe avec Natura2000 nous tape bien sur les doigts.
Ici aussi, on a nos cons.
[^] # Re: rss
Posté par Vador Dark (site web personnel) . Évalué à 4.
[^] # Re: rss
Posté par jm trivial (site web personnel) . Évalué à 2.
[^] # Re: rss
Posté par Vador Dark (site web personnel) . Évalué à 3.
[^] # Re: rss
Posté par Maclag . Évalué à 2.
--
Matthieu, diplomate expérimenté
# Ca arrive
Posté par timid . Évalué à -3.
En tant qu'utilisateur de linux au quotidien, j'ai eu aussi pas mal de kernel panic (vive les drivers vidéos)
Le problème de windows c'est pas vraiment les BSOD, c'est le reste
[^] # Re: Ca arrive
Posté par iXTom . Évalué à 10.
Après il est certain qu'un plantage à un moment "crucial" tel que la cérémonie d'ouverture des JO n'est pas du meilleur effet. <hs>Pour info les ordinateurs reliés aux projecteurs fonctionnaient sous xp, qui n'est qu'en beta 3 (également appelé "service pack 3").</hs>
Cela étant, le fait que nous n'ayons pas vu cela à la télévision (ou ailleurs que sur le net) ne signifie pas qu'il s'agisse pour autant d'un fake ou d'une censure "Made in China", mais peut-être simplement du fait que le spectacle était plus intéréssant au centre du stade que sur les plafonds de celui-ci, sur lequel il n'était que projeté des "vidéos d'ambiance".
Le spectacle se tenant d'avantage au centre de la piste, cela semblerai cohérent.
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à -10.
C'est du code hein, le processeur fait pas des trucs magiques quand c'est Windows qui tourne, un minimum de connaissances de l'OS te permettent d'assez vite trouver l'origine (driver, OS, hw) d'un BSOD quand tu sais ce qu'il faut lire, tout comme avec un kernel panic.
[^] # Re: Ca arrive
Posté par Sébastien B. . Évalué à 10.
de connaissances de l'OS te permettent d'assez vite trouver l'origine (driver, OS, hw,meteo au Groenland, astrologie, hasard, ...)
[^] # Re: Ca arrive
Posté par suJeSelS . Évalué à 2.
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à -3.
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.26.2
Ath5k: fix memory corruption
Ath5k: kill tasklets on shutdown
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.26.1
ath5k: don't enable MSI, we cannot handle it yet
b43legacy: Release mutex in error handling code
DVB: cx23885: SRAM changes for the 885 and 887 silicon parts
DVB: cx23885: Reallocated the sram to avoid concurrent VIDB/C issues
DVB: cx23885: Ensure PAD_CTRL is always reset to a sensible default
V4L: cx23885: Bugfix for concurrent use of /dev/video0 and /dev/video1
V4L: uvcvideo: Fix a buffer overflow in format descriptor parsing
...
Ah oui tiens, meme dans les drivers libres il y a des bugs.
Faut arreter cette connerie comme quoi les drivers libres c'est la panacee, il y a des bugs dans les 2 mondes.
[^] # Re: Ca arrive
Posté par GG (site web personnel) . Évalué à 1.
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.26.2
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.26.1
...
Ah oui tiens, meme dans les drivers libres il y a des bugs.
Sur ma Debian SID (donc non recommandée pour les serveurs ni les postes de travails), j'ai effectivement ces kernel disponibles.
En Debian testing, il n'y sont pas encore... curieux, non? parce qu'ils n'ont pas encore été assez testés, et une fois que ce le sera, ils le seront encore avant de passer dasn Debian Stable.
Tu vois le principe?
Voilà pourquoi Linuix (Debian) est sibien, c'est parce que l'on choisi le niveau de fraîcheur/stabilité des paquets.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 2.
C'est connu, les kernels 2.2.0, 2.4.0 et 2.6.0 sont exempts de bugs, ils sont parfaits et les ameliorations qui sont faites par la suite ne servent a rien...
Je conseille a tous ceux d'entre vous qui croyez en la perfection du code libre et de Linux (ou du proprio d'ailleurs hein, c'est meme topo) de lire des bouquins sur les cycles de developpement (software development lifecycle, aucune idee de comment traduire ca autrement), ca risque de briser certains de vos reves, mais ca vous apprendra plein de trucs interessants.
[^] # Re: Ca arrive
Posté par benja . Évalué à 2.
Oui et où veux-tu en venir ?
Enfin "on" se doute d'où tu veux en venir, mais là tu manque sérieusement d'un argumentaire. A+
ps: tiens, le xp sp3, est-il déja sorti ?
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 0.
Des bugs il y en a partout, et faire du code GPL ne signifie en rien qu'ils ont magiquement tout apparaitre et etre resolus. Cette phrase de "given enough eyes all bugs are shallow" a ete demontree comme une anerie par assez de softs GPL troues pour ne plus valoir un sou.
Sinon, oui XP SP3 est deja sorti.
[^] # Re: Ca arrive
Posté par benja . Évalué à 3.
Content de savoir que le sp3 est dispo ;-)
[^] # Re: Ca arrive
Posté par tuXico . Évalué à 1.
On est tous d'accord là dessus, il est donc inutile de s'énerver...
Par contre, un système fermé et opaque empêche de trouver un plantage donc du coup, quand le plantage semble mystérieux, ça semble encore plus mystérieux...
Donc que Windows est pas top (au niveau technique et au niveau de l'accès à la connaissance -son, code source-), on le sait tous (même Toi), qu'il ne rend pas le proc magique, on le sait tous mais il est compréhensible et excusable que les plantages (parfois très absurdes) donnent lieu à une mauvaise expression...
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 1.
Faux, il t'empeche de le corriger, pas de le localiser.
Donc que Windows est pas top (au niveau technique et au niveau de l'accès à la connaissance -son, code source-), on le sait tous (même Toi)
Parles pour toi mon cher.
mais il est compréhensible et excusable que les plantages (parfois très absurdes) donnent lieu à une mauvaise expression...
Un BSOD est tout aussi simple a comprendre qu'un kernel panic. Tu sais parfaitement qu'a la vue d'un kernel panic, quasiment personne ne va aller jeter un oeil aux sources pour essayer de comprendre le probleme, car tres tres peu de gens ont les competences necessaires pour faire du debugging niveau kernel.
Alors cette histoire que le manque de sources rend la chose pire sous Windows est une anerie, car sous Linux quasiment personne ne les regarde.
[^] # Re: Ca arrive
Posté par benoar . Évalué à 2.
Franchement, avec un minimum de connaissances en C, un kernel panic est compréhensible. OK, ça limite le public aux devs un minimum compétants, mais ça fait déjà pas mal de monde chez les utilisateurs de linux ... Un BSOD, personne ne pourra jamais le lire, on n'a même une backtrace avec le nom des symboles ...
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 0.
Alors dev C + connaissances kernel ca fait combien de monde chez les utilisateurs Linux ? Voyons, ca fait quoi ? 1% des utilisateurs ? Au total ca fait donc 1% de 1% de la population, super...
Et le jour ou Linux sera repandu chez tout le monde et pas seulement les geeks ca sera quoi la proportion ? Ah oui, encore moins...
[^] # Re: Ca arrive
Posté par benoar . Évalué à 3.
Dis moi, combien de gens rapportent les "rapports" des BSOD chez MS ?
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 1.
Beaucoup car c'est automatise ! Ils envoyent un dump aussi qui permet aux developpeurs de debugger la chose, et si je ne me trompes pas, il y a meme des options dans le systeme de notification pour acceder a plus d'infos (avec demande a l'utilisateur toujours) si les devs ont recu des dumps de ce BSOD avant et ont besoin de plus d'infos pour trouver le probleme.
Meme mieux, apres connection au serveur MS, si MS a deja sorti un correctif pour le probleme, ou si un driver update (NVidia, etc...) est sorti pour corriger le probleme, tu es averti et peux aller l'installer.
Oh et bien sur, quand le crash se trouve dans un element externe (driver d'autre societe, etc...) on les avertit et leur envoie l'information.
[^] # Re: Ca arrive
Posté par benoar . Évalué à 2.
Par contre, la plupart des BSOD ne crachent pas tout le système, pour pouvoir envoyer le rapport ? Parce que si c'est un freeze du système, bon courage pour envoyer (ou même enregistrer) le rapport ...
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 2.
Pour ce qui est des BSOD, un BSOD c'est un crash, t'as un ecran bleu, dans ce cas la t'as un dump(parce que l'ecran bleu c'est le noyau qui l'affiche apres avoir realise qu'il y a qqe chose qui cloche, et en plus d'afficher ce joli ecran bleu il sauve le dump) et le systeme au prochain boot notifiera MS.
Pour les freezes (systeme tourne en boucle), effectivement ca ne gere pas ca, mais c'est un peu le meme probleme partout la (bien que l'utilisateur puisses le generer si ca le chante).
[^] # Re: Ca arrive
Posté par benoar . Évalué à 2.
Merci pour la précision pour les BSOD, je pensais que c'était un crash vraiment "dur". Par contre, sous linux, j'ai déjà pris un kernal panic lors du déchargement d'un module, et mon système tournait toujours ; j'ai même pu recharger le module corrigé sans rebooter ...
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: Ca arrive
Posté par tuXico . Évalué à 2.
Faux, il t'empeche de le corriger, pas de le localiser.
(bien sûr localiser un truc dans le noir, c'est plus facile...)
à mettre en regard de
mais faut aussi savoir comment le kernel fonctionne si tu veux avoir un espoir de vraiment comprendre et corriger la chose sans tout foutre en l'air
Tu ne fais pas tout le temps les mêmes subtilités. Disons que parler avec Toi nous contraint à être très précis (vu que sinon c'est réponse au ton désagrable) alors que Toi non, Tu vas quand même pas Te contraindre de la même manière que ce que Tu demandes aux autres...
Alors cette histoire que le manque de sources rend la chose pire sous Windows est une anerie, car sous Linux quasiment personne ne les regarde.
Bon, passons sur la stupidité (faible et selon moi) de l'argument (qui permettrait de faire des lois scandaleuses si on l'appliquait)
Même sans compétences noyau, on peut *comprendre* les causes d'un crash en en parlant avec un ami (qui aura p-ê plus de compétences) ou sur le web (Tu sais sur le site d'un gars qui a plus de compétences) ou même peu à peu en commençant par des bugs reports sur son player de son par exemple (en montant en compétence si Tu veux)
Après, pour ce qui est de résoudre, c'est effectivement encore un autre problème. J'imagine que le fait que les gens en ait la *possibilité* Te passe au dessus vu que c'est bien connu personne ne le fait, il suffi t de le crier pour que ce soit vrai.
(Je parie que Tu n'as jamais parler de candyman à voix haute.)
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 1.
Dans le noir ? Marrant, je me demandes comment les developpeurs de drivers font pour debugger leurs machines quand leur driver en developpement fait planter le systeme, parce qu'il faut comprendre le crash pour decouvrire le probleme dans le driver, et ce crash peut arriver ailleurs que dans le driver...
C'est un peu le probleme avec les gens qui parlent de Windows sans rien y connaitre, ils balancent leur prejuges, souvent faux, sans vraiment savoir de quoi ils parlent.
Par exemple ils te disent que tu bosses dans le noir car tu n'as pas acces aux sources, ils te disent que ta stack est illisible dans un BSOD, etc...
Alors que dans la realite, les symboles de debuggage sont disponible sur le site de MS (cf. http://www.microsoft.com/whdc/DevTools/Debugging/symbolpkg.m(...) par exemple) et le debugger kernel de Windows est des annees lumieres en avance de ce qui se fait niveau debuggage du kernel sous Linux, en offrant notamment une analyse du crash automatique dans bien des cas.
[^] # Re: Ca arrive
Posté par tuXico . Évalué à -1.
Par exemple ils te disent que tu bosses dans le noir car tu n'as pas acces aux sources
C'est fou ce que les ignorants osent dire.
[^] # Re: Ca arrive
Posté par e-t172 (site web personnel) . Évalué à 3.
Dans ce cas précis, comparons les informations données par un Kernel Panic et un BSOD :
- Avec un Kernel Panic, j'ai droit à une backtrace. Si on est quelque peu expérimenté, on peut en déduire très rapidement où est le problème. Par exemple, récemment j'ai eu un problème matériel avec une carte réseau qui causait des Kernel Panics. J'ai su que ça venait de ma carte réseau parce que au vu du backtrace c'était évident : les fonctions dans lesquelles il se plantait commençaient par r8169_, qui est le nom du driver de ma carte réseau. J'ai donc pu prendre les actions nécéssaires pour pallier au problème.
- Avec un BSOD, j'ai droit à une seule ligne de texte cryptique et minimaliste (du style MACHIN_IRQ_BIDULE) avec des adresses mémoire qui bien évidemment ne signifient rien pour moi. Je n'ai aucun moyen de savoir d'où vient le problème.
Voilà pourquoi je suis bien plus avancé avec un Kernel Panic qu'avec un BSOD.
[^] # Re: Ca arrive
Posté par SF . Évalué à 5.
C'est un peu parler sans savoir là je pense et avec pas mal de mauvaise fois.
On peut retourner l'argumentaire dans l'autre sens :
Lors d'un kernel panic je vois des trucs bizarres qui s'affichent même que ça commence par r8169_ ce qui ne veut rien dire.
Lors d'un BSOD je vois marqué HP machin et je sais que c'est le pilote de cette marque toute pourrie d'imprimante qui m'a mis à plat mon beau windows tout parfait.
Pitié un BSOD ça s'analyse quand on sait le faire et c'est aussi utile qu'un laconique "guru meditation" pour le commun des mortels. Et un Kernel panic, ben c'est tout pile poil pareil.
[^] # Re: Ca arrive
Posté par benja . Évalué à 2.
En ce qui concerne la récupération automatique des kernel dumps, certaines distributions on mit cela en place de manière bien conviviale: après le reboot, une petite notification apparaît pour demander d'envoyer le dump à http://www.kerneloops.org/
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 0.
Google: windows kernel debugger
1er lien, installes, ca prend bien 3 minutes.
Les symboles de debuggage sont en ligne, le debugger ira les chercher sur le serveur MS.
Quand au code de pilotes tiers, le debugger infere la stack, il est capable de te dire dans quel module c'est et tres souvent de te refaire la stack en dessous de ce module.
Notes que Watson t'affiche normalement la stack avec uniquement les noms de module sans debugger.
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 1.
Non, avec un BSOD t'as un dump complet stocke sur ton systeme, que tu peux loader dans WinDbg (dispo gratuitement sur le site de MS), et les symboles de deboggage dispo gratuitement sur le site de MS aussi.
Avec ca tu as :
a) Une stack trace avec les noms de fonction
b) Un debugger qui te permet d'analyser ton crash automatiquement dans bien des cas (!analyze -v dans le debugger) et te donner des infos qu'un non-initie serait incapable de trouver.
Tu trouves un BSOD incomprehensible parce que tu es habitue au kernel panic Linux et que tu ne sais pas quoi faire avec un BSOD, la realite c'est que t'as une quantite d'infos elevee qui t'es donnee, tu ne sais simplement pas ou les trouver car tu ne connais pas Windows autant que tu connais Linux.
[^] # Re: Ca arrive
Posté par yellowiscool . Évalué à 7.
Et le jour ou Linux sera repandu chez tout le monde et pas seulement les geeks ca sera quoi la proportion ?
Donc chez microsoft aussi on pense que Linux sera un jour répandu chez tout le monde.
Envoyé depuis mon lapin.
[^] # Re: Ca arrive
Posté par zebra3 . Évalué à 2.
Donc chez microsoft aussi on pense
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ca arrive
Posté par benja . Évalué à 2.
[^] # Re: Ca arrive
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Ca arrive
Posté par Psychofox (Mastodon) . Évalué à 2.
En même temps, je n'ai pas vu d'écran bleu sur un pc sous windows à moi depuis des années (l'arrivée d'XP). J'ai fortement l'impression que ça dépend de l'interface chaise-clavier et/ou de l'achat de périphériques buggés. Bref faut le chercher un minimum. A l'époque des win9x, la c'était plus drôle.
Bon maintenant je l'utilise bien peu donc c'est moins représentatif, mais je ne crois pas avoir vu mon vista planté une seule fois (ni même freezer)..
[^] # Re: Ca arrive
Posté par Putifuto . Évalué à 10.
Je pensais comme ça jusqu'à la semaine dernière où lorsque je voulais imprimer un certain un document Word, j'avais un BSOD. et sur 3 PC différents. A priori un graphique visio qui était mal digéré par la chaîne d'impression.
Mais c'est quand même inacceptable qu'une impression foute le kernel en l'air.
J'ai contourné le problème en virant le schéma.
[^] # Re: Ca arrive
Posté par Earered . Évalué à 2.
Parce qu'il est configuré par défaut pour rebooter quasi immédiatement, ces messages d'erreurs étant incompréhensible pour l'utilisateur.
Bonne chose a mon avis, mais le support téléphonique familiale est un poil plus dur en cas de reboot intempestif (virus, chaleur, pilote de merde?)
[^] # Re: Ca arrive
Posté par Psychofox (Mastodon) . Évalué à 1.
[^] # Re: Ca arrive
Posté par ß ß . Évalué à 10.
Tous les systèmes plantent, la c'est juste arrivé au mauvais momentC'est ce qu'on critique. Pas que ça plante, mais que ça plante au mauvais moment.
Que ça fasse un kernel panic au reboot, ce n'est pas grave. Ça arrive généralement quand tu as changé ta conf (tu sais donc ce que tu as fait), ou quand tu as utilisé des drivers moisis^W propriétaires^W privateurs (whatever, c'est synonyme tout ça).
Mais surtout ça arrive quand tu reboote. C'est quelque chose que je n'ai jamais compris perso cette comparaison entre les kernel panics et les BSOD. Le BSOD il peut arriver au moment d'un reboot certes, ou à l'ouverture d'une session, mais enfin ce n'est pas le plus courant, ni le plus gênant.
Le plus gênant, c'est quand ça arrive en plein milieu d'une phase de prod sur un distributeur de billets, en plein milieu d'une cérémonie d'ouverture des JO, en plein milieu d'une présentation de MS du nouveau Windows top stable et sicioure, dans les bornes SNCF, etc.
À ma connaissance il n'y a pas souvent (du tout?) de kernel panics en plein milieu d'une utilisation. À la limite des oops en cas de matériels défectueux. Mais c'est tout.
[^] # Re: Ca arrive
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Ca arrive
Posté par feth . Évalué à 4.
[^] # Re: Ca arrive
Posté par timid . Évalué à 1.
Ca m'arrive assez souvent que ca freeze complètement (même pas d'accès possible par SSH) avec les drivers ATI libres, quand je lance des programmes qui utilisent la 3d
Ca me le fait aussi sur un PC avec une i810 quand je redémarre le serveur X
Le problème de stabilité de windows c'est pas les BSOD qui arrivent très rarement, c'est que tout l'applicatif est troué de bugs (qui n'entrainent pas tout le temps de plantages)
# Et Windows aime la Chine
Posté par feth . Évalué à 6.
La plupart des Chinois ne parlent pas et lisent encore moins l'anglais ; ça fait très longtemps (depuis presque le début ?) que Windows est piratable dans cette langue, et que les Chinois piratent massivement tous les logciels qui leur passent sous la main pour l'avantage compétitif immédiat que ça procure, sans craindre aucune répression.
# Cocorico
Posté par dyno partouzeur de drouate . Évalué à 10.
Cet écran bleu est donc à mettre à l'actif de la France avec nos nombreuses médailles d'or.
A croire que c'est Manaudou le sysadmin...
[^] # Re: Cocorico
Posté par Obsidian . Évalué à 10.
On a dit « ça plante », pas « ça rame » ! :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.