Batchyx a écrit 1261 commentaires

Tu veux dire, libre de ne pas utiliser la norme PC-BIOS, libre de ne pas te conformer à des trucs désuets de POSIX, libre de ne pas coder pour x86, libre te te coltiner la compatibilité PIC… Etc etc

Tout ça n'est certainement rien à coté du code général des impôts ou de tout ses équivalents européens. Et surtout, tes normes sont prévues pour des ordinateurs, alors que le code général des impôts est prévu pour des humains.

C'est pareil pour CSS: c'est prévu pour être utilisé sur le web par des implémentations indépendantes interchangeables avec une contrainte de compatibilité ascendante et descendante (il faut ignorer les attributs que l'on ne connaît pas) et qui doit avant tout être une fonctionnalité optionnelle. C'est un peu se flageller que de s'imposer ces contraintes là pour décrire des interfaces.

Une interface avec un layout optionnel ça te fait peut-être triper, mais moi j'aimerai bosser.

je ne comprends pas vraiment ta phrase.

Simple: une application Web est aussi lente qu'une application GTK2 sur une machine vielle de 8 ans.

Je vois mal comment écrire un langage déclaratif plus simple. Au lieu de troller dans le vide, je te saurais gré de faire des critiques construites et intéressantes

Sur la lisibilité du code :
- L'ordre des déclarations est important et peu introduire des bugs silencieux. Impossible de réorganiser du code ou de splitter ça dans plusieurs fichiers sans risquer d'introduire des bugs silencieux. C'est comme si on virait les déclaration en C et qu'on définissait toutes les fonctions avant de pouvoir les utiliser: c'est juste complètement hideux.
- L'absence totale de sémantique, et le fait que tout code avancé soit un amas de bidouilles: pour aligner des blocs horizontalement, utilisez float:left. Hein ?

Sur la simplicité technique, il n'y a même pas de commentaire à faire, il suffit de regarder les tests ACID 1 et 2 et de te demander combien de temps il te faudrai pour faire une implém qui respecte la norme.

Un jour, un maître programmeur interpella l'un de ses disciples:
- Si tu avais le choix entre programmer un logiciel de comptabilité et un noyau de système d'exploitation, lequel choisirai tu ?
- Le noyau de système d'exploitation, maître.
- Bien, et pourquoi ?
- Programmer un système d'exploitation soit bien plus complexe et plus difficile que de programmer un logiciel de comptabilité, mais j'aurai néanmoins le choix des concepts que je pourrai utiliser. Alors que programmer un logiciel de comptabilité va me forcer à apprendre et à respecter des concepts et des règles archaïques immuables sans aucun degré de liberté.
- C'est bien, je te laisse tranquille.

La performance en soi est inutile. Parfois, il vaut mieux privilégier la simplicité technique et la lisibilité du code tant que la fonctionnalité et l'expérience utilisateur n'est pas impactée.

Désolé, mais ce point là à été atteint depuis bien longtemps avec les navigateurs modernes. Ils en sont à se battre avec de l'accélération matérielle, des compilateurs JIT et du parallélisme, tout ça pour obtenir un résultat minable si on compare un quadruple cœur avec un navigateur et un pentium 4 avec une application native GTK2 (et je ne vais pas comparer avec d'autres toolkit, ça serait insultant).

Tu devrai leur dire d'arrêter leur "kikoo-driven developpment" et de se concentrer sur la simplicité technique et la lisibilité du code.

C'est avec ce genre de raisonnement qu'on se demande à quoi ça sert de faire un OS multitâche si les applications sont tellement lourdes qu'on ne peut pas en faire tourner deux en même temps.

Et sinon, parler de "simplicité technique et de lisibilité du code" avec CSS, comment dire …

C'est extrêmement gonflé de parler d'interpréter du CSS comme une "petite inefficacité", surtout pour un toolkit généraliste qui sera utilisé par plusieurs applications. Si c'est votre trip d'empêcher les gens de lancer trois programmes s'ils n'ont pas une machine dernier-cri, c'est pas le cas de tout le monde. Il y en a qui aimeraient juste pouvoir bosser.

Même LaTeX est plus rapide, en plus d'être plus puissant. Pourquoi ne pas l'utiliser ?

Et les performances ? C'est aussi lent qu'un navigateur ?

Ou sinon, il suffit juste d'avoir une batterie d'utilisateurs qui vont bien te faire chier quand ça marche plus. Cette technique fonctionne très bien avec le noyau Linux.

