Batchyx a écrit 1261 commentaires

À quelques exceptions près, c'est lent sur toutes les plateformes.

Le Web fait autant partie d'Internet que la redoute fait partie du réseau postal.

Le Web utilise Internet, mais il pourrai très bien utiliser autre chose, et jeter Internet dans la rue comme un chien. Un peu comme ce que font les opérateurs mobiles.

D'une part, ifconfig est déprécié, mais surtout iwconfig (qui est tout autant déprécié, sinon plus) n'en à rien à faire que l'interface soit up ou pas. Il va la lister quand même.

Donc si iw dev ne liste rien, c'est pas la peine de tenter des ip link set wlan0 up.

Sinon, il faudrai plutôt avoir la sortie de dmesg après un boot. Histoire qu'on sache si le noyau à tenté quelque chose avec cette carte (du genre essayer de charger un firmware).

Ça dépend du quota que tu à dans ton répertoire personnel. Si c'est pas gros, vaut mieux pas avoir trop de sources. Après on peut travailler dans /tmp/ ou sur une clef USB, mais c'est franchement pas pratique.

Parce que tel que c'est documenté, il faut minimum 200 Mo de place disponible.

C'est pas possible de simplement extraire les rpm dans son repertoire perso et de bidouiller les variables d'environnements LD_truc pour les faire marcher ?

Tu à oublié le passage par déplacement ;)

Pour les surcharge d'opérateurs, c'est plus simple que ça. Le compilateur ne va chercher des surcharges membres dans s ou dans le namespace du type de s ou de a. Et si les conversions foires ou qu'il n'y en a pas une seule surcharge définie, ça ne va pas plus loin.

Donc non, si tu définit tes 600 surcharges d'opérateurs correctement et que tu reparti tes types maisons dans des espace de noms différents, ton compilo ne va pas essayer 600 conversions.

Mais bon, les lenteurs de compilations de C++ ne sont pas si grandes que ça lorsqu'on utilise pas un métaprogramme qui génère des analyseurs syntaxiques ou des expressions rationnelles.

Et ça passe à l'échelle à 30 000 articles ?

Ce qui est lent en C++, c'est pas l'analyse syntaxique ou la preprocession, c'est toutes les couches de métaprogramations entre les templates et les expressions constantes.

À partir du moment ou tu cherche à avoir un tableau de taille "20ième nombre de la suite de fibonacci", tes temps de compiles explosent, même si ton source préprocéssé fait dix lignes.

Et si on retire ces fonctionnalités là à C++, alors le langage n'a plus beaucoup d'intérêt.

Si ce sont des radios commerciales, il peut y avoir des problèmes de droit d'auteur.

Et ça fait quoi si son FAI filtre les requêtes vers les serveurs racines (voire les serveurs DNS des sites qu'il cherche à visiter) ?

PS: rm /etc/resolv.conf à le même effet que ta deuxième commande.

Tu à déjà lu la GPLv2 (utiliséee par x264) ? Notamment la section 7, 8 et/ou l'avant dernier paragraphe du préambule.

N'importe qui peut prendre le code de x264, s'en servir et le modifier sans avoir à payer de brevets. Si ce n'est pas le cas, alors publier x264 sous licence GPLv2 est illégal, ou alors il faut poser une restriction sur les pays ou la distribution est autorisée.

Ce ne sont pas les options de compilation qui posent problème, c'est l'ordre dans lequel tu spécifie les éléments que tu doit lier. C'est d'ailleurs bizarre que ça marchait avant, parce que l'éditeur de lien ld à toujours été sensible à l'ordre de ses entrées.

Si ton programme utilise des symboles d'une bibliothèque (et non l'inverse), alors les fichiers *.o doivent être spécifiés avant la bibliothèque en question.

Autrement dit, LDFLAGS doit toujours se trouver derrière $^

Mais quelque soit l'avenir, il serait bon qu'Alsa soit interrogeable officiellement via D-Bus, ce qui donnerait un accès à Alsa à tout langage dès qu'il existerai un module D-Bus pour ce langage !

Tu confond plusieurs choses.

L'affaire de D-Bus dans le noyau, c'est pour avoir un bus contenant des données arbitraires avec des (hum) envois multicast fiables et ordonnés¹ (hum), pour permettre d'implémenter des bus arbitraires entre les applications.

Or D-Bus, c'est un bus avec un protocole maison, qui est un peu bizarre et chiant à la fois. Personne (à ma connaissance) veut d'implémenter ça dans le noyau. Ou en tout cas, personne de sensé: le protocole D-Bus est totalement inadapté pour parler avec le noyau; D-Bus nécessite que les interfaces soient stables entre l'appelant et l'appelé, or le noyau évolue et l'userspace aussi, et les deux doivent être rétrocompatible avec des anciennes versions, et ça D-Bus le propose pas.

