moi1392 a écrit 740 commentaires

Oui, mais après faut accepter d'avoir des boîtes noires dans son OS

Non, si tu n'en veux pas, ne les utilise pas, ça ne change rien à ta façon d'utiliser ton OS aujourd'hui !

L'auteur du journal à l'air de n'avoir pas de soucis particuliers avec ce point et accepte la boite noire, donc pas de soucis.

Au passage, si tu veux quand même utiliser ce genre de logiciel mais que le coté boite noire te gêne, il y a une solution intermédiaire qui serait de créer un utilisateur "jeux" qui ne sert qu'à cela, ça n'est pas la panacée et tu t'expose toujours au des attaques sur des failles de type escalade de privilège, cassage des mots de passe des autres utilisateurs par brute force, mais c'est toujours un peu mieux pour te protéger des techniques simple de tracking et d'espionnage de ta vie privée que de tout avoir sous le même compte.

ce serait d'avoir des jeux plus performants / plus jolis sous linux, voir de belles exclus

Perso, je suis un peu comme beaucoup de monde ici (à en lire les commentaires, je me trompe peut-être) et le fait qu'il y ait plus de parts de marché ne m'intéresse que dans la perspective que pour de logiciels soient portés et maintenus, que les pilotes soient de meilleur qualités, les périfériques tous supportés, …
Mais des parts de marché pour des parts de marché, je m'en fou un peu.

Et le fait que des personnes y passeraient pour des exclus ne me réjouis pas spécialement.
D'ailleurs je trouve cela con qu'il y ait des exclus. Qu'il y en ait parce que les gens développent dessus et n'aient pas le temps, les compétences pour porter les logiciel ailleurs, ça me parait normal et logique, mais que cela soit une exclus juste pour dire "on a la plus grosse" je trouve cela con.

"notre OS préféré" ???
Moi, c'est mon os préféré parce que je fais ce que j'en veux !
Parce que l'os ne me mets pas de bâtons dans les roues volontairement pour me limiter ou décide à ma place ce que est le mieux pour moi sans me laisser d'alternative.
Parce que je le trouve plus performant, pratique et simple d'utilisation (oui oui) que les autres.
Et aussi pour son coté communautaire, parce que je ne suis pas un gros égoïste de base, et que j'aime bien partager les trucs que je trouve cool et que tout le monde en profite.

Partant de là, je ne vois pas en quoi cela est gênant qu'il y ait ce genre de choses sur "mon OS préféré" et en quoi ça le rendrait moins bien sur les points que j'ai cité plus haut (j'en ai certainement oublié quelques uns au passage)

goto, c'est dépassé, les vrais codeurs utilisent comefrom maintenant !

http://c2.com/cgi/wiki?ComeFrom

Moi je trouve que c'est une affaire de goût. Est-ce une affaire de goût de savoir si c'est une affaire de goût ? :-)
Certains projet ne laisse pas passer un code avec des accolades en trop en review. (ex: Qt)
Et d'autres veulent des espaces, et d'autres veulent des tabs. Moi j'apelle ça une affaire de goût.

La différence entre espaces et tab, la taille des espaces, la position des accollades, si les parentheses sont collées ou pas à ce qu'elle contiennent, je classe également tout cela dans le style.

Mais le coup de ne pas mettre d'accolades lorsqu'il n'y a qu'une seule instruction avec un if, j'ai vraiment du mal.
C'est vrai que tous les arguments auquels je pense, peuvent être appliqués aux autres cas, mais quand même, ça crée une différence artificielle entre les cas 1 et plusieurs instructions, et je trouve que c'est beaucoup plus sujet à erreur que les autres.

Je ne veux pas défendre les « mauvaises pratiques ».
Je critique: « Oh une faille, c'est à cause des mauvaises pratiques, c'est vraiment des incompétants chez Apple ».
Ce serait plutôt du même accabit que « Il a eu un cancer, donc c'est un con (car les fumeurs sont des cons) », qui est assez irrespectueux en plus d'être fallacieux.

Moi je dirais, il a eu un cancer, c'est vraiment pas cool pour lui. Mais son mode de vie n'était vraiment pas très sain, du coup c'est quelque chose qui lui pendait au nez plus qu'à d'autres !

Sinon, la différence est que le type qui a un cancer, déjà c'est vraiment terrible pour lui et son entourage ! Mais ensuite, si cela viens de son tabagisme, c'est lui qui ne prenait pas soin de lui même, à moi il ne m'a rien fait et je n'ai pas de raisons de lui en vouloir ni de l'accabler plus !
Là, on parle de professionnels qui vendent un produit, sans dire que c'est des cons, dans ce cas c'est plutôt de nous qu'ils se moquent, car c'est nous qui en patissons en utilisant leur produits au final. Ça terni leur réputation et la confiance qu'on leur octroi. (même si elle frisait déjà le zéro pour ma part)