Moi aussi, mais ça ne m'empêche pas de citer l'Église d'Emacs. Je peux aussi citer le Culte de Vi si tu veux.

Comme déjà dis rien ne t'y oblige, mais ça n'est pas nouveau non plus. À une époque (et ça arrive encore) c'était des sujets intéressant qui étaient abordés (cinéma, cuisine, rasage,…) plutôt que d'immondes trolls.

À l'époque, surtout, s'il y avais eu un journal comme celui là, il y aurai au moins un commentaire qui mentionne l'église d'Emacs pour que ça dégénère en troll des éditeurs.

Ça fait déjà 80 commentaires, et je n'ai toujours pas vu un seul commentaire hors sujet. Ce n'est vraiment plus ce que c'était…

Il y a suffisamment de compétitions sportives en France (ou même dans le monde) pour en diffuser 24/24h, il y a même des chaînes sportives qui font ça.

Pas besoin de la pire de tous.

Malheureux ! Il est ILLÉGAL de publier des benchmarks sans l'autorisation écrite préalable de Microsoft ! Relis ta licence !

Le public n'a juste qu'à considérer que leurs produits soient plus lent…

chmod -R a-x,a+X

Il y a à peu près autant d'API dépréciée pour lire du son sous Windows et sous linux. Et DirectSound en fait partie, de ces API dépréciée, tout comme MCI et DirectMusic.

Le constructeur va te faire une ISO qui intègre toutes les cochonneries et qui te les installera dès que tu aura le dos tourné. Et il risque même de te le faire payer.

On peut déjà faire du firewall en espace utilisateur, donc du coup on peut utiliser un parseur natif plutôt que des regex, ça suffit largement pour des pauv' routeur Wifi. Mettre un moteur de regex dans le noyau, c'est vraiment overkill. Pourquoi ne pas y mettre le shell et grep, après tout ?

Au début de chaque script Debian, il y a, par exemple :

#!/bin/sh -e

### BEGIN INIT INFO
# Provides:          openvpn
# Required-Start:    $network $remote_fs $syslog
# Required-Stop:     $network $remote_fs $syslog
# Should-Start:      network-manager
# Should-Stop:       network-manager
# X-Start-Before:    $x-display-manager gdm kdm xdm wdm ldm sdm nodm
# X-Interactive:     true
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Openvpn VPN service
# Description: This script will start OpenVPN tunnels as specified
#              in /etc/default/openvpn and /etc/openvpn/*.conf
### END INIT INFO

# Original version by Robert Leslie
# <rob@mars.org>, edited by iwj and cs
# Modified for openvpn by Alberto Gonzalez Iniesta <agi@inittab.org>
# Modified for restarting / starting / stopping single tunnels by Richard Mueller <mueller@teamix.net>

Oui, ça fait 25 lignes. Il en manque 12 pour combler la moyenne …

grep ça devrait être dans le noyau, avec le serveur http.

Rigole pas trop, hein, y a un moteur d'expression rationnelle dans le noyau bidouillé d'OpenWRT…

Et quant le BIOS/EFI/OpenBoot sera enfin de nouveau rapide

Continue de rêver …

Toi t'as tout compris.

exec ne lance pas de processus, il mute le processus courant vers un autre. C'est très bien expliqué dans la page de manuel que tu file.

Et sinon, exécuter un processus, ce n'est pas simplement définir les arguments et les variables d'environnements, c'est aussi définir à quoi est reliée son entrée standard, sa sortie standard et sa sortie d'erreur, et aussi éviter de leaker des fd du parent. C'est aussi définir l'utilisateur effectif/réel/fs, avec exceptionnellement des autorisations/capabilities supplémentaires. Sans parler de ceux qui veulent des cgroups/rlimits/netns/autres …

Enfin bref, pour lancer un processus qui va tourner en fond (ou pas), sous Debian, il y a déjà start-stop-daemon. Il suffirait juste de l'étendre un peu pour qu'il gère des paramètres en plus, et qu'il puisse prendre des options par programmes dans un fichier de configuration séparé, pour pouvoir définir des nouveaux paramètres par défaut et des options forcées pour certains programmes… et quasiment tout le système bénéficiera déjà des améliorations.

Mais bon, améliorer l'existant, c'est tellement pas drôle …

Et bien tu sépare la fonctionnalité "lancer un processus" dans une bibliothèque/executable/autre bidule à part, et tu laisse init() et cron() utiliser cette fonctionnalité.

