> Tu n'as plus les vis que tu avais acheté.
mouai, à mon avis va falloir user de beaucoup d'arguments pour convaincre quelqu'un que c'est du vol...
> La caractéristique c'est aussi la tête de la vis qui te permet de la dévisser.
Sauf que la tête de vis te permet toujours de la dévisser. Tu n'a peut-être pas le tournevis, mais tu n'avais peut-être pas non plus un cruci de la taille de la vis précédente...
en fait j'ai du mal à voir :
- la partie aggravé ?
- le vol ?
- les caractéristiques modifiées ? (la caractéristique c'est que la coque soit tenue par une vis, pas la tronche de la vis, encore moins si le pas est identique...)
> Il doit bien y avoir un moyen de les faire chier sur le sujet
oui, arrêter d'en acheter ?
justement, si dans deux semaines on trouve les outils adéquats, alors ça ne justifie pas le coup de passer à une nouvelle empreinte.
En fait je suis de plus en plus persuadé que c'est pour éviter le bourrage plus qu'autre chose (car leurs petites cruciforme d'avant, y'a moyen vite fait de les abimer si on emploi pas le bon tournevis) surtout que contrairement à ce que beaucoup écrives ça ne semble pas être une nouvelle vis qu'ils auraient inventés,.
encore un cas où tu aurais du réfléchir avant de l'ouvrir sur un sujet que tu ne connais pas du tout...
> 2. La chaleur qu'ils produisent est entièrement perdue.
Ha bon ? Tiens c'est étrange, les locaux où je bosse sont en partie chauffés par récupération de la chaleur évacuée par le datacenter intégré au bâtiment...
oué enfin en même temps utiliser des torx par exemple (là leur nouveau model je sais pas) c'est pas une histoire de pognon ou d'empêcher les gens de démonter pour plusieurs raisons :
* les torx c'est loin d'être rare
* les torx sont une bonne avancée en matière de vis, essentiellement lorsque tu veux faire du montage par des robots, moins de glissement, etc.
Maintenant c'est vrai que leurs vis pentalobe ... des torx security auraient surement suffit, mais un coup de perceuse et on les transforme en torx donc bon...
Et leurs pentalobe ressemblent surtout à des torx plus anti bourrage (à 5 lobes ... tiens, pentalobe).
Donc en fait ils sont toujours sous des vis torx mais avec deux modifications :
* ils utilisent la version plus, version plus résistante aux torsions en minimisant l'usure
* ils utilisent la version 5 lobes qui est anti bourrage, c'est à dire empêchant l'ouverture par un outil non approprié mais dont l'usage pourrait être détourné (par ex dévisser des pozidrive avec un plat). On peut le regretter mais l'autre avantage est de réduire par la même les risques de "foirage" de la tête en attaquant avec un mauvais outil.
(mais bon, je reste plutôt sur l'idée qu'une torx classique, une security au pire, devrait suffire normalement)
ben dit donc, je dois soit vraiment mal m'exprimer, soit c'est toujours interprété comme souhaité et non comme écrit...
le "on y arrive" fait référence à n'importe qu'elle raison qui pourrait être donné, et non uniquement "la paresse". D'ailleurs il y avait un zoli disclaimer qui précisais bien que je ne prenais pas ça comme une réponse pour firefox bla bla bla
Donc oui, le temps peut être une raison, la paresse aussi, être mauvais aussi, etc. Il peut y avoir plein de raison, mais j'aurais bien voulu connaître la vrai ...
ok, oui en effet je n'avais pas bien saisi ton analogie.
> La bonne raison dans ces cas-là c'est quasiment toujours la paresse
ha ben voilà, on y arrive ! (en fait je pensais qu'on y serait arrivé beaucoup plus tôt)
Pour reprendre ce que disais tankey, mes affirmations (maladroites) visaient surtout à ce qu'on réponde quelque chose du genre (ou tout autre justification qu'elle qu'elle soit)...
/disclaimer : je sais bien que l'affirmation d'Antoine n'est pas relative à firefox, pas la peine de croire que je prend ça comme une réponse sur le problème de firefox /disclaimer
Et oui, si on ne fait pas ses propres vérifs par paresse, on ne peut absolument pas exiger que d'autres fassent les leurs !
Comme déjà indiqué, non ce n'est pas une attaque. Comme l'a dit tankey un poil plus haut je pense qu'on entre essentiellement dans un problème de formulation (qui est surement de mon fait)
Mais oui, la logique voudrait que lorsqu'on demande à une partie externe d'être irréprochable, c'est pas pour de l'autre côté ne pas faire toutes les vérifs qui s'imposent. Ca reste à mon sens assez logique.
Mais bon, là on arrive quand même dans du bel enculage de drosophile avec multi répétition / justification des mêmes contenu...
> Je suis sûr que si tu rapportes un plantage ...
Aucun rapport.
Ha ok, je commence à comprendre ... en fait vous (je reste bien général) l'avez tous pris comme une attaque contre le (les ?) dev de firefox ... ce que ce n'était pas. Lorsque je parle de logique, je parle de logique de dev, absolument pas de la faute de quelqu'un en particulier.
/franchement ça me gave que tout soit toujours pris de manière perso, surtout qu'on aurait pu parler des problèmes, de pourquoi mozilla ne faisait pas les tests (il y a surement une bonne raison, même si c'est jusque que les drivers utilisés n'en avaient pas besoin), pourquoi c'était pas blindé côté driver, pourquoi on s'en aperçoit si tard, etc
/me doit se trouver des disclaimer pour les prochains posts techniques...
merci d'appuyer sur le aussi alors que j'en parle déjà (qui a dit dialogue de sourd ?) :
* tords partagés même si certains ont plus de responsabilité que d'autre quant à l'issue du problème (en l’occurrence les drivers)
* le driver devrait le gérer
> de la part de CrEv
hum, j'adore lorsqu'on rentre sur le domaine perso, c'est tellement mieux
Pour reprendre le début de ton journal "Je m'essaye à l'exercice du journal LinuxFr" il reste encore la partie style / susceptibilité à appréhender alors
Dans tous les cas je pense que tu as très mal pris mon message alors qu'il était en aucun cas méchant et encore moins personnel.
Mais bon, on peut toujours faire une petite explication de texte.
Tout d'abord :
"Sans vouloir du tout rentrer dans le style des autres réponses" -> ben oui, je trouvais que d'autres réponses partaient en vrille alors je voulais faire soft pour le coup...
"Je comprend bien que les drivers sont beaucoup plus critiques que firefox" -> donc vous pouvez tous répondre que userland, drivers, toussa ... mais je l'ai déjà écris...
"mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même." -> ben oui, désolé mais lorsqu'on lit [https://linuxfr.org/comments/1201200.html#1201200] :
"ça serait dû à Firefox, qui utilise une extension sans vérifier qu'elle est disponible (GL_ARB_ES2_compatibility) et qui accède aux "uniforms" avec des indices invalides." il y a bien faute côté mozilla. Evidemment les drivers ne devraient pas planter et faire des vérifs, mais ce genre de vérif (vérifier que la fonctionnalité est dispo) reste à faire du côté mozilla. Si le drivers devrait être capable de le gérer, mozilla ne devrait lui pas le faire non plus. Le bon côté est que cela permet par contre de corriger des bugs potentiels liés à une mauvaise utilisation.
D'ailleurs je ne faisais que reprendre tes propos : "on pourrait et devrait valider mieux les parametres avant de faire nos appels"
"il reste que toute bibliotheque qu'une application appelle a un 'contrat' avec l'application qui definit bien clairement a qui la faute"
et on rajoutera dans les règles [https://linuxfr.org/comments/1201485.html#1201485] Le conseil d'un prof de DUT à propos des styles de vérification du code :
* dans ton propre code : tu peux te permettre de donner les préconditions et supposer que tu les respecteras lors de l'appel
* si tu distribues ton codes : tu blindes les APIS et vérifies systématiquement que les préconditions sont respectées après les appels de fonctions.
* de toute bibliothèque externe tu te méfiera, tu ne sais pas si le boulot est bien fait (en gros) et tes appels tu blindera (surtout si tu passes kernel-land et que ça risque d’entraîner ton soft avec)
Et en plus, histoire que mon message initial ne soit pas mal interprété, je finissais par :
Maintenant, ce qui est plutôt une très bonne nouvelle (au delas de tout le blabla inhérent dont il faut finalement assez peu ce soucier ;) ) :
> tout ca devrait bientot etre du passe
Mais pour finir cette fois :
> Bref, encore un commentaire aggressif pour rien de la part de CrEv, merci bien (j'ai ma dose).
(ok, je devrais pas écrire la suite je vais encore probablement me faire moinser...)
Il était évident qu'en venant raconter ton histoire elle allait se faire décortiquer de tous les côtés. Et je pense que c'est bien (je ne voudrais justement pas te dissuader de recommencer car on a appris pas mal de choses). Nombre de commentaires (avec des styles peut-être plus ou moins direct - oui je parle juste de direct plutôt que d’agressif car en aucun cas ce n'était des attaques de ma part) ont permit de préciser exactement la nature des problèmes, en mettant en évidence des tords partagés même si certains ont plus de responsabilité que d'autre quant à l'issue du problème (en l’occurrence les drivers).
Sans vouloir du tout rentrer dans le style des autres réponses, je suis toujours surpris de ce genre de déclaration :
> on pourrait et devrait valider mieux les parametres avant de faire nos appels, ce qui peut eviter certains plantages, ca oui, mais il reste que les drivers ne sont jamais censes planter
En gros on ne vérifie pas suffisamment notre code, et donc ça fait planter. Nous on le fait mais eux ils ne devraient pas, parce que c'est des drivers, toussa.
Je comprend bien que les drivers sont beaucoup plus critiques que firefox, mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même.
Maintenant, ce qui est plutôt une très bonne nouvelle (au delas de tout le blabla inhérent dont il faut finalement assez peu ce soucier ;) ) :
> tout ca devrait bientot etre du passe
ha mais je suis bien d'accord
Mais à lire le journal on a un "ça marche pas c'est la faute aux pilotes" et à côté de ça un "mais ça marche chez chrome"
Donc la question de savoir comment chrome fait, pourquoi firefox ne fait pas pareil est à mon avis plutôt pertinante. Et après avoir les réponses, d'autres questions arrivent : ok mais chrome va-t-il changer ensuite, ce que chrome utilise ne va-t-il justement pas resté maintenu pour cette raison ?
Je ne dis pas que firefox doit faire comme chrome, mais reporter la faute uniquement sur les drivers alors que d'autre s'en sortent est de premier abord, sans explication complémentaire, plutôt intriguant.
Maintenant, si ça permet de corriger les drivers et que tout marche, ben c'est bien cool et j'en serai bien content.
en même temps, vu que webgl fonctionne beaucoup mieux sous windows que sous linux (puisque juste avec nvidia proprio) on devrait proportionnellement en avoir pas mal sous linux, non ?
> je ne pense pas rouler qui que ce soit dans la farine
Désolé, la fin était peut-être un peu excessive.
Mais si on relis on a :
- on a désactivé webgl (nvidia proprio exclu) pour tous les drivers open source car ils ne sont pas bon
- oué mais sous chrome ça marche
- je ne voulais pas insister dessus
Donc voilà...
> nous avons des outils tres puissants pour etudier les plantages des utilisateurs
Oui, mais ce qui n'est jamais vraiment comparable à un vrai debug / expérimentation, surtout en terme de réactivité (à moins que vos outils soient vraiment vraiment vraiment bien)
ok, compris pour la comparaison avec chrome. Mais ça veut dire que eux vont changer de techno rapidement (si le support change) ? Ou que finalement ça va rester supporté suffisamment longtemps ?
> J'ai une carte nvidia
Que je comprenne bien. Ca veut dire que vous (mozilla ?) êtes en train d'intégrer une fonctionnalité basée sur la 3d sans avoir une batterie de pc avec différentes cartes pour voir ce que ça donne ?
> La grosse difference que je vois a ce niveau avec Chrome, c'est plutot qu'ils semblent utiliser des PBuffers alors que nous creons un contexte OpenGL invisible (je crois appuye par un pixmap) et faisons tout le rendu dans un FBO.
Et dans le cas où ça fonctionne sous chrome, pourquoi ne pas reprendre le même principe ?
> Je ne voulais pas insister sur cet aspect la
Ben c'est dommage car ça donne un peu l'impression de se faire rouler dans la farine par le message initial.
> Je m'essaye a l'exercice du journal linuxfr
Comme quoi, spa si évident que ça, y'a toujours quelqu'un pour venir pinailler, ajouter son grain de sel, etc. Et tu t'en sort pas mal je trouver, certains se font soit shooter sur l'orthographe, soit sur des histoires d'avortement...
Ca faisait longtemps que je ne l'avais pas sorti ;-)
Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre avis. Si vous désirez poser une question, merci d'utiliser les forums.
ha ok, d'où le "jusque très récemment" ;-)
J'ai passé un code il y a 2 ans, pas de notion, le précédent datait d'il y a (de tête) une douzaine d'année, pas de notion de vert clignotant non plus.
Donc peut-être que ça a existé mais ça fait longtemps que c'est plus le cas par contre.
arg, mais quel intérêt de faire tourner ça avec jruby ??
> Un mec qui vend un bouquin en prenant Redmine comme cible, j'avoue que j'ai tendance à me méfier.
Oué, enfin avant de se méfier de tout le monde pour rien sans savoir, il est intéressant de se renseigner. Il suffit par exemple de lire les annonces sur le site de redmine [http://www.redmine.org/projects/redmine/news]
Il a sorti les versions 1.0.3, 1.0.2, 1.0.1, 1.0.0, 0.9.6, 0.9.5, 0.9.3 ainsi que blog et plugins à propos de redmine.
Donc même s'il a des avis / envies à propos de redmine, il est pas étranger au développement de redmine.
Et son bouquin ne prend pas du tout redmine pour cible, il prend comme exemple de refactoring des modifications / améliorations / refactoring qu'il a fait sur le code de redmine.
Ce n'est donc pas du tout "c'est pourri achetez mon bouquin" ...
oui je suis sur (enfin j'espère bien, sinon c'est que j'ai vraiment loupé un truc)
Après, moi aussi j'ai un "version source" mais ça n'a rien de standard ;-)
C'est sur un redmine que tu utilises ou que tu administres ?
> Un mec important (je pense qu'il etait le #2 en terme de contribution) vient de quitter... justement pour des raisons de proprete de code, de refactoring, etc...
Tu as un pointeur sur ce point ? Ca m'intéresserait
heu, non (ou alors j'ai pas compris la relation version - code source)
C'est la version sur laquelle on base un bug, une demande.
Par exemple tel bug a été découvert en version x.y (version source, champ perso dans redmine), il sera corrigé dans la version x.z (version cible, gérée correctement dans redmine)
Actuellement dans redmine, on gère des versions cibles.
Mais ces versions ne peuvent pas être utilisées en tant que version source (histoire d'indiquer dans quel version le problème existe).
Il est alors obligatoire de passer par un champ perso, mais ceux-ci ne sont pas top pour ça et surtout obligent à maintenir deux listes comportant des valeurs communes. Une demande existe depuis longtemps concernant ce point, mais c'est pas encore réalisé.
qu'est ce qui avait planté ?
Redmine ?
Mongrel ?
Passenger ?
Ruby ?
... ?
m'enfin là je dirais simplement : chezmoiçamarche (et je dois pas être le seul). C'est pas un énorme mais c'est correct quand même : 75 projets, 4400 issues, 54000 révisions (svn pour le moment).
Ben... ça tourne sans aucun problème, sans problème de charge, sans saturation mémoire. Depuis 3 ans je crois que j'ai du redémarré une fois le service httpd mais c'est tout...
Ensuite, m'étonnerais pas que certains aient eu la même chose ... avec trac.
Trac n'est pas mauvais ... il n'a juste pas de fonctionnalités.
Et quand je vois qu'il fait ni mercurial ni git ... ben il est largué c'est tout. Et que les devs fassent autre chose, tant mieux pour eux, mais si on regarde y'a pas non plus bcp de monde derrière redmine...
intéressant... pour ma part, lorsque je veux faire des choses un peu trop complexes, je tape directement dans la base de donnée et ça marche assez bien (genre typiquement réassigner beaucoup de demandes). Maintenant c'est pas forcément très propre...
Mais je ne pense pas du tout que redmine soit une effet de mode vis à vis de rails, surtout qu'au contraire certains ne veulent pas l'installer car c'est en rails (par rapport à du php par exemple).
Avant redmine j'utilisais aussi trac, mais lorsqu'on voyait la galère pour installer un trac potable, qu'il fallait y coller plein de plugins pour avoir un truc qui marche en multi projet, multi dépôt etc alors qu'il suffit d'installer redmine pour que ça fonctionne...
D'ailleurs, ton message me fait penser (sans aller chercher plus loin l'état réel) que trac n'a toujours pas en standard de multi projet / dépôt ? Si c'est le cas c'est vraiment un réel point bloquant pour trac, et doucement ok, mais çà fait longtemps que redmine (ou autre) le font. Actuellement je suis sur une instance de redmine où j'ai 75 projets différents et organisés de manière hiérarchique, dont certains se partagent les versions cibles et versions sources. Comment je fais ça facilement sous trac ?
[^] # Re: Juridiquement...
Posté par CrEv (site web personnel) . En réponse au journal Apple: "Don't do it yourself". Évalué à 2.
mouai, à mon avis va falloir user de beaucoup d'arguments pour convaincre quelqu'un que c'est du vol...
> La caractéristique c'est aussi la tête de la vis qui te permet de la dévisser.
Sauf que la tête de vis te permet toujours de la dévisser. Tu n'a peut-être pas le tournevis, mais tu n'avais peut-être pas non plus un cruci de la taille de la vis précédente...
[^] # Re: Juridiquement...
Posté par CrEv (site web personnel) . En réponse au journal Apple: "Don't do it yourself". Évalué à 4.
- la partie aggravé ?
- le vol ?
- les caractéristiques modifiées ? (la caractéristique c'est que la coque soit tenue par une vis, pas la tronche de la vis, encore moins si le pas est identique...)
> Il doit bien y avoir un moyen de les faire chier sur le sujet
oui, arrêter d'en acheter ?
[^] # Re: Retour aux sources...
Posté par CrEv (site web personnel) . En réponse au journal Apple: "Don't do it yourself". Évalué à 2.
En fait je suis de plus en plus persuadé que c'est pour éviter le bourrage plus qu'autre chose (car leurs petites cruciforme d'avant, y'a moyen vite fait de les abimer si on emploi pas le bon tournevis) surtout que contrairement à ce que beaucoup écrives ça ne semble pas être une nouvelle vis qu'ils auraient inventés,.
[^] # Re: Bonne initiative mais...
Posté par CrEv (site web personnel) . En réponse à la dépêche Des nouvelles sur l'auto-hébergement. Évalué à 4.
> 2. La chaleur qu'ils produisent est entièrement perdue.
Ha bon ? Tiens c'est étrange, les locaux où je bosse sont en partie chauffés par récupération de la chaleur évacuée par le datacenter intégré au bâtiment...
[^] # Re: Retour aux sources...
Posté par CrEv (site web personnel) . En réponse au journal Apple: "Don't do it yourself". Évalué à 2.
[^] # Re: Retour aux sources...
Posté par CrEv (site web personnel) . En réponse au journal Apple: "Don't do it yourself". Évalué à 5.
* les torx c'est loin d'être rare
* les torx sont une bonne avancée en matière de vis, essentiellement lorsque tu veux faire du montage par des robots, moins de glissement, etc.
Maintenant c'est vrai que leurs vis pentalobe ... des torx security auraient surement suffit, mais un coup de perceuse et on les transforme en torx donc bon...
Et leurs pentalobe ressemblent surtout à des torx plus anti bourrage (à 5 lobes ... tiens, pentalobe).
Donc en fait ils sont toujours sous des vis torx mais avec deux modifications :
* ils utilisent la version plus, version plus résistante aux torsions en minimisant l'usure
* ils utilisent la version 5 lobes qui est anti bourrage, c'est à dire empêchant l'ouverture par un outil non approprié mais dont l'usage pourrait être détourné (par ex dévisser des pozidrive avec un plat). On peut le regretter mais l'autre avantage est de réduire par la même les risques de "foirage" de la tête en attaquant avec un mauvais outil.
(mais bon, je reste plutôt sur l'idée qu'une torx classique, une security au pire, devrait suffire normalement)
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. Évalué à 2.
le "on y arrive" fait référence à n'importe qu'elle raison qui pourrait être donné, et non uniquement "la paresse". D'ailleurs il y avait un zoli disclaimer qui précisais bien que je ne prenais pas ça comme une réponse pour firefox bla bla bla
Donc oui, le temps peut être une raison, la paresse aussi, être mauvais aussi, etc. Il peut y avoir plein de raison, mais j'aurais bien voulu connaître la vrai ...
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. Évalué à 1.
> La bonne raison dans ces cas-là c'est quasiment toujours la paresse
ha ben voilà, on y arrive ! (en fait je pensais qu'on y serait arrivé beaucoup plus tôt)
Pour reprendre ce que disais tankey, mes affirmations (maladroites) visaient surtout à ce qu'on réponde quelque chose du genre (ou tout autre justification qu'elle qu'elle soit)...
/disclaimer : je sais bien que l'affirmation d'Antoine n'est pas relative à firefox, pas la peine de croire que je prend ça comme une réponse sur le problème de firefox /disclaimer
Et oui, si on ne fait pas ses propres vérifs par paresse, on ne peut absolument pas exiger que d'autres fassent les leurs !
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. Évalué à 2.
Mais oui, la logique voudrait que lorsqu'on demande à une partie externe d'être irréprochable, c'est pas pour de l'autre côté ne pas faire toutes les vérifs qui s'imposent. Ca reste à mon sens assez logique.
Mais bon, là on arrive quand même dans du bel enculage de drosophile avec multi répétition / justification des mêmes contenu...
> Je suis sûr que si tu rapportes un plantage ...
Aucun rapport.
Ha ok, je commence à comprendre ... en fait vous (je reste bien général) l'avez tous pris comme une attaque contre le (les ?) dev de firefox ... ce que ce n'était pas. Lorsque je parle de logique, je parle de logique de dev, absolument pas de la faute de quelqu'un en particulier.
/franchement ça me gave que tout soit toujours pris de manière perso, surtout qu'on aurait pu parler des problèmes, de pourquoi mozilla ne faisait pas les tests (il y a surement une bonne raison, même si c'est jusque que les drivers utilisés n'en avaient pas besoin), pourquoi c'était pas blindé côté driver, pourquoi on s'en aperçoit si tard, etc
/me doit se trouver des disclaimer pour les prochains posts techniques...
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. Évalué à 2.
* tords partagés même si certains ont plus de responsabilité que d'autre quant à l'issue du problème (en l’occurrence les drivers)
* le driver devrait le gérer
mais par contre merci d'avoir replacé ce lien
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. Évalué à 1.
hum, j'adore lorsqu'on rentre sur le domaine perso, c'est tellement mieux
Pour reprendre le début de ton journal "Je m'essaye à l'exercice du journal LinuxFr" il reste encore la partie style / susceptibilité à appréhender alors
Dans tous les cas je pense que tu as très mal pris mon message alors qu'il était en aucun cas méchant et encore moins personnel.
Mais bon, on peut toujours faire une petite explication de texte.
Tout d'abord :
"Sans vouloir du tout rentrer dans le style des autres réponses" -> ben oui, je trouvais que d'autres réponses partaient en vrille alors je voulais faire soft pour le coup...
"Je comprend bien que les drivers sont beaucoup plus critiques que firefox" -> donc vous pouvez tous répondre que userland, drivers, toussa ... mais je l'ai déjà écris...
"mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même." -> ben oui, désolé mais lorsqu'on lit [https://linuxfr.org/comments/1201200.html#1201200] :
"ça serait dû à Firefox, qui utilise une extension sans vérifier qu'elle est disponible (GL_ARB_ES2_compatibility) et qui accède aux "uniforms" avec des indices invalides." il y a bien faute côté mozilla. Evidemment les drivers ne devraient pas planter et faire des vérifs, mais ce genre de vérif (vérifier que la fonctionnalité est dispo) reste à faire du côté mozilla. Si le drivers devrait être capable de le gérer, mozilla ne devrait lui pas le faire non plus. Le bon côté est que cela permet par contre de corriger des bugs potentiels liés à une mauvaise utilisation.
D'ailleurs je ne faisais que reprendre tes propos : "on pourrait et devrait valider mieux les parametres avant de faire nos appels"
"il reste que toute bibliotheque qu'une application appelle a un 'contrat' avec l'application qui definit bien clairement a qui la faute"
et on rajoutera dans les règles [https://linuxfr.org/comments/1201485.html#1201485]
Et en plus, histoire que mon message initial ne soit pas mal interprété, je finissais par :
Maintenant, ce qui est plutôt une très bonne nouvelle (au delas de tout le blabla inhérent dont il faut finalement assez peu ce soucier ;) ) :
> tout ca devrait bientot etre du passe
Mais pour finir cette fois :
> Bref, encore un commentaire aggressif pour rien de la part de CrEv, merci bien (j'ai ma dose).
(ok, je devrais pas écrire la suite je vais encore probablement me faire moinser...)
Il était évident qu'en venant raconter ton histoire elle allait se faire décortiquer de tous les côtés. Et je pense que c'est bien (je ne voudrais justement pas te dissuader de recommencer car on a appris pas mal de choses). Nombre de commentaires (avec des styles peut-être plus ou moins direct - oui je parle juste de direct plutôt que d’agressif car en aucun cas ce n'était des attaques de ma part) ont permit de préciser exactement la nature des problèmes, en mettant en évidence des tords partagés même si certains ont plus de responsabilité que d'autre quant à l'issue du problème (en l’occurrence les drivers).
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. Évalué à -5.
> on pourrait et devrait valider mieux les parametres avant de faire nos appels, ce qui peut eviter certains plantages, ca oui, mais il reste que les drivers ne sont jamais censes planter
En gros on ne vérifie pas suffisamment notre code, et donc ça fait planter. Nous on le fait mais eux ils ne devraient pas, parce que c'est des drivers, toussa.
Je comprend bien que les drivers sont beaucoup plus critiques que firefox, mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même.
Maintenant, ce qui est plutôt une très bonne nouvelle (au delas de tout le blabla inhérent dont il faut finalement assez peu ce soucier ;) ) :
> tout ca devrait bientot etre du passe
[^] # Re: Dis donc ! c'est pas encore vendredi :)
Posté par CrEv (site web personnel) . En réponse au journal Firefox 4 et pilotes de cartes graphiques sous linux. Évalué à 3.
Mais à lire le journal on a un "ça marche pas c'est la faute aux pilotes" et à côté de ça un "mais ça marche chez chrome"
Donc la question de savoir comment chrome fait, pourquoi firefox ne fait pas pareil est à mon avis plutôt pertinante. Et après avoir les réponses, d'autres questions arrivent : ok mais chrome va-t-il changer ensuite, ce que chrome utilise ne va-t-il justement pas resté maintenu pour cette raison ?
Je ne dis pas que firefox doit faire comme chrome, mais reporter la faute uniquement sur les drivers alors que d'autre s'en sortent est de premier abord, sans explication complémentaire, plutôt intriguant.
Maintenant, si ça permet de corriger les drivers et que tout marche, ben c'est bien cool et j'en serai bien content.
[^] # Re: Dis donc ! c'est pas encore vendredi :)
Posté par CrEv (site web personnel) . En réponse au journal Firefox 4 et pilotes de cartes graphiques sous linux. Évalué à 3.
[^] # Re: Dis donc ! c'est pas encore vendredi :)
Posté par CrEv (site web personnel) . En réponse au journal Firefox 4 et pilotes de cartes graphiques sous linux. Évalué à 0.
Désolé, la fin était peut-être un peu excessive.
Mais si on relis on a :
- on a désactivé webgl (nvidia proprio exclu) pour tous les drivers open source car ils ne sont pas bon
- oué mais sous chrome ça marche
- je ne voulais pas insister dessus
Donc voilà...
> nous avons des outils tres puissants pour etudier les plantages des utilisateurs
Oui, mais ce qui n'est jamais vraiment comparable à un vrai debug / expérimentation, surtout en terme de réactivité (à moins que vos outils soient vraiment vraiment vraiment bien)
ok, compris pour la comparaison avec chrome. Mais ça veut dire que eux vont changer de techno rapidement (si le support change) ? Ou que finalement ça va rester supporté suffisamment longtemps ?
[^] # Re: Dis donc ! c'est pas encore vendredi :)
Posté par CrEv (site web personnel) . En réponse au journal Firefox 4 et pilotes de cartes graphiques sous linux. Évalué à 1.
Que je comprenne bien. Ca veut dire que vous (mozilla ?) êtes en train d'intégrer une fonctionnalité basée sur la 3d sans avoir une batterie de pc avec différentes cartes pour voir ce que ça donne ?
> La grosse difference que je vois a ce niveau avec Chrome, c'est plutot qu'ils semblent utiliser des PBuffers alors que nous creons un contexte OpenGL invisible (je crois appuye par un pixmap) et faisons tout le rendu dans un FBO.
Et dans le cas où ça fonctionne sous chrome, pourquoi ne pas reprendre le même principe ?
> Je ne voulais pas insister sur cet aspect la
Ben c'est dommage car ça donne un peu l'impression de se faire rouler dans la farine par le message initial.
> Je m'essaye a l'exercice du journal linuxfr
Comme quoi, spa si évident que ça, y'a toujours quelqu'un pour venir pinailler, ajouter son grain de sel, etc. Et tu t'en sort pas mal je trouver, certains se font soit shooter sur l'orthographe, soit sur des histoires d'avortement...
[^] # Re: Pas la peine d'en faire un journal.
Posté par CrEv (site web personnel) . En réponse au journal Comparaison Firefox et Chromium avec un benchmark du web. Évalué à 3.
Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre avis. Si vous désirez poser une question, merci d'utiliser les forums.
[^] # Re: Pas vu
Posté par CrEv (site web personnel) . En réponse au journal Dépouillement de Firefox. Évalué à 2.
J'ai passé un code il y a 2 ans, pas de notion, le précédent datait d'il y a (de tête) une douzaine d'année, pas de notion de vert clignotant non plus.
Donc peut-être que ça a existé mais ça fait longtemps que c'est plus le cas par contre.
[^] # Re: Redmine rocks
Posté par CrEv (site web personnel) . En réponse à la dépêche Gérez vos projets avec Redmine. Évalué à 3.
> Un mec qui vend un bouquin en prenant Redmine comme cible, j'avoue que j'ai tendance à me méfier.
Oué, enfin avant de se méfier de tout le monde pour rien sans savoir, il est intéressant de se renseigner. Il suffit par exemple de lire les annonces sur le site de redmine [http://www.redmine.org/projects/redmine/news]
Il a sorti les versions 1.0.3, 1.0.2, 1.0.1, 1.0.0, 0.9.6, 0.9.5, 0.9.3 ainsi que blog et plugins à propos de redmine.
Donc même s'il a des avis / envies à propos de redmine, il est pas étranger au développement de redmine.
Et son bouquin ne prend pas du tout redmine pour cible, il prend comme exemple de refactoring des modifications / améliorations / refactoring qu'il a fait sur le code de redmine.
Ce n'est donc pas du tout "c'est pourri achetez mon bouquin" ...
[^] # Re: scrum
Posté par CrEv (site web personnel) . En réponse à la dépêche Gérez vos projets avec Redmine. Évalué à 2.
Après, moi aussi j'ai un "version source" mais ça n'a rien de standard ;-)
C'est sur un redmine que tu utilises ou que tu administres ?
[^] # Re: Redmine rocks
Posté par CrEv (site web personnel) . En réponse à la dépêche Gérez vos projets avec Redmine. Évalué à 2.
Tu as un pointeur sur ce point ? Ca m'intéresserait
[^] # Re: scrum
Posté par CrEv (site web personnel) . En réponse à la dépêche Gérez vos projets avec Redmine. Évalué à 3.
C'est la version sur laquelle on base un bug, une demande.
Par exemple tel bug a été découvert en version x.y (version source, champ perso dans redmine), il sera corrigé dans la version x.z (version cible, gérée correctement dans redmine)
[^] # Re: scrum
Posté par CrEv (site web personnel) . En réponse à la dépêche Gérez vos projets avec Redmine. Évalué à 2.
Mais ces versions ne peuvent pas être utilisées en tant que version source (histoire d'indiquer dans quel version le problème existe).
Il est alors obligatoire de passer par un champ perso, mais ceux-ci ne sont pas top pour ça et surtout obligent à maintenir deux listes comportant des valeurs communes. Une demande existe depuis longtemps concernant ce point, mais c'est pas encore réalisé.
[^] # Re: Comptes utilisateurs
Posté par CrEv (site web personnel) . En réponse à la dépêche Gérez vos projets avec Redmine. Évalué à 4.
Redmine ?
Mongrel ?
Passenger ?
Ruby ?
... ?
m'enfin là je dirais simplement : chezmoiçamarche (et je dois pas être le seul). C'est pas un énorme mais c'est correct quand même : 75 projets, 4400 issues, 54000 révisions (svn pour le moment).
Ben... ça tourne sans aucun problème, sans problème de charge, sans saturation mémoire. Depuis 3 ans je crois que j'ai du redémarré une fois le service httpd mais c'est tout...
Ensuite, m'étonnerais pas que certains aient eu la même chose ... avec trac.
Trac n'est pas mauvais ... il n'a juste pas de fonctionnalités.
Et quand je vois qu'il fait ni mercurial ni git ... ben il est largué c'est tout. Et que les devs fassent autre chose, tant mieux pour eux, mais si on regarde y'a pas non plus bcp de monde derrière redmine...
[^] # Re: Comptes utilisateurs
Posté par CrEv (site web personnel) . En réponse à la dépêche Gérez vos projets avec Redmine. Évalué à 5.
Mais je ne pense pas du tout que redmine soit une effet de mode vis à vis de rails, surtout qu'au contraire certains ne veulent pas l'installer car c'est en rails (par rapport à du php par exemple).
Avant redmine j'utilisais aussi trac, mais lorsqu'on voyait la galère pour installer un trac potable, qu'il fallait y coller plein de plugins pour avoir un truc qui marche en multi projet, multi dépôt etc alors qu'il suffit d'installer redmine pour que ça fonctionne...
D'ailleurs, ton message me fait penser (sans aller chercher plus loin l'état réel) que trac n'a toujours pas en standard de multi projet / dépôt ? Si c'est le cas c'est vraiment un réel point bloquant pour trac, et doucement ok, mais çà fait longtemps que redmine (ou autre) le font. Actuellement je suis sur une instance de redmine où j'ai 75 projets différents et organisés de manière hiérarchique, dont certains se partagent les versions cibles et versions sources. Comment je fais ça facilement sous trac ?