Et surtout, le noyau possède déjà un protocole pour parler avec l'utilisateur: generic netlink. C'est un protocole simple et extensible (les deux parties peuvent ignorer des attributs qu'ils ne connaissent pas) qui est implémenté depuis belle lurette.

Et Alsa ? c'est à la fois une API pour passer du son au noyau, et une bibliothèque utilisateur (c'est pas le noyau qui lit ~/.asoundrc) qui applique une configuration définie par l'administrateur ou l'utilisateur et qui passe ça au noyau.

Si tu veux parler Alsa via D-Bus, ça veut dire qu'il va falloir un démon qui applique la configuration qui était appliqué par libasound avant, et qui lui, parle au noyau. Franchement, il y a déjà pulseaudio pour ça.

Ou plus simplement, ça répond aux cas de figures que eux connaissent, et ils n'ont jamais pensé au tiens, ou sous-estiment la quantité d'utilisateurs qui utilisent l'outil comme toi.

Ou sont payés par une boite qui n'a pas de client avec ce cas de figure, et qui n'a pas envie d'investir dedans.

si tu leur expose ton problème, il vont rejeter la faute sur toi ou sur les autres logiciels que tu essaye de faire marcher avec le leur. Quand c'est pas le cas, ils vont attendre un patch.
Procès d'intention.

Pourtant la réponse est souvent explicite: "Your setup is broken".

Et même s'ils te répondent qu'ils n'ont pas les ressources pour ça et veulent un patch, ils sauront au moins que ça intéresse des utilisateurs, et si un jour un dév se propose de leur filer un coup de main, ils pourront lui proposer de résoudre ton problème.

Si tout les développeurs étaient aussi ouverts que ça, je leur offrirai des patches plus souvent. Le (non) problème dans ce cas là, c'est que le plus souvent, j'ai aucun problème avec leur logiciel.

Si tous les dévs pensaient comme ça, je ne pourrais pas utiliser un système Libre aujourd'hui!

La plupart des développeurs bénévoles développent parce que ça leur fait plaisir. Un code crade et cryptique, franchement, ça fait pas envie, non pas juste par esthétisme, mais par facilité de patcher. Si le code est crade et que ta modification ne l'arrange pas, tu est quasiment sur que ton patch marchera pas, ou alors créera des bugs supplémentaires. Ça veut dire qu'il faudra plus d'effort pour faire un patch qui marche dans tout les cas. Si je suis payé pour le faire, je le fais, mais sinon, je préfère aller voir ailleurs. Faut pas s'étonner que le projet ne reçoive pas beaucoup de contribution extérieure dans ce cas.

Alors quand je dis que je ferai un patch crade, je ferai un patch crade qui marchera chez moi dans mon cas d'utilisation. Le publier, ça serai juste faire perdre du temps, ou rajouter des bugs chez les autres.

Mais note encore que "ils peuvent se brosser pour leur patch": attends-toi forcément à "vas te brosser pour l'appli dont t'as besoin!".

Je rappelle qu'on parle d'un projet qui implémente une mauvaise idée et qui la documente. Ces projets là ne sont pas courants. La seule chose que j'affirme, c'est que la plupart de ces projets ne sont pas ouverts. Les rares fois ou je suis payé pour soumettre un patch à ces projets là, ça se passe souvent très mal.

Bien sûr les geeks barbus qui codent sont tous des obtus fini incapable d'avoir la moindre ouverture d'esprit et toujours nombrilistes.

Non, mais certains le sont. Et c'est bizarre, mais c'est leur logiciels qui me pose le plus de problème. Et j'ai même pas besoin de le signaler, quelqu'un l'a déjà fait et s'est fait rembarrer (ou mieux, ignoré) à ma place.

D'ailleurs les bug trackers ne servent à rien puisque ça marche chez eux, ils ne corrigeront jamais quoi que ce soit.

Chez certains projets, c'est clairement ça. un bug avec un patch qui traîne ou qui est marqué wontfix, avec plein de votes ou de commentaires. Et pendant ce temps là, les auteurs ne cherchent pas à corriger le problème.

En fait ce n'est pas que tu crois que les développeurs sont associables, tu crois juste qu'ils sont comme toi…

Ne généralise pas des choses que je ne pense même pas. Je n'ai pas de problème avec la plupart des logiciels.

Ou à sa gestion mémoire. Ou à l'orienté objet pur.

Mais il y a un problème: Ça ne gère pas les templates. Vous savez, la chose qui sert normalement à générer du code en C++, et accessoirement à faire du polymorphisme.

Bah oui mais rien que QString, QStringList, QVariant, QRegExp suffisent largement à me faire préférer Qt à c++ + boost, même si au final on arrive à faire la même chose avec boost, on a d'un coté un truc simple et bien intégré et de l'autre un machin complexe qui jongle avec une classe string trop simple.

Ça n'est que ton avis. Moi j'écrirai pas un parseur avec Qt.

Par ailleurs tu continues de ne regarder que c++ + boost, sauf que les projets ne faisant 'que' du mode console, y'en a pas des masses, tu vas souvent avoir un autre tookit pour l'affichage, gtk, IlogViews, Win32…

Et pourquoi pas Qt ? Quand je l'utilise, je fait tout le modèle + contrôleur en boost, puis la vue en Qt (+ boost pour tout ce que Qt ne fait pas).

Même si, je te l'accorde, je fais plus souvent des logiciels sans interface graphique pour des machines sans écrans.

Certaines (la plupart?) bibliothèques de boost proposent une version header-only: Il suffit juste d'inclure un entête contenant l'implémentation dans un de tes fichiers, et hop, plus besoin de bibliothèque.
Après ça fait de la duplication de code, mais faut savoir ce qu'on veut.

Et puis bon, si on compare la taille des bibliothèque que tu utilise à QtCore uniquement, la différence est vite vue: boost ne réimplémente pas toute la bibliothèque standard C++03, contrairement à Qt.

Et sinon, certaines des bibliothèque de boost peuvent être évitées en utilisant des constructions plus statiques, ou en passant à C++11.

Mais dépendant d'une certaine version, d'une certaine bibliothèque, avec un code pas forcément lisible.

Une bibliothèque ? ou ça ? boost::signal2 ne sont que des entêtes. La seule dépendance, c'est un compilateur C++ standard … ou pas.

Entre une dépendance à boost ou une dépendance à Qt, la différence est faible.

Donc en gros, pour toi, dépendre d'entêtes écrites en C++ standard utilisant uniquement la bibliothèque standard, c'est pareil que d'utiliser une bibliothèque externe et un générateur de code ?

Si ces logiciels étaient payant, ça serait pareil, sinon mieux: les logiciels que j'aime n'aurai pas idée de s'intégrer avec eux ;)

Biensûr que tout est possible avec des macros et des templates, mais est-ce que on arrive à du code aussi clair que celui de Qt ?

Tout dépend des goûts, mais au final, tu obtiens du code C++ standard. Et ça, c'est inestimable..

Un autre aventage des signaux et propriétés de Qt: on peux en rajouter dans les objects sans casser la compatibilité binaire.

Rajouter des signaux sans rajouter des slots, ça à un intérêt un peu limité.

Quel est le problème avec moc ?

Il ne supporte pas les templates de QObject. Tu peux faire des contournements crades, mais ce sont des contournements crades, et tu peux pas avoir un slot/signal qui dépend ou est conditionné par un paramètre template. Au final, tu à quand même perdu une bonne partie des fonctionnalités de C++, et tu te retrouve avec un langage orienté objet pur aussi chiant que Java.

Et QObject est une grosse classe dieu qui fait tout, donc si tu a besoin qu'une partie des fonctionnalités (genre la gestion mémoire arriérée) qui ne nécessité pas de compiler du code généré, et bien tu te tappe quand même du code généré et toutes les limitations de moc.

L'"avantage" de wine sur windows dans ce cas est que l'attaque ne se propagera ni au système ni aux autres utilisteurs.

Par défaut, Wine ouvre l'accès à / Donc si ton utilisateur normal peut faire quelque chose, un virus sous Wine le pourra aussi.

C'est évident que c'est une diversion. Pendant que tu moulais sur LinuxFR pour raconter tout ça, ton système à été plonké, rootkité et les traces ont été supprimées par des vrais pirates chinois communistes du FBI.

Non, mais ça aide à comprendre les choix et arguments,

Et ça avance à quoi ? Au final tu à un logiciel qui ne fait pas ce que tu veux, ou qui le fait mal.

et ça permet d'en discuter.

Avec qui ? Upstream ? S'ils ont fait ces choix particuliers, c'est souvent en accord avec leurs propres idées, donc si tu leur expose ton problème, il vont rejeter la faute sur toi ou sur les autres logiciels que tu essaye de faire marcher avec le leur. Quand c'est pas le cas, ils vont attendre un patch. Et à ce moment là, si je trouve la motivation de corriger ça mais que le code source est trop horrible, ils pourront se brosser pour un patch correct: Si je le fait, ça sera crade et ça restera chez moi.

C'est toujours plus constructif que de dire « c'est pourri comme idée » (je ne dis pas ça pour toi).

Ça n'a rien de constructif, puisque justement, au final, ça reviens à dire « c'est pourri comme présupposé »

Et puis bon, la doc, quand il y en a, ne décrit pas souvent pourquoi un logiciel est fait comme ça, mais plutôt comment il est fait.