Obsidian a écrit 5292 commentaires

Pour le SQL, en effet, ça ne peut pas marcher ! Par contre, cela fonctionnerait très bien avec un OR central. Le problème vient du fait que ce qui t'intérresse, ce n'est pas seulement les lignes qui correspondent à un certain critère, mais le fait qu'il y ait PLUSIEURS de ces lignes, sur des critères différents. Il faut donc interroger deux fois la table, et interpoler les résultats. Donc, en une requête:

SELECT DISTINCT a.site FROM TABLE a, TABLE b
WHERE a.site = b.site
AND a.question = 1
AND a.reponse = 0
AND b.question = 3
AND b.question = 0

Et cela devrait fonctionner. Note qu'en temps normal il vaut mieux utiliser JOIN qu'un produit cartésien (selection de plusieurs tables séparées par des virgules), mais dans le cas présent il ne s'agit pas d'une réelle jointure, en tout cas d'une table dépendante d'une autre ...

C'est une chouette initiative ... à condition que la qualité de l'intégration du logiciel soit au rendez-vous.

S'ils sortent sous Linux une version éponyme de leur produit phare sous Windows mais qu'il s'agit d'un premier jet sous Linux, sans grande expérience, comme on en voit de temps en temps, alors beaucoup de gens risquent d'utiliser ce genre de logiciel comme « étalon » pour comparer les deux systèmes (« PowerDVD tourne 24,17% moins bien sous Linux ! »).

Il sera très difficile d'expliquer aux nouveaux venus la réalité des choses sans passer pour des gens de mauvaise foi ...

Et pour faire renaître un paquet de cigarettes de ses cendres ?

Tu as bien de la chance avec ton chipset VIA.

Personnellement, j'ai toujours eu vent de problèmes en tous genres avec les chipsets de cette marque, depuis plusieurs années. Récement, un copain a acheté une carte mère bien équipée en VIA (North Bridge + South Bridge: Controleur IDE, SATA, carte son plus deux trois autres babioles).

- Impossible d'utiliser le Serial ATA (pas encore reconnu par une Mdk9.2). Bon, on a mis cela sur le compte de la jeunesse du matériel. Il a fallu toutefois fouiller bien profond sur kernel.org pour trouver un patch SATA pour ce chipset, et encore, valable qu'a partir du 2.4.23. Maintenant ca marche, mais il nous faut toujours utiliser un disque IDE ATA parallèle standard pour booter.

- Carte son: Utilisation d'ALSA, dernier pilote en date. Essayé également avec la release précédente. Le son fonctionne, mais la qualité est dégueulasse, et visiblement personne ne connaît le problème. Le son grésille, mais pas à cause d'un saturation, d'un larsen ou autre. Cela ressemble plutôt à ce qu'il se passe lorsque qu'un sample est mal encodé, trop compressé ou que le bit7 est inversé mais en moins violent. Visiblement le problème est logiciel.

- Evidement, il ne faut pas compter sur VIA pour proposer des pilotes Linux et à jour. La seule chose que l'on ait trouvé par le disque par exemple est un module noyau pour RedHat 7.1, exclusivement.

Je n'ai pas essayé les autres chipsets, probablement mieux reconnus et pris en charge, mais je reste toujours méfiant à présent.

Débat sensible s'il en est !

Personnellement, ma préférence a de plus en plus tendance à s'écarter de celles des autres et est principalement axée sur le bas-niveau et l'optimisation. Donc :

- énormément de langage C.

- Du C++ également, lorsque j'ai besoin d'une structure objet. Dans ce domaine, j'affectionne spécialement ce langage plutôt que d'autres comme Java, d'abord parce qu'il se comporte, à la compilation, comme le C et permet de produire du code très proche de la machine, ensuite parce que je fais un usage assez poussé de la surcharge des opérateurs (nécessaires à mon goût pour réellement définir un nouveau « type »), ainsi que certains principes assez intérressants comme l'héritage multiple et aussi les templates.

- Beaucoup d'assembleur. C'est par définition le seul langage qui permette de s'affranchir des couches intermédiaires. Je m'étonne d'ailleurs qui si peu de gens soient encore intérressés par savoir comment fonctionne réellement leur machine. Il existe toujours un fossé entre l'assembleur et le langage C pourtant réputé être le plus proche.

- Coté scripts, j'aime beaucoup le shellscript. Perl est très sympa aussi mais je n'ai jamais eu le temps de m'y mettre sérieusement.

En résumé: Tout ce qui m'apporte liberté et puissance !

la fete de la musique c'est quand deja ?

LE 21 juin ! :-)

Oui, d'ailleurs je serais bien content de commencer à avoir des retours sur cette version stable d'ALSA.

Je l'ai installé (ainsi que la release immédiatement précédente) sur le PC tout neuf d'un copain: Carte son intégrée, gérée par un chipset VIA.

Le son sort, mais est de très mauvaise qualité. Quelqu'un a-t-il déjà rencontré ce problème ?

Exact, d'ailleurs les américains y sont allés parce qu'il parait que les sondes orbitales y auraient détecté des armes de destruction massive ...

On peut reprendre tes propos dans l'autre sens: Tu prends une la dernière Mdk, tu lances drakeconf ou ce qui en tient lieu depuis le bureau de KDE, et voila: En trois clics tout est configuré. Maintenant est-ce que M. Toutlemonde a besoin d'avoir une machine super optimisée ?