Après, il y a peut-être également une certaine frustration des gens ici car ils entendent souvent vanter apple et ses produits, alors ils se lâchent un peu…

On est d'accord. « plus difficlie », mais toujours possible. Donc l'existence d'une faille ne prouve pas que les pratiques sont mauvaises.

Ça n'est pas ce que j'ai dit, j'ai dit que cela réduisait les risques, et que statistiquement, je pense qu'il devrait y en avoir moins dans une grosse base de code si elle a été écrite en suivant de "bonnes pratiques" en terme de style mais aussi de technique de codage.
Après, entre ce que je pense et la réalité…
Pour reprendre l'analogie du cancer, il y a des gens qui ont un mode de vie très sain qui finissent malheuresement par en avoir un.

(c'est beau les trolls sur la cigarette en plein débat sécurité des produit apple !! je suis fier de moi pour le coup !)

non utilisation des accolades

Chacun ces goûts. On peux troller autant qu'on veut sur tab/espace, niveau d'indentation, acolade ou non.

En l'occurence, je ne trouve pas que le manque d'accolades soit une affaire de goût.
Le C l'autorise, mais je trouve que c'est une mauvaise pratique, en tout cas, je ne laisse en aucun cas passer un code comme cela en revue chez moi.

C'est le cas de quasiment toutes les faille ou bugs. Je ne prendrais pas cet example comme une peuve de mauvaise pratique. Des bugs arrivent dans tout les projets.

C'est vrai que ça arrive dans tous les projets, même ceux ayant de bonnes pratiques (on en parle un peu dans les commentaires précédents, parait-il)
Mais les mauvaises pratiques de code peuvent accentuer le problème et ajouter de nouvelles failles.
Donc le "ça arrive même à ceux qui codent bien" est du même accabi que lorsque j'entends des gens dire "il a eu un cancer à 45 ans et il ne fumait pas, alors je m'en fou, je peux fumer 3 paquets par jours !"

Peut être aussi que cette « erreur » est volontaire.

Ça c'est un autre problème. Mais là encore, avec de bonnes pratiques, une erreur volontaire est plus difficile à dissimuler.

Là tu parles d'interface graphiques, déjà branchées par dessus des abstractions (libc, c++, X11, wayland)

En l'occurence, systemd est la couche basse, directement branchée sur le noyau.
Or la principale différence entre un linux et un BSD est … le noyau, linux ou BSD.

Du coup je ne vois pas comment faire un truc portable directement au dessus du noyau, à moins de faire une lib d'abstraction intermédiaire ? qu'on appellerai libsystem, et par dessus, on aurait notre outil portable, que l'on pourrait appeler libbus !

Je tiens un truc là je crois…

qui soient légers et portable, le tout bien intégré au système ?

Je crois qu'il y a un léger soucis de compatibilité entre ces deux points.

J'ai la solution !!
Il suffit de faire une boite de dialogue de mot de passes qui esquive quand on veut y entrer son mot de passe :D
Du coup, quand ce sera trop facile pour les autres, l'utilisateur se doutera forcément de quelque chose !

Faut penser à activer les webcam pour filmer la tête des utilisateurs au passage :D

Le soucis c'est que tu compares avec ce qui t'arrange pour dire que cela ne te conviens pas.

Je pourrais aussi dire que je souhaites un système qui contrôle l'accès à mes fichiers en fonction de l'utilisateur et des droits du fichier.

Lequel des deux énoncés est plus proche du cas compositeur wayland ?

Moi je trouve l'article très intéressant.
Et je trouve cela correcte qu'à partir du moment où le rendu à l'écran soit du ressort du compositeur, et que l'on décide d'en restrindre l'accès à l'application, et bien que cette restriction soit complètement gerée par le compositeur.

Pour l'analogie avec l'accès à un fichier, je dirais aussi que les cas d'utilisation sont très différents !
L'utilisation de ton système étant très dépendante de l'accès à des fichiers, il est difficile d'en restreindre l'accès arbitrairement sans remettre en cause énormément de choses.
Pourtant, c'est bien ce qui est en train de se faire avec les exécutions dans des bac à sable sur les systèmes mobiles entre autre qui n'ont pas ce lourd historique applicatif à gerer !
Et du coup ça n'est peut-être pas une si mauvaise idée que cela, juste qu'elle est vraiment trop difficilement applicable à l'existant.
Mais vu que wayland et ses compositeur sont nouveaux (rien à voir avec le driver nvidia…), autant essayer d'améliorer les choses là où c'est possible sans remettre en cause trop d'applications et de cas d'utilisation existants.

Si tu commences, je ne pense pas que cela soit le meilleur livre pour toi.

Je le trouve vraiment très bon, il me semble (mais je dis peut-être des bétises, car je l'ai lu en 2004…) que tout ce qu'il contient est compatible C++98, mais pour autant il y expose des techniques très intéressantes (au niveau implémentation de certains design pattern, et aussi certaines techniques algorithmiques) que j'utilise encore aujourd'hui dans mon travail.
Je le conseillerai à quelqu'un qui connais et a déjà un peu programmé en C++ (au moins un an, avec un petit background en programmation en général, et pourquoi pas avec lu "Design Patterns" avant)

Je ne connais pas beaucoup de bons livres pour débutant, mais je suis sûr que d'autres sauront te renseigner.

Tout se fait à la compilation plutôt qu'à l'exécution.

C'est le constexpr qui permet cela, tu peux sans soucis écrire :

auto total = s(1) + min(12) + h(3);

après je suis d'accord que cela ajoute un peu de lisibilité à certains codes, et aussi cela à l'avantage de proposer un namespace vide, donc pas de risque de collision avec un suffixe "h" qui est déjà défini par l'utilisateur.

Mais ce qui est nouveau dans ton cas d'utilisation, c'est le constexpr qui permet l'évaluation à la compilation.

J'ai lu avec intérêt ton nouveau message, et en ce qui concerne l'utilisation de std::function et std::bind, j'ai plus l'impression qu'il s'agit d'aides pour simplifier l'écriture de functors.

J'utilise déjà des functors sur des méthodes de classe depuis 2005 dans une version très proche (puisqu'inspirée) du livre "Modern C++ Design" de Andrei Alexandrescu.
Qui est d'ailleurs un excellent livre que je conseille à tous ceux qui veulent s'initier à la programmation générique en C++.

Pour ce qui est des littéraux, je ne m'étais jamais penché sur cette spec, et je trouve ça sympa, mais mais je me demande quelle est la différence entre cela et utiliser une fonction normale.
J'ai peut-être raté un truc mais j'ai l'impression que ça n'apporte qu'une nouvelle syntaxe sur des fonctionnalités déjà existantes.

Par contre, les 14 types de containers suivant que tu gères un ensemble ordonné ou non, itérable ou pas, dans un sens ou dans les deux, ça c'est sur que c'est hyper utile en pratique !

heeuuu… les conteneurs sont tout de même le support de base de l'algorithmique…
Combien d'algo chez nous j'ai "optimisé" juste en changeant le conteneur utilisé parce que le "bon" développeur qui l'a écrit ne voyait certainement pas l'intérêt de 14 conteneurs différents…

Tu peux déjà tenter de créer un nouvel utilisateur, juste pour voir si cela règle tes soucis.
Si c'est le cas, au lieu de faire une installation qui t'effacera toutes tes préférences, tu peux te contenter de ne perdre que la config de KDE en supprimant le dossier ~/.kde

Cette phrase m'a paru bizarre : "il se permet donc d'écrire des blocs moins prioritaire, si c'est sur son chemin."

De ce que j'en avais compris à l'époque des disques dur (avec de vrais morceaux de disque à l'intérieur), quand on parlais de "sur le chemin", il s'agit du chemin de la tête de lecture.
Mais puisque qu'un ssd n'a plus de tête de lecture qui se promène, cela ne correspond plus à rien.

Il y a un truc que je n'ai pas compris dans l'histoire ?

C'est un problème mal compris de l'offre et de la demande: certains comme Zenitram pensent que s'il y a une demande, une offre va magiquement apparaître.

Je suis d'accord, mais dans le cas présent c'est un peu différent, les offres étaient déjà là.
Et je pense (et je peux me tromper, c'est bien là le point de désaccord) que si le pipe fixe avant encore une demande raisonnable (= siffisament forte), quelques moteurs existant y seraient resté.

Après, le point que tu soulignes à l'air d'être vrai aussi. Quand la demande est faible et qu'elle va en se réduisant, en dessous d'une certaine limite, comme l'offre disparait, cela "force" un peu à se mettre à niveau si on veut utiliser ce qui sort.

Mais prends l'exemple de kwin, ils on gardé jusqu'à présent (à voir pour la version 5) du code de gestion de pipe fixe pour la composition. Ils auraient pu le virer en disant qu'il marche aussi sans, et que les gens ayant de vieille carte n'ont qu'à pas utiliser d'effets.
Donc s'il y a une demande assez forte pour quelque chose de déjà là, souvent cela reste.

nanim ?

Et la puissance implique aussi un marché! Dans les conseils donnés aux indies, on retrouve souvent faites un jeu pour des machines peu puissantes, ça représente beaucoup de clients.

Peut-être, mais quand tu développe ton cadriciel, tu le fais pour les jeux qui ont besoin de peu de puissance ET ce qui en veulent plus.
après, il y a peut-être un marché pour des cadriciel de rendu 3D pour des machines à pipe fixe, mais j'ai l'impression qu'il est très faible, sinon ils seraient très utilisés, surtout dans du logiciel libre ou la maintenant coûte beaucoup moins cher que l'évolution/la réécriture.
S'ils évoluent tous et que (peu de) personne ne conserve les anciennes versions, c'est que la demande doit être vraiment très faible, tu ne penses pas ?
Après, tu fais parti de cette demande, et je comprends que ça te fasse chier, ça m'embêterai sûrement aussi.

Enfin, aujourd'hui, machine peu puissante != pipe fixe ou programmable.
On considère que les pipes sont tous programmables et que les puces graphiques peu puissantes sont celles qui on peu de coeurs de calcul, peu de mémoire et une fréquence basse.

Ce qui m'embête dans cette histoire, c'est qu'on exclue des PC, pas pour des raisons de puissance (un GPU à pipeline fixe peut envoyer du polygones par seconde), mais de technologie.

Pour un cadriciel, la technologie implique la puissance, car tu ne sais pas dans quel contexte il va être utilisé.

C'est vrai que c'est dommage d'abandonner les vieilles cartes, et quand tu codes un nouveau truc qui n'as pas forcément besoin de beaucoup de puissance, tu peux te contenter d'OpenGL 1.x

Mais d'un autre coté, je ne blâme pas les dev, cela offre tellement de souplesse et ouvre tellement de possibilités de jouer avec le pipe de rendu, que je comprends qu'on y passe à un moment.
Moi même, dès que j'ai envie de faire un truc un poil pas simple, si je peux, je passe par des shader.

Tu peux aussi voir le coût en maintenance. Ajouter des fonctionnalités sur un pipe fixe, souvent ça complexifie beaucoup, ou alors il faut revoir en profondeur l'architecture de ton moteur.
Coté shader, dès fois ça se fait en une demi journée !

Ben moi le X, je préfère quand c'est tout nu !

Argument difficile à contrer.

Pas vraiment non… une arme à feu est faite pour tuer !
Pas un logiciel (en tous cas, pas un logiciel de compta…) ni un marteau, ni une voiture.

Après, effectivement, on peut tuer quelqu'un avec un marteau ou une voiture (ou un logiciel de compta pour chuck norris)

Mais vendre un objet dont le but est de tuer en disant que c'est pas la faute de cet objet mais des gens qui l'utilisent, et donc que sa vente ne pose pas de soucis en elle même, c'est un peu (sarcasme) se moquer du monde quand même…

Pour rebondir sur cette phrase :

Des logiciels qui disparaissent, ça arrive. Mais des logiciels qui s'ouvrent, se libèrent et deviennent très utilisés voire incontournables, cela est déjà arrivé. Winamp pourrait suivre le chemin tracé par, entre autres, Mozilla et Blender.

Je pense que Mozilla et Blender ont comblé de gros vides à leur époque, alors que là, des logiciels de lecture multimédia de qualité, il y en a déjà pas mal, et j'ai du mal à imaginer que winamp puisse remplacer vlc ou mplayer au moins dans mon utilisation quotidienne.

La langue que je préfère à l'écoute, le bon allemand, je trouve quel sonne bien à l'oreille.

Comment dire…
Les fauves sont souvent dressés en anglais et en allemand !
L'anglais parce que les mots sont courts et simple, plus facile à mémoriser et à comprendre, et l'allemand parce que les sonorités sont plus sèches et rudes, cela donne plus d'autorité !

Source, un reportage arte, mais on trouve aussi quelques références la dessus sur le web :
http://www.lefigaro.fr/cinema/2012/12/21/03002-20121221ARTFIG00572-l-homme-qui-murmure-a-l-oreille-des-fauves.php
http://www.lepetitnicois.fr/article/fr%C3%A9d%C3%A9ric-edelstein-un-lion-parmi-les-lions-46889.html

L'allemand, la langue qui fait peur aux lion…

ça dépends, si c'est 99% du driver ou 99% du code du driver qui est compatible, au final, aucun ne marche…