Vu l'état actuel de l'open hardware, on peut difficilement qualifier la carte principale de traitement de l'information d'un système de simple composant.
Sinon je prend le manuel de service de mon laptop et je prétend que c'est de l'open hardware : c'est juste ridicule.
Cette phrase est là pour qu'on puisse jouer au business loto ?
Plus sérieusement je suis 100 % d'accord avec le problème identifié ici, le raspberry pi est un bidule intéressant mais surtout pour brancher sur un écran HD, et totalement inadapté ici, et qui n'a rien d'open hardware, et n'a pas son logiciel de base libre si je ne m'abuse.
Il en existe depuis 20 ans des board principales ultra light à base de uC, bien plus adaptées pour ce projet, et en open hardware ça doit pouvoir se trouver en préexistant, sinon il y a des gens qui seront ravis d'en faire.
Ce qui aurait permis à "Olivier Blondeau, docteur à Sciences Po" de dire << Le tout en “full open hardware” >> sans se full-décrédibiliser instantanément.
Ce que tu décris c'est de l'optimisation précoce, pas de l'over-engineering (où alors on considère que l'optimisation précoce est un sous ensemble de l'over-engineering ptet ?)
C'est d'ailleurs la méthode de dev de Linux et le facteur de dev mesuré scientifiquement comme étant le plus important d'un point de vue de la qualité du code produit.
Les tokens RSA ne posent sans doute pas de problème à une agence gouvernementale majeure motivée, surtout si c'est celle du pays de la boite qui vend les tokens. Bref y a un équivalent français aux tokens RSA ?
sérieusement, ya des gens qui m'ont moinsé pour ce que j'ai sorti ?
Je le redis donc, pcq les neuneus n'auront pas raison de ma sagesse suprème : "Franchement, si un projet repose sur le fait que des assert doivent être conservés car ils contiennent des effets de bord fonctionnels, hm, RHAAAAAAAAAAAAAAAAAAAAAA"
Et sérieusement, si des neuneus moinsent ça, j'espère au moins qu'ils ne codent pas, et qu'ils se font soigner.
Pour rebondir sur les crapwares sous Windows que tant de boites kiffent, probablement parce que le sadisme de leur dirigeants n'a pas de limite, je viens de tomber sur : http://dendory.net/blog.php?id=509ec629
Franchement, si un projet repose sur le fait que des assert doivent être conservés car ils contiennent des effets de bord fonctionnels, hm, RHAAAAAAAAAAAAAAAAAAAAAA
Hm "Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias" sachant que "The project SHALL be hosted on github.com or equivalent, herein called the "Platform"", c'est quand même très très "mignon" comme exigence.
J'aurais énormément de mal à contribuer à un projet qui utilise Git et qui voudrait me faire ouvrir un compte sur github pour centraliser et accepter mes patchs.
Et si je continue à lire ce bordel j'ai quand même beaucoup de mal à me retenir de crier FOUTAISE en voyant des phrases comme "To maximize the scale of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;"
"reduces the risk of hijack by hostile entities." <-- hm en outre magnifique esprit logiciel libre tout ça…
"A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code." <-- magnifique efficacité; obligation de réinventer toutes les roues et impossibilité absolue de réintégrer des modifications des forks hostiles : MAGNIFIQUE !
"Maintainers SHALL NOT make value judgments on correct patches." hm pensons à l'état qu'aurait Linux (ainsi que divers autres projets) dans ces conditions et … OMFG ! Bien évidemment les exemples inverses de gouvernance complètement refermées, autoritaires et dysfonctionnelles abondent aussi. Simplement sur ce point choisir un extrême pour s'en prémunir d'un autre ne me convainc pas.
Bon bref, ptet que leur objectif de "maximize the scale of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks" est tenable, j'en sais rien, mais moi ça me donne pas envie.
Certains points font presque peur : "Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers."—hm certes, mais… pourquoi c'est nécessaire d'écrire ça ? On a besoin de l'accord, si c'est pas pour cette raison ???
L'intention sous-jacente de ce document est claire : si tu ose ne pas venir sur github (ou équivalent) on te parlera pas et tout code pondu en dehors de ce dogme méthodologique sera banni à jamais. Très bien, mais sans moi !
Je suis en désaccord quasi complet avec ton analyse énonçant qu'il serait souhaitable de casser le système de paquet au prétexte qu'il ne permettrait pas d'avoir une intégration correcte des bundles. Il n'y a aucune raison intrinsèque à ce que ça soit requis, et il serait bon de profiter du meilleurs des deux mondes : permettre une "intégration" acceptable des bundles, sans pour autant jeter le bébé avec l'eau du bain.
Concernant la compatibilité binaire à assez long terme des pilotes de périphérique, l'idée n'est potentiellement réaliste que si l'on utilise un micro noyau (du moins beaucoup plus que Linux et celui de Windows) et d'une manière générale un système beaucoup moins couplé que Windows et la tendance actuelle d'ultra-couplage du monde GNU/Linux (alors que MS fait justement des efforts de découplage depuis moultes années, hm certains concepteurs bien en vue feraient bien d'étudier l'histoire de l'autre côté de la barrière). Windows permet une sorte de compatibilité à ce niveau, mais elle est en fait bien plus mauvaise que la compatibilité dans le reste du système : le passage en 64 bits s'est assez mal passé (incompatibilité des matériels existants (quasi?) générale) et seule la puissance attractive de MS l'a rendue possible, il va probablement se passer exactement la même chose pour l'ARM si MS réussit sur cette archi. L'état des "pilotes" d'imprimantes est pour certaines (beaucoup!) marques calamiteux (justement parce que le système est si tolérant vis-à-vis des logiciels tiers et si prompt à attirer les entreprises de merde en les autorisant à bourrer tout de bloatware sous la dénomination absurde de "valeur ajoutée") et le non fonctionnement des drivers d'un Windows à l'autre est une méthode archi-classique d'obsolescence "programmée" (du moins entérinée). Les drivers d'une génération de sous-système précédent sont parfois tolérés sous Windows, mais modulo l'impossibilité d'utiliser certains logiciels applicatifs ou même certaines fonctions de l'OS (ce qui est parfois assez logique). Linux en forçant l'intégration des drivers les supporte alors parfois bien plus longtemps. De toute façon Apple a montré que le succès commercial pouvait être assez fortement décoléré de l'ouverture de la plateforme et de sa pérennité, initiant au passage une mode malheureuse.
Les besoins principaux en drivers permettant l'extensibilité ou l'évolution des PC de bureau aujourd'hui ne couvrent de toutes manières pas trop de catégories pour couvrir le besoin essentiel technique : imprimante et carte/chip graphique. Les imprimantes sont justement un point ou l'intégration de logiciel libre centralisé a permis un support à très long terme d'un très grand nombre de modèles, donc peu importe si certaines ne sont pas supportée, ce n'est pas plus un drame que les imprimantes de certaines marques qui sont systématiquement dépréciées toutes les deux version de Windows, ni d'ailleurs du device quelconque qui ne fonctionne pas sous OS X ou IOS ou je sais pas quoi. Pour ne pas empêcher le décollage le besoin est marketing et non technique. Concernant les cartes graphiques on est sur un marché ultra hi-tech et très concurrentiel avec encore principalement un cercle vertueux techniquement entre MS et les fabriquant de CG mais excluant fortement toute tentative des tiers de reprendre une partie du leadership pour (co)driver l'évolution. Donc il va falloir dans un premier temps suivre, avec tous les problèmes archi connus qui seront les même que sous Linux. Le besoin principal est un interlocuteur commercial assez puissant, et justement Valve est en train de foutre un peu le bordel dans ce milieu, donc l'idée la plus plausible serait de se greffer à ce mouvement et de réutiliser le plus possible des drivers Linux et stacks graphiques de base Linux. Je ne crois pas une seule seconde à l'arrivée d'un petit nouveau dans ce contexte.
Enfin je ne vois pas pourquoi "stations de travail est très mal servi". OS X est très utilisé pour certaines niches. Les grands éditeurs d'énorme suites logicielles typées "stations de travail" ont tendance à se concentrer sur Windows parce que l'OS suffit largement aujourd'hui (voire, dans certains domaines, est supérieur du fait de l'écosystème), et que cette standardisation de fait procure bien plus d'avantages qu'il ne pourrait y avoir d'inconvénients technique. Par contre pour les logiciels associés à du matériel (embarqué) on voit quelques retour ou passage au multiplateforme notamment dans le domaine des IDE, justement grâce aux plateformes constituée de logiciel libre qui s'imposent par leur qualité, couverture fonctionnelle, et parce que sur des thèmes considérées comme des commodités, puis une fois l'étincelle allumé par le cercle vertueux autour de ses softs se renforce des apports collaboratif de toutes les boites qui s'en servent (bref qui s'imposent par un faisceau de raisons qui ratisse très large). Par contre j'ai l'impression que ce phénomène est confiné au domaine qui intéresse historiquement les informaticiens unixien et/ou libristes vu qu'ils ont les plateformes de dev logiciel traditionnel qui excellent particulièrement et qu’ils drivent ce domaine avec du libre (bref conjonction d’énormément de facteurs, ça risque d’être difficile à reproduire).
Les alimentations électriques n'ont pas besoin de siffler directement de manière audible pour foutre la merde dans un bloc électronique audio.
Une alimentation électrique (ou un bloc DC/DC de point de charge) émet en sortie divers parasites superposés à la tension continue. Si l’électronique ne filtre pas correctement tout cela (et en audio c'est pas forcement évident, l'oreille humaine étant très sensible), on se retrouve avec les-dits parasites dans la partie analogique du bloc audio et finalement dans le haut parleur.
Bref je disais donc qu'il est plus probable que le bruit électronique proviennent au départ d'une alim, voire effectivement de toute la machine si la carte audio est vraiment très mal isolée, que d'une ligne d'interruption. La raison étant qu'une ligne d'interruption ne devrait générer que très peu de bruit.
Est ce que Apple et MS proposent les mêmes avantage du mode de distribution de Steam (et non uniquement les juste les mêmes inconvénients…) ? Si oui alors Steam a du soucis à se faire, si non ils ont encore une sacrée avance. En plus de l'autre sacrée avance qu'ils ont déjà sur le marché des jeux vidéos, hors mobile…
Après est-ce que HL3 sous GNU/Linux uniquement va profondément modifier la répartition des systèmes d'exploitation sur PC, c'est une autre question.
Je ne dirais pas que H & P était des "pauvres gars sans le sous"…
Tous deux ingénieurs, l'un bossant chez GE (pouvant servir de repli en cas d'échec), l'autre sortant du MIT et de Stanford. Familles très aisés ou simplement aisée, je ne sais pas, mais on ne peut pas en tout cas dire qu'ils partaient défavorisés dans la vie et que leur boite est un miracle de l’ascension sociale…
C'est pas parce que X fait Y dans Z et que Z à un grand succès commercial que faire aussi Y dans un contexte != mènera aussi à un grand succès.
D'autre part au moins dans des tas de biblio majeures MS ne permet pas de mélanger deux versions de la même biblio à utiliser par le même processus. En terme d'archi logicielle ça serait complètement tordu.
En revanche il est possible que les traductions récentes soient verrouillées. Il faudrait en trouver une suffisamment vielle ou une explicitement libre.
Il n'y a pas que un docteur, mais exemple hôpital, tu avances les milliers d'Euros qu'il faut pour un opération d'urgence?
Les hôpitaux français, par exemple, ont le bon goût de faire payer les gens après un passage aux urgences… Si le paiement est exigible avant la prise en charge dans d'autres pays, il conviendrait peut-être de fuir ces barbares.
J'adore les sites de rebelles qui dénoncent le (ou rapportent des dénonciations de) flicage et l'exploitation des usagers avec en bas de chaque pages de magnifiques pubs "Suivez-nous sur Facebook / Twitter".
[^] # Re: Open?!
Posté par Guillaume Knispel . En réponse au journal Open Hardware: Mesure de la pollution. Évalué à 7.
Vu l'état actuel de l'open hardware, on peut difficilement qualifier la carte principale de traitement de l'information d'un système de simple composant.
Sinon je prend le manuel de service de mon laptop et je prétend que c'est de l'open hardware : c'est juste ridicule.
[^] # Re: Open?!
Posté par Guillaume Knispel . En réponse au journal Open Hardware: Mesure de la pollution. Évalué à 10.
"Mais la démarche s'incrit dans cette mouvance."
Cette phrase est là pour qu'on puisse jouer au business loto ?
Plus sérieusement je suis 100 % d'accord avec le problème identifié ici, le raspberry pi est un bidule intéressant mais surtout pour brancher sur un écran HD, et totalement inadapté ici, et qui n'a rien d'open hardware, et n'a pas son logiciel de base libre si je ne m'abuse.
Il en existe depuis 20 ans des board principales ultra light à base de uC, bien plus adaptées pour ce projet, et en open hardware ça doit pouvoir se trouver en préexistant, sinon il y a des gens qui seront ravis d'en faire.
Ce qui aurait permis à "Olivier Blondeau, docteur à Sciences Po" de dire << Le tout en “full open hardware” >> sans se full-décrédibiliser instantanément.
[^] # Re: Je veux pas troller, mais...
Posté par Guillaume Knispel . En réponse au journal Trolldi : Lennart en pleine forme. Évalué à 6.
hein ?
[^] # Re: Je veux pas troller, mais...
Posté par Guillaume Knispel . En réponse au journal Trolldi : Lennart en pleine forme. Évalué à 4.
Tu penses que l'être humain bien-pensant né avec une tendance naturelle à haïr Lennart ?
[^] # Re: POO
Posté par Guillaume Knispel . En réponse au journal Du code propre, c'est quoi ?. Évalué à 2.
Ce que tu décris c'est de l'optimisation précoce, pas de l'over-engineering (où alors on considère que l'optimisation précoce est un sous ensemble de l'over-engineering ptet ?)
[^] # Re: Code review
Posté par Guillaume Knispel . En réponse au journal Du code propre, c'est quoi ?. Évalué à 2.
C'est d'ailleurs la méthode de dev de Linux et le facteur de dev mesuré scientifiquement comme étant le plus important d'un point de vue de la qualité du code produit.
[^] # Re: pourquoi ?
Posté par Guillaume Knispel . En réponse au journal Le saviez vous ?. Évalué à 2.
À l'origine pour faire du graphisme du moins :)
[^] # Re: sécurité
Posté par Guillaume Knispel . En réponse au journal La France attaquée par les chinois du F.B.I. Évalué à 6.
Les tokens RSA ne posent sans doute pas de problème à une agence gouvernementale majeure motivée, surtout si c'est celle du pays de la boite qui vend les tokens. Bref y a un équivalent français aux tokens RSA ?
[^] # Re: assert (rc != -1)
Posté par Guillaume Knispel . En réponse au journal ZeroMQ et les mangoustes. Évalué à 2.
Tu as un problème à comprendre "effet de bord fonctionnel" ?
[^] # Re: assert (rc != -1)
Posté par Guillaume Knispel . En réponse au journal ZeroMQ et les mangoustes. Évalué à 2.
sérieusement, ya des gens qui m'ont moinsé pour ce que j'ai sorti ?
Je le redis donc, pcq les neuneus n'auront pas raison de ma sagesse suprème : "Franchement, si un projet repose sur le fait que des assert doivent être conservés car ils contiennent des effets de bord fonctionnels, hm, RHAAAAAAAAAAAAAAAAAAAAAA"
Et sérieusement, si des neuneus moinsent ça, j'espère au moins qu'ils ne codent pas, et qu'ils se font soigner.
sérieusement
[^] # Re: intuitive != d'utilisable
Posté par Guillaume Knispel . En réponse au journal Moment de détente. Évalué à 6.
Une des caractéristiques les plus importantes d'une IHM est justement d'être "intuitive" (au moins découvrable).
Si ça n'est pas le cas, c'est un FAIL.
[^] # Re: Delayed firmware loading
Posté par Guillaume Knispel . En réponse au journal Les big balls de gentoo. Évalué à 10.
Pour info il bosse chez RH.
Les types controversés de Gnome aussi.
Sans oublier le mec le plus célèbre du moment.
Mais j'ai probablement tords d'y voir un pattern, et puis de toutes façon ils sont gentils chez RH, ils contribuent à Linux.
[^] # Re: casser les paquets et imposer la compatibilité binaire des drivers
Posté par Guillaume Knispel . En réponse au journal Si on commençait un nouvel OS libre de bureau aujourd'hui.... Évalué à 5.
Pour rebondir sur les crapwares sous Windows que tant de boites kiffent, probablement parce que le sadisme de leur dirigeants n'a pas de limite, je viens de tomber sur : http://dendory.net/blog.php?id=509ec629
[^] # Re: assert (rc != -1)
Posté par Guillaume Knispel . En réponse au journal ZeroMQ et les mangoustes. Évalué à 0.
Franchement, si un projet repose sur le fait que des assert doivent être conservés car ils contiennent des effets de bord fonctionnels, hm, RHAAAAAAAAAAAAAAAAAAAAAA
sérieusement
[^] # Re: M'enfin !
Posté par Guillaume Knispel . En réponse au journal ZeroMQ et les mangoustes. Évalué à 9.
Hm "Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias" sachant que "The project SHALL be hosted on github.com or equivalent, herein called the "Platform"", c'est quand même très très "mignon" comme exigence.
J'aurais énormément de mal à contribuer à un projet qui utilise Git et qui voudrait me faire ouvrir un compte sur github pour centraliser et accepter mes patchs.
Et si je continue à lire ce bordel j'ai quand même beaucoup de mal à me retenir de crier FOUTAISE en voyant des phrases comme "To maximize the scale of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;"
"reduces the risk of hijack by hostile entities." <-- hm en outre magnifique esprit logiciel libre tout ça…
"A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code." <-- magnifique efficacité; obligation de réinventer toutes les roues et impossibilité absolue de réintégrer des modifications des forks hostiles : MAGNIFIQUE !
"Maintainers SHALL NOT make value judgments on correct patches." hm pensons à l'état qu'aurait Linux (ainsi que divers autres projets) dans ces conditions et … OMFG ! Bien évidemment les exemples inverses de gouvernance complètement refermées, autoritaires et dysfonctionnelles abondent aussi. Simplement sur ce point choisir un extrême pour s'en prémunir d'un autre ne me convainc pas.
Bon bref, ptet que leur objectif de "maximize the scale of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks" est tenable, j'en sais rien, mais moi ça me donne pas envie.
Certains points font presque peur : "Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers."—hm certes, mais… pourquoi c'est nécessaire d'écrire ça ? On a besoin de l'accord, si c'est pas pour cette raison ???
L'intention sous-jacente de ce document est claire : si tu ose ne pas venir sur github (ou équivalent) on te parlera pas et tout code pondu en dehors de ce dogme méthodologique sera banni à jamais. Très bien, mais sans moi !
# casser les paquets et imposer la compatibilité binaire des drivers
Posté par Guillaume Knispel . En réponse au journal Si on commençait un nouvel OS libre de bureau aujourd'hui.... Évalué à 10.
Je suis en désaccord quasi complet avec ton analyse énonçant qu'il serait souhaitable de casser le système de paquet au prétexte qu'il ne permettrait pas d'avoir une intégration correcte des bundles. Il n'y a aucune raison intrinsèque à ce que ça soit requis, et il serait bon de profiter du meilleurs des deux mondes : permettre une "intégration" acceptable des bundles, sans pour autant jeter le bébé avec l'eau du bain.
Concernant la compatibilité binaire à assez long terme des pilotes de périphérique, l'idée n'est potentiellement réaliste que si l'on utilise un micro noyau (du moins beaucoup plus que Linux et celui de Windows) et d'une manière générale un système beaucoup moins couplé que Windows et la tendance actuelle d'ultra-couplage du monde GNU/Linux (alors que MS fait justement des efforts de découplage depuis moultes années, hm certains concepteurs bien en vue feraient bien d'étudier l'histoire de l'autre côté de la barrière). Windows permet une sorte de compatibilité à ce niveau, mais elle est en fait bien plus mauvaise que la compatibilité dans le reste du système : le passage en 64 bits s'est assez mal passé (incompatibilité des matériels existants (quasi?) générale) et seule la puissance attractive de MS l'a rendue possible, il va probablement se passer exactement la même chose pour l'ARM si MS réussit sur cette archi. L'état des "pilotes" d'imprimantes est pour certaines (beaucoup!) marques calamiteux (justement parce que le système est si tolérant vis-à-vis des logiciels tiers et si prompt à attirer les entreprises de merde en les autorisant à bourrer tout de bloatware sous la dénomination absurde de "valeur ajoutée") et le non fonctionnement des drivers d'un Windows à l'autre est une méthode archi-classique d'obsolescence "programmée" (du moins entérinée). Les drivers d'une génération de sous-système précédent sont parfois tolérés sous Windows, mais modulo l'impossibilité d'utiliser certains logiciels applicatifs ou même certaines fonctions de l'OS (ce qui est parfois assez logique). Linux en forçant l'intégration des drivers les supporte alors parfois bien plus longtemps. De toute façon Apple a montré que le succès commercial pouvait être assez fortement décoléré de l'ouverture de la plateforme et de sa pérennité, initiant au passage une mode malheureuse.
Les besoins principaux en drivers permettant l'extensibilité ou l'évolution des PC de bureau aujourd'hui ne couvrent de toutes manières pas trop de catégories pour couvrir le besoin essentiel technique : imprimante et carte/chip graphique. Les imprimantes sont justement un point ou l'intégration de logiciel libre centralisé a permis un support à très long terme d'un très grand nombre de modèles, donc peu importe si certaines ne sont pas supportée, ce n'est pas plus un drame que les imprimantes de certaines marques qui sont systématiquement dépréciées toutes les deux version de Windows, ni d'ailleurs du device quelconque qui ne fonctionne pas sous OS X ou IOS ou je sais pas quoi. Pour ne pas empêcher le décollage le besoin est marketing et non technique. Concernant les cartes graphiques on est sur un marché ultra hi-tech et très concurrentiel avec encore principalement un cercle vertueux techniquement entre MS et les fabriquant de CG mais excluant fortement toute tentative des tiers de reprendre une partie du leadership pour (co)driver l'évolution. Donc il va falloir dans un premier temps suivre, avec tous les problèmes archi connus qui seront les même que sous Linux. Le besoin principal est un interlocuteur commercial assez puissant, et justement Valve est en train de foutre un peu le bordel dans ce milieu, donc l'idée la plus plausible serait de se greffer à ce mouvement et de réutiliser le plus possible des drivers Linux et stacks graphiques de base Linux. Je ne crois pas une seule seconde à l'arrivée d'un petit nouveau dans ce contexte.
Enfin je ne vois pas pourquoi "stations de travail est très mal servi". OS X est très utilisé pour certaines niches. Les grands éditeurs d'énorme suites logicielles typées "stations de travail" ont tendance à se concentrer sur Windows parce que l'OS suffit largement aujourd'hui (voire, dans certains domaines, est supérieur du fait de l'écosystème), et que cette standardisation de fait procure bien plus d'avantages qu'il ne pourrait y avoir d'inconvénients technique. Par contre pour les logiciels associés à du matériel (embarqué) on voit quelques retour ou passage au multiplateforme notamment dans le domaine des IDE, justement grâce aux plateformes constituée de logiciel libre qui s'imposent par leur qualité, couverture fonctionnelle, et parce que sur des thèmes considérées comme des commodités, puis une fois l'étincelle allumé par le cercle vertueux autour de ses softs se renforce des apports collaboratif de toutes les boites qui s'en servent (bref qui s'imposent par un faisceau de raisons qui ratisse très large). Par contre j'ai l'impression que ce phénomène est confiné au domaine qui intéresse historiquement les informaticiens unixien et/ou libristes vu qu'ils ont les plateformes de dev logiciel traditionnel qui excellent particulièrement et qu’ils drivent ce domaine avec du libre (bref conjonction d’énormément de facteurs, ça risque d’être difficile à reproduire).
[^] # Re: J'ai la même chose ...
Posté par Guillaume Knispel . En réponse au journal Avec un bon Dell on peut.... Évalué à 2.
Les alimentations électriques n'ont pas besoin de siffler directement de manière audible pour foutre la merde dans un bloc électronique audio.
Une alimentation électrique (ou un bloc DC/DC de point de charge) émet en sortie divers parasites superposés à la tension continue. Si l’électronique ne filtre pas correctement tout cela (et en audio c'est pas forcement évident, l'oreille humaine étant très sensible), on se retrouve avec les-dits parasites dans la partie analogique du bloc audio et finalement dans le haut parleur.
Bref je disais donc qu'il est plus probable que le bruit électronique proviennent au départ d'une alim, voire effectivement de toute la machine si la carte audio est vraiment très mal isolée, que d'une ligne d'interruption. La raison étant qu'une ligne d'interruption ne devrait générer que très peu de bruit.
[^] # Re: On parie?
Posté par Guillaume Knispel . En réponse au journal Half-life 3 sera sous linux. UNIQUEMENT SOUS LINUX !. Évalué à 2.
Est ce que Apple et MS proposent les mêmes avantage du mode de distribution de Steam (et non uniquement les juste les mêmes inconvénients…) ? Si oui alors Steam a du soucis à se faire, si non ils ont encore une sacrée avance. En plus de l'autre sacrée avance qu'ils ont déjà sur le marché des jeux vidéos, hors mobile…
Après est-ce que HL3 sous GNU/Linux uniquement va profondément modifier la répartition des systèmes d'exploitation sur PC, c'est une autre question.
[^] # Re: Nos rentes d'abord !
Posté par Guillaume Knispel . En réponse au journal Le logiciel dévore le monde… depuis les États‐Unis. Évalué à 5.
Je ne dirais pas que H & P était des "pauvres gars sans le sous"…
Tous deux ingénieurs, l'un bossant chez GE (pouvant servir de repli en cas d'échec), l'autre sortant du MIT et de Stanford. Familles très aisés ou simplement aisée, je ne sais pas, mais on ne peut pas en tout cas dire qu'ils partaient défavorisés dans la vie et que leur boite est un miracle de l’ascension sociale…
[^] # Re: Autorisations
Posté par Guillaume Knispel . En réponse au journal ice cream sandwich, je ne mange pas de ce pain-là. Évalué à 2.
Hm on peut ptet considérer que ce sont des conditions abusives et donc non applicables.
[^] # Re: Tu critiques Qt ?
Posté par Guillaume Knispel . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 6.
C'est pas parce que X fait Y dans Z et que Z à un grand succès commercial que faire aussi Y dans un contexte != mènera aussi à un grand succès.
D'autre part au moins dans des tas de biblio majeures MS ne permet pas de mélanger deux versions de la même biblio à utiliser par le même processus. En terme d'archi logicielle ça serait complètement tordu.
[^] # Re: Privé moins cher ?
Posté par Guillaume Knispel . En réponse au journal L’aventure spatiale perd un peu de sa liberté. Évalué à 1.
Celle qui ressemble comme deux goutes d'eau et qui n'a volé qu'une fois ? C'est pas un peu hypothétique comme affirmation ?
[^] # Re: Licence
Posté par Guillaume Knispel . En réponse au journal Une religion open source ?. Évalué à 3.
En revanche il est possible que les traductions récentes soient verrouillées. Il faudrait en trouver une suffisamment vielle ou une explicitement libre.
[^] # Re: encore un truc bien logique de nos ENArques
Posté par Guillaume Knispel . En réponse au journal Situation des frontaliers Suisse : vers la fin du choix de cotisation pour l'assurance maladie. Évalué à 2.
Les hôpitaux français, par exemple, ont le bon goût de faire payer les gens après un passage aux urgences… Si le paiement est exigible avant la prise en charge dans d'autres pays, il conviendrait peut-être de fuir ces barbares.
# J'adore
Posté par Guillaume Knispel . En réponse au journal L'analyse d'un béotien sur les tendance big brother de google. Évalué à 10.
J'adore les sites de rebelles qui dénoncent le (ou rapportent des dénonciations de) flicage et l'exploitation des usagers avec en bas de chaque pages de magnifiques pubs "Suivez-nous sur Facebook / Twitter".