Et comme ça, tu pourra aussi permettre à d'autres logiciels de l'utiliser, du genre acpid ou mon logiciel buggé qui me rend bien des services mais que je n'ai pas publié.

C'est pourtant pas bien compliqué de faire du modulaire …

Ah ben voila, si on à pas besoin d'un gros merdier lourdingue plantogène, alors notre machine sert à rien … On dirait les windowsiens à venir dire que si ta machine n'est pas assez puissante pour faire tourner Windows, c'est que ta machine sert à rien.

Madame michu n'a pas besoin d'atd, n'a pas besoin d'inetd, les seules choses qui pourraient servir, c'est sethostname et consolekit (sur un portable), et je vois pas pourquoi ça devrai être dans le processus critique PID 1.

Et si il y a un million de personnes qui se font avoir, alors il faudra un million de personnes devant les tribunaux ?

Lenovo à déjà été condamné, je comprend pas pourquoi il faille encore aller au tribunal pour obtenir réparation, une simple notification que Lenovo ne respecte toujours pas la loi devrai suffire.

Ça désengorgerai aussi les tribunaux, parce que j'imagine qu'il n'y a pas que le racket de Lenovo qui à besoin d'être jugé plusieurs fois.

Sauf que si :

• J'ai pas besoin d'atd (d'ailleurs, à quoi ça sert ? il n'est même pas installé sur la plupart de mes systèmes, et quand il est installé, c'est parce que LSB en dépend),
• J'ai pas besoin d'inet (c'est simple : au démarrage, soit je lance aucun service réseau, soit j'en lance plein),
• J'ai pas besoin de sethostname (c'est pas comme si je changeait d'hostname tout les jours)
• et j'ai pas besoin de consolekit…

Alors systemd est un gros bloat qui implémente des fonctionnalités inutiles. Quel intérêt d'intégrer tout les inconvénients de tout les outils existants, quand la plupart ne sont pas installés/utiles par défaut ?

Donc quand tu est une grosse entreprise comme Valve, tu à accès qu'à un seul mec de chez AMD et NVidia. Tu crois pas qu'il y aura pas un peu de contention sur cette ressource rare qui n'a pas que ça à faire ?

Et je suis sûr qu'il y a des bugs simples que les mecs de Valve peuvent corriger tout seul.

Le problème c'est qu'une fois le programme totalement fini, tout refaire -> j'aurai pas le courage, alors que si je le fait quand le serveur n'est pas trop gros, c'est faisable.

Sinon, si tu n'a pas envie de tout réécrire même si tu en a envie, alors fait un truc modulaire et un backend pour Qt. Tu pourra faire le backend boost::asio plus tard, ou en même temps…

Linux va avoir du mal à suivre parce que les industriels veulent pas faire de drivers.

C'est pour ça que les développeurs de Valve travaillent avec … des développeurs de drivers libres.

Pourquoi des drivers libres ? Simple, parce qu'ils ont le source à portée de main, et un accès au mecs qui font le source). Leur jeu est lent comme la pluie ? Ils comprennent pas pourquoi activer une option de rien du tout plombe les performances par deux ? Ils comprennent pas pourquoi leurs shaders marchent pas ?
Ils peuvent savent pourquoi, et peuvent plus facilement contourner ou remédier les problèmes qu'ils ont. Alors qu'avec des drivers propriétaires, c'était plutôt de la devinette.

Enfin bref, il y a déjà des patches pour améliorer les perfs des drivers libres.

Alors, est ce qu'il vaut mieux un driver OpenGL libre, ou un driver Direct3D fermé ?

Franchement, boost sera peut-être un peu plus rapide que Qt si tu aime faire du C++ non-virtuel, mais ne t'attend pas à du ×2.
Si tu à des problèmes de performances, ils ne viendront certainement pas de ton système d'event ou de ton backend réseau, mais plutôt de tout ce qu'il y a entre les deux : parsage des paquets entrant, génération des paquets sortants, ou de ce qu'il y à après : logique du jeu, concurrence entre les clients, ou de tout ce qui est protocolaire (du genre, si dès qu'un client X fait une action, je l'envoie au 100 clients à proximité, et que 100 clients font des actions …)

Enfin bref, n'optimise que des programmes finis qui marchent. Si c'est pas lent, je vois pas pourquoi tu voudrai gagner 20% en passant d'une lib que tu connais à une lib que tu connais pas.

Mais si tu à juste envie d'apprendre boost, alors arrête de chercher des raisons bidons ;)