Il y a aussi un module spécial dans le noyau (EXPERIMENTAL) pour forger tes paquets. Vois si les autres outils peuvent en avoir besoin.

Certes ! :-)

M'enfin bon, ceci dit, cela reste de la responsabilité de leur hébergeur. Je suis curieux de savoir quelle est la formule qu'ils ont choisi, mais justement, en tant qu'experts, je suppose qu'ils ont opté à la base pour quelque chose de dimensionné.

Arg, en effet.

Non seulement Hoaxbuster est en tête de liste de mes bookmarks depuis longtemps, mais j'y renvoie systématiquement tous ceux qui me font suivre un hoax, et ce, comme pas mal de monde.

Espérons que cela se règle vite.

Le troll officiel est de retour et l'Equation est enfin équilibrée ...

Je crois que la meilleure traduction est encore « qui n'a plus cours », même si cela ne tient pas en un mot ...

Ce serait bien, mais objectivement, tant qu'il y aura des PCs préinstallés vendus, ils gagneront des clients ...

C'est ce qu'on vient de dire ! :-)

C'est clair que cela ne vole pas très haut, mais bon il y a du vrai et du faux.

Evidement, dire que si une version supérieure est plus rapide, c'est parce que la précédente a été bâclée, c'est faire abstraction du temps que peut prendre l'optimisation d'un programme (souvent autant que le temps de rédaction + débuggage de ladite application).

Cela dit, il est quand même bon de se rendre compte que même dans ce genre de canard, il y a des gens qui sont attachés à la qualité de la rédaction d'un logiciel, et puis cela nous change du désormais habituel « On s'en fout de l'optimisation, on a toute la puissance qu'on veut ».

« Envoie un patch » ©®™

Mouais, ton post est pertinent. Cela vaudrait le coup de s'y pencher un peu, pour voir ...

Mais bon, on pourrait parler un peu de Linux pour changer ? :-)

Exact, ils finissent aussi au Pizza Hut ...

Sinon, ce que tu veux faire en particulier s'appelle un socket:

man socket
man 2 bind

Pas besoin d'écrire un module pour ça. Et puis si tu veux faire une connexion réseau bidirectionnelle, netcat peut très bien se mettre à l'écoute d'un port. C'est pratique pour voir par exemple quelles entêtes un navigateur web envoie à un serveur. L'inverse est aisée avec un telnet sur le port 80, mais c'est plus difficile dans ce sens sans netcat. Au fait ce ne serait pas ce que tu cherches à faire, des fois ?

Le LINUX KERNEL MODULE PROGRAMMING GUIDE officiel est ton ami:

http://www.google.fr/search?q=LKMPG&ie=UTF-8&oe=UTF-8&h(...)
http://www.faqs.org/docs/kernel/(...)

Je ne connais pas grand chose au PCMCIA, mais à priori non.

Cela fonctionne exactement comme une carte interne, ou même quoi que ce soit qui soit branché sur le port parallèle ou série. Il y a une broche d'alimentation et une masse pour permettre à l'équipement terminal qui y est relié de fonctionner correctement, mais ce n'est pas dimensionné pour alimenter une ville, si je puis m'exprimer ainsi.

Je pense que cette notion a été introduite avec le port USB, qui cause bien du tracas aux électroniciens car toutes ces merveilleuses idées sont particulièrement chiantes à implémenter. Dans la mesure où il a été déclaré que le bus de données serait aussi un bus d'alimentation, non seulement les circuits ont été dimensionnés pour, mais des systèmes de mesure (au moins de dépassement du seuil maximal) ont été mis en place. C'est seulement à ce titre que de gros périphériques comme un Ipod ou un modem USB peuvent être connectés par un seul câble, ce qui, il faut le reconnaître, est quand même bien pratique.

Autrement, faire se recharger une batterie au travers d'un port série (pourtant conçu pour être très robuste) serait déjà limite, mais par le biais de quelque chose d'aussi intégré et portable qu'une carte PCMCIA, cela me parait quelque peu suicidaire (pas de fusible, broches minuscules, aucun - mais alors aucun - moyen de dissiper la chaleur ...).

Pour Windows préinstallé, complètement vrai. Cela établit un standard de fait, et tout le monde le sait bien, à commencer par Microsoft lui-même qui dégage une énergie incroyable pour que cela dure.

Pour les installs automatiques, ce n'est pas tant Linux qui a à faire des progrès. D'abord parce que ma Knoppix reconnait très bien le touchpad PS/2 de mon portable :-) Ensuite, parce que Windows lui-même est loin d'être meilleur. Par contre les fabricants eux-mêmes passent beaucoup de temps à intégrer LEURS produits à un système statique. S'ils faisaient exactement la même chose avec Linux, le système serait aussi connu que le Mac, à mon avis..

D'ailleurs je ne vois vraiment pas pourquoi ces fabricants - professionnels du métier, et pas simples utilisateurs qui ne veulent pas se soucier de l'état de l'art en la matière - n'y mettent pas plus de zèle: Non seulement toutes les spécifications, jusqu'à la dernière ligne de code, de Linux sont disponibles, mais on est même prêt à faire le travail pour eux (dans une certaine mesure).

Oui, c'est inquiétant, mais peut-être n'auront-ils même plus besoin d'être reliés au Système pour savoir tout cela (c.f. cette petite blague devenue célèbre):

http://www.auduteau.net/humour/vrac/vrac21.shtml(...)