Batchyx a écrit 1261 commentaires

Ça existe (Sysinternals), mais ça trace toutes les applications et c'est trop lent.

Ou POSIX/X11 (ou POSIX/FHS/Linux, ou POSIX/FHS/X11 …)

Je comprend pas pourquoi le mot "POSIX" ou "X11" n'appairait pas dans la discussion, alors que c'est pourtant ce qui manque pour qu'on puisse utiliser des applications bien sous android.

Tu trouves cela normal qu'un système de log soit lié au noyau ?

Tu fait comment en userspace pour logger la stacktrace quand ton noyau vautre totalement et panique ?

Note que ce système de log ne s'applique qu'au noyau et pas à Java ou systemd.

Ces versions sont épurées de toutes les publicités et placement de produits ?

Le noyau de Windows est clairement à blamer pour ses pilotes, tout comme on pourrai blamer le noyau Linux. Mais est ce qu'on peut reprocher la qualité des pilotes à Windows 7 AiO ou au autres distributions de Windows ?

Ok, 3.10, c'est la dernière stable. Mais en temps noyau, il y a déjà des patches en plus dans les 3.11-rc (qui ont été intégré pendant la période de merge après la sortie de 3.10) et les patches déjà préparés pour la période de merge qui ira après 3.11 ;)

Après pour débuger, y a des moyens d'avoir plein d'information de debug pas forcement utiles ou compréhensibles… genre créer une interface en mode monitor en parallèle (iw dev wlan0 interface add mon0 type monitor) et tout capturer quand ça marche pas, ou alors mettre 65535 dans /sys/kernel/debug/ieee80211/phyX/ath9k/debug (c'est bien ath9k que t'utilise ?) et voir ton dmesg se faire flooder…

De ce que tu en dit, ça à encore un sens de faire du montage linéaire lorsque tu doit diffuser la vidéo en temps réel, de la même manière qu'il y a les éditeurs de textes et les éditeurs de flux de texte.

Mais dans le contexte, je crois qu'on parle de la distro, et on peut difficilement reprocher à une distro la qualité des pilotes.

Non, mais on peut reprocher à une distro d'utiliser des noyaux trop anciens, et donc de ne pas supporter correctement tout les matériels récents. Avoir 3.2 en stable, c'est peut-être toujours mieux que 2.6.35, mais des patches ont coulés sous les ponts depuis, et tous ne sont pas backportés.

(Moi j'ai une Atheros en PCI, et franchement c'est la loterie à chaque démarrage! Je ne sais même pas comment rapporter le bug:
Procédure pour reproduire:
-déconnecter la carte
-lancer le client DHCP: la connexion s'établira dans un laps de temps totalement imprévisible compris entre quelques secondes et plusieurs jours ; oui, 2 jours, le record! normalement je reboote entre deux plein d'espoir, peut-être que je peux faire mieux!!)

(t'a essayé avec un noyau récent ? sinon, faut augmenter le niveau de verbosité du noyau et/ou de wpasupplicant)

Si c'était bien fait, il n'aurai pas besoin de télécharger le monde et répliquer le contenu de mon répertoire /usr/share/java déjà bien rempli par Debian.

Ça plus le fait que ça soit du Java quoi…

En l'occurrence, lorsque c'est le cas, beaucoup de programmes de partitionnements comme fdisk et parted vont te le signaler. Pareil si tu a des partoches qui s'overlappent ou qui dépassent la taille du disque.

Mais ce n'était pas mon cas.

Je ne pense pas que cela fragmentera l'écosystème C#. C#/Qt sera un langage à part entière qui aura la particularité d'avoir la même syntaxe que le langage C#. Mais les binaires C# ne seront a priori pas compatible avec les binaires C#/Qt et vice-versa, pour des raisons de portabilité.

Donc tu fragmente l'écosystème C# en deux, CQFD.

Si jamais quelqu'un veut écrire une bibliothèque en C#, il va devoir choisir entre le C# normalisé et le C# avec une bibliothèque non standard, sachant que quelqu'un qui utilise le C# normalisé ne pourra pas utiliser du code qui viens de l'autre écosystème et inversement.

Sur ce point, ce projet se différencie donc de Qt qui était une bibliothèque pour C++ utilisable avec d'autres bibiothèques C++. Là, il s'agit de créer un nouvel écosystème.

Qt n'est pas qu'une bibliothèque, c'est aussi un générateur de code et un système de build. Mais même sur sa partie bibliothèque, il réimplémente toute la bibliothèque standard C++ en moins bien, et si tu veux utiliser une bibliothèque qui utilise Qt dans du code qui utilise majoritairement la bibliothèque standard (ou inversement), ce n'est certes pas impossible de mixer les deux, mais en pratique c'est beaucoup de glue chiante à écrire pour rien, qui peut casser facilement si tu ne prend pas en compte les différences qu'ont les deux environnements sur les namespaces, les exceptions et la gestion de la mémoire.

C'est assez pour te dissuader de mixer les deux, et à la place, réimplémenter la fonctionnalité de la bibliothèque dans ton coin. D'ou une fragmentation entre du C++ standard et du C++/Qt.

Tu va fragmenter l'écosystème C# de la même manière que Qt à déjà fragmenté l'écosystème C++ en refusant d'utiliser ou de migrer vers la bibliothèque standard et normalisée du langage.

Même si sur le coup, ça sera toujours mieux d'avoir une API Qt orienté objet dans un langage purement orienté objet comme C# plutôt que d'avoir une API purement orienté objet dans un langage qui n'a pas été fait pour, et qui du coup utilise le langage d'une manière totalement non-naturelle en jetant en l'air des années de bonnes pratiques.

Je ne sais pas pour le C++, mais pour le C tu as cc qui est au moins un standard de fait sur les unix-like.

Mais pas sous Windows. Or si il y a bien un OS qui à besoin d'un gestionnaire de dépendance de toute urgence, c'est bien cet OS (quoi que j'en pense). Le reste a déjà des gestionnaire de paquets…

La différence avec apt c'est qu'il peut se charger lui même de mettre tout ça dans un dossier à toi et choisir les directive du compilateur pour les inclures (une énorme partie existe déjà dans CMake).

Debian ça n'est pas qu'apt, il y a aussi toute la gestion de la compilation et de la cross compilation des paquets, en plus de l'infrastructure qui permet de compiler tout ça automatiquement.

D'ailleurs, Debian a (avait ?) discuté de la possibilité d'installer des paquets en tant qu'utilisateur. Comme quoi les problématiques ne sont pas aussi éloignées que tu ne le crois.

Dans ce commentaire tu dis que le C++ s'il en existait un pour du C++ ça ferrait double emplois avec le gestionnaire de paquet.

Dans le précédent aussi.

Alors que dans les précédent tu disais que gem c'est de la merde fait pour les bouts de code fait à l'arrache.

Je n'ai jamais dit ça. L'autre reproche principal que je faisais concerne la sécurité de certains dépôts de ces systèmes de dépendances, ou les utilisateurs exécutent automatiquement du code uploadable par n'importe qui sans aucune vérification ni cloisonnement.

Même si pour le coup, avec un langage aussi expert-friendly que C++, on va forcement avoir des problème de qualité des codes uploadés.

Mes trois partitions étaient toutes primaires dans cet ordre:

• Vfat petite
• ext3 (ou 2 ou 4, je sais plus)
• vfat grosse.

Le gestionnaire de partitions de Windows voyait les trois, mais il ne semblait pas reconnaître que la troisième était du FAT32 des familles.

Debian à toute une infrastructure à base de logiciels libres, disponibles (et packagés pour Debian) pour permettre de construire des paquets dans des environnements isolés pour éviter qu'un rigolo te lance une backdoor lors d'un ./configure. Ils ne sont peut-être pas parfaits et entièrement sécurisés, mais c'est déjà bien mieux que certains gestionnaires de dépendances ou c'est totalement open bar. Par contre, ils ne te protégeront pas contre la compilation de code malveillant (ou de code tout simplement pourri).

C++ n'est rien d'autre qu'une spécification sur le langage. Il n'y a pas d'implémentation de référence ou quoi que ce soit. Il n'y a pas de moyen standard pour compiler et lancer un logiciel. Le langage ne dicte par exemple pas que ton système doit supporter les bibliothèques dynamiques, et tu a des systèmes ou ce n'est pas le cas. Tu à des systèmes ou ton implémentation de la norme C++ est incomplète (pas d'exception, par exemple).

À partir de ce moment là, tu à un gros problème à gérer, rien que pour compiler et lancer un logiciel sans dépendances. Il te faut un système de build bloaté pour supporter plusieurs systèmes, plusieurs compilos (avec des bugs divers et variés) les architectures éxotiques sans virgule flottante matérielle, les bibliothèques standard avec plus ou moins de lacunes (parfois causées simplement par les limitations matérielles), la cross compilation (greuh), et ne parlons pas des options de compilation.

En fait, tu te retrouve avec tout les problèmes qu'ont les systèmes de builds, les distributions et les gestionnaires de paquets avec les logiciels C depuis 20 ans. Et à ce que je sache, personne n'a pour l'instant résolu le problème pour Windows, ou il y a encore plus de segmentation avec les compilos Visual C++ incompatibles entre eux.

Alors oui, quand je dit que ça fait double emploi avec $PACKAGE_MANAGER, c'est que c'est vraiment le cas, puisque ça en est un.

La seule vraie solution à ce problème, ça serait une meta distribution générique qui s'intègre avec tout les OS qui existent. Or on sais très bien que ça va poser encore plus de problème que ça va n'en résoudre.

apt-get build-dep $PROJECT
apt-get --compile source $PROJECT

J'ai le même problème avec une carte SD avec trois partitions dont deux VFAT. La première est reconnue partout, mais la deuxième n'est pas reconnue par Windows 7… pourtant les deux ont le même type 0xc, mais pas la même taille, la deuxième faisant 10GB alors que la première devait faire 200MB.

(et oui, j'ai essayé fsck.vfat, et ça n'a rien changé)

Mais bon c'est pas grave, c'est pas moi qui a le windows …

Tu veux dire les machins qui font double/triple emploi avec le gestionnaire de paquets de ta distribution et des gestionnaires customs existants (genre pkg-config et compagnie) ?

À moins que tu parle des dépôts publics insécurisés ou tout le monde peut publier des backdoorées et télécharger sans aucune authentification de la somme de contrôle, voire sans somme de contrôle du tout ?

Sérieusement, ça apporte quoi par rapport à des projets éparpillés sur le net, mis à part de la centralisation ?

Mais je me demande si d'autres services ne seraient pas vulnérables ainsi, ou si ce n'est pas qu'un élément d'une attaque plus complexe.

Il me semble que rsyslog pourrai être affecté, puisqu'il ne se fie qu'au résolutions DNS inverses.
Utiliser TCP en localhost est pas courant, mais ça se fait lorsqu'on veut passer du syslog dans un forwarder TCP qui fait passer ça dans un tunnel sécurisé…

Car si tu tapes uniquement des mots clés dans la barre d'adresse, il fera une recherche dans ton moteur de recherché affecté comme pour la barre de recherche.

Sauf que le navigateur est bien souvent incapable de faire la différence entre un mot clef seul et une adresse sans protocole.

Quand je tape "monserveur" dans la barre d'adresse, je veux que ça soit reconnu comme un nom d'hôte auquel il faut essayer le suffixe par défaut pour qu'au final ça aille sur http://monserveur.mon.suffixe.par.default.example.nl/. Si j'essaye ça avec Chromium, ça me fait une recherche idiote sur monserveur sur google. Génial.

Et ce n'est pas comme si ça n'était pas utilisé en entreprise, par des madames michus qui ne connaissent même pas le suffixe DNS que le navigateur utilise (et encore moins ce qu'est un suffixe DNS), mais qui savent que si ils tapent "wiki" ou "search", ils tombent sur le wiki ou le moteur de recherche de l'entreprise.

Le pire étant sur un réseau déconnecté d'Internet ou on utilise un TLD maison, et ou même en tapant monserveur.tldmaison, certains navigateurs tentent de faire une recherche sur google sans aucune vérification au préalable. Recherche qui bien entendu foire lamentablement, donc le navigateur affiche une page d'erreur générique "impossible de contacter le site web" (point bonus quand il ne précise pas lequel, oui ça existe, surtout chez les navigateurs mobiles), alors que monserveur.tldmaison existe bel et bien. La solution étant de taper http://monserveur ou http://monserveur.tldmaison, ce qui est chiant à taper sur un desktop et super chiant sur un mobile.

class ClasseMere {
/* ... */
    ClasseMere() {}
/* ... */
    AutreClasse &m_attribut;
};

En C++, les références sont immuables et doivent donc être obligatoirement initialisées. Vu que ton constructeur n'initialise rien, il est invalide. Ta classe ne peut donc pas être construite, donc elle est inutilisable.

Vu que les héritiers ont aussi besoin de construire la classe de base, les héritiers sont inutilisables aussi.

Si je comprends bien l'erreur que m'affiche QtCreator, le constructeur bogue parce que ClasseFille n'a pas l'attribut m_attribut.

Non, l'erreur c'est que ClasseFille n'a pas de champ m_attribut. Un champ et un attribut (on parle plutôt de membre en C++), ce n'est pas la même chose.

ClasseFille n'a qu'un seul champ: ClasseMere (qui elle, contient un champ m_attribut). Si ClasseFille avait aussi un attribut m_coucou, alors ClasseFille aurai deux champs: ClasseMere et m_coucou.

Un constructeur de classe ne peut initialiser que ses propres champs. Donc ClasseMere doit initialiser m_attribut et ClasseFille doit initialiser ClasseMere, en lui passant la référence en paramètre, par exemple.

Je crois que tu n'a pas compris de quoi on parle.

Si tu veux faire un mesh autonome, il faut pouvoir faire ça au minimum, et sans dépendre d'un serveur externe (puisqu'il y en a pas) :

• De quoi se connecter à n'importe quoi avec la topologie qu'on veut

  • Le plus simple, c'est de pouvoir mettre une carte wifi en mode ad-hoc (cas 1) ou 802.11s (cas 2).
  • Sinon, on peut bidouiller pour toujours être AP et créer des interfaces virtuelles dynamiquement pour le reste (cas 3)

• De quoi automatiquement découvrir et se connecter à ses voisins directs.

  • Avec (1), (2) c'est déjà fait au niveau MAC.
  • Avec (3) il faut un démon qui demande à la carte de scanner régulièrement et récupérer les résultats, et créer dynamiquement des stations virtuelles pour se connecter aux voisins.

• De quoi adresser ses voisins directs.

  • Si tu peux récupérer la liste des adresses MAC de tes voisins à partir du noyau et que tu peux utiliser des socket paquets, alors c'est bon.
  • Sinon, il faut t'auto-attribuer une adresse IP et faire de la découverte avec du multicast/broadcast UDP. (3) peut s'en sortir autrement.

• De quoi communiquer avec ses voisins directs.

  • Si tu fait du socket paquets, alors tu n'a pas de problème.
  • Si tu veux de l'IP unicast, il faut pouvoir changer la table de routage dynamiquement et pouvoir se connecter à une adresse IP donnée et écouter les connexions des autres.
  • Au pire, faire du broadcast tout le temps.

Maintenant, si tu est dans le cas (2), alors tu à déjà un mesh. Sinon, tu peux y ajouter un protocole de routage et un relayeur de message et tu pourra former un réseau mesh. Et je dit bien "un" réseau mesh. Si tu veux pouvoir joindre un réseau mesh Serval, t'a intérêt à pouvoir causer le même proto qu'eux. Quelque chose me dit que ce n'est pas du TCP relayé à la main.

Maintenant ou bien tu m'explique comment tu fait ça avec l'API PeerConnection, ou bien tu nous avoue clairement que FFOS ne permet pas de faire ça.

Celui là utilise une grammaire sans contexte écrite à la main et non pas de la déduction de chaîne de markov. Les mecs ont bien du s'amuser, mais à mon avis, au final ça rend les articles générés plus crédibles puisque les constructions de phrases sont toujours correctes et la grammaire est remplie de constructions de phrases percutantes qui buzzent.

Bien sur que si ça a du sens de crypter. Faut arrêter avec ces affirmation toutes faites de la part de linguistes qui ne connaissent rien en informatique. Quand tu obtient la capacité d'insérer ou de remplacer des données dans un flux chiffé, tu peux en faire des dégâts. Ce genre d'attaque a existé, par exemple avec WEP qui permettait de retrouver le keystream si tu pouvait injecter des paquets depuis l'éxterieur. Ensuite, tu pouvait crypter les paquets que tu voulait, et en décrypter certains… sans avoir la clef !