reno a écrit 3879 commentaires

  • [^] # Re: A noter: la release a été faite par Pekka Paalanen.

    Posté par  . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 6.

    Et bien Wayland étant un mot un peu 'fourre tout', la réponse est forcément 'ça dépend' (Ça se voit que je suis Normand?).
    Il me semble que tu peux utiliser Wayland dans l'embarqué dès maintenant, pour ce qui est des desktops 'classique', là il faut reconstruire un environnement au dessus de wayland (xdg-shell est son doux nom) autrement une appli Qt/Wayland ne pourra pas vraiment fonctionner avec un compositeur Wayland/Gnome, c'est cette partie là qui est en cours de finalisation..

    Personnellement je pense pour fin 2015 pour Wayland en production/stable pour le bureau, après ça peut dépendre du DE: il me semble que Gnome est plus avancé que KDE sur le sujet.

  • # A noter: la release a été faite par Pekka Paalanen.

    Posté par  . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 6.

    Avant c'était Kristian Høgsberg (l'initiateur du projet) qui faisait les release mais apparemment il ne travaille plus sur Wayland pour le moment.

  • [^] # Re: Tant de changements pour une version mineure

    Posté par  . En réponse à la dépêche OCaml 4.02. Évalué à 2.

    Hum, avec Python3 ça n'est plus vrai..

  • [^] # Re: Intéressant tes critiques sur le shell

    Posté par  . En réponse au journal Sur systemd, btrfs & co. Évalué à 6.

    C'est peut-être parce que ps n'est pas fait

    C'est là le problème, tu ne peux pas vraiment avoir une sortie texte à la fois adaptée pour un être humain et pour un script, donc le 'tout est texte' te force en fait soit à faire des compromis douloureux soit à multiplier les outils..

    pour ça encore que ça ne me semble pas bien difficile en précisant qu'on ne veut pas d'en-tête et qu'on veut des colonnes bien précises.

    Et bien ça dépend de ce dont tu as besoin, mais typiquement tu as besoin du nom/de la ligne de commande et là c'est le drame: les noms de processus avec des espaces, les caractères non-ASCII, ça semble marcher sauf quand..

  • # Intéressant tes critiques sur le shell

    Posté par  . En réponse au journal Sur systemd, btrfs & co. Évalué à 5.

    Mais note quand même qu'il y a une différence entre le concept d'un langage de shell et les implémentations.
    Pour le concept, je pense que c'est une très bonne idée: même Microsoft l'a (finalement) adopté!

    Pour ce qui est des implémentations, effectivement le bash c'est très très nul comme langage, mais tu peux utiliser scsh (un 'shell' en Scheme), là tu as un bon langage mais avec une syntaxe pas adaptée: le plus dur c'est d'avoir un bon langage ET une syntaxe adapté a la ligne de commande..

    Pour ce qui est des pipes, le concept de pipe est très puissant mais l'implémentation Unix ou tout est 'texte' par rapport à PowerShell là je ne suis pas convaincu (1), après le problème dans passer des objets est qu'il faut se mettre d'accord sur une sérialisation unique des objets et pour se mettre d'accord sur quelque chose dans le monde Unix, on n'est pas très fort..

    1: essayer de parser la sortie de 'ps' de manière fiable et on en reparle de la soi-disant supériorité du texte comme sérialisation.

  • # Ouhahou

    Posté par  . En réponse au journal Total s'appuie sur un super-calculateur tournant sous Linux !. Évalué à 10.

    Ouahou, un supercalculateur sous Linux, quelle grande nouvelle!!
    Le top 500 des supercalculateurs n'est pas du tout quasiment intégralement sous Linux depuis plusieurs années..

  • [^] # Re: Séparateur de chiffre

    Posté par  . En réponse au journal C++14. Évalué à 3.

    +1 les identifiants hexadécimal fichent le bazar en effet.

    Bon bah va pour le ' c'est moche, mais c'est mieux que rien!

  • # Pas simple la sécurité

    Posté par  . En réponse au journal Happening de données exposées, fap fap fap, cloud et protection. Évalué à 2.

    Note que même quand il y aura une protection contre le bruteforcing de mot de passe (ce qui est tout de même le minimum!), il y aura des fansidiots qui loueront un botnet pour continuer a essayer de bruteforcer le mot de passe des célébrités.

    Et toi, ami lecteur [cut] comment fais tu pour conseiller à un non geek absolu de protéger ses données dans le "Cloud" ?

    Pas la moindre idée! Être anonyme ça réduis les risques mais..

  • [^] # Re: Citation needed

    Posté par  . En réponse au journal Forum sur la gouvernance de l'Internet. Évalué à 1.

    alors que c'est sans doute la France qui lui a vendu développé son matos de DPI,

    "alors que ce sont doute la Francedes entreprises Françaises qui lui ont vendu et développé son matos de DPI"

    Merci de ne pas faire l'amalgame.
    Ou alors tu insinue que c'est le gouvernement Français qui a vendu au gouvernement Turque le matos de DPI?

  • [^] # Re: Séparateur de chiffre

    Posté par  . En réponse au journal C++14. Évalué à 3.

    Ah, oui j'avais oublié..

    Donc pour qu'une règle simple fonctionne il faudrait interdire de commencer les variables par des _, ça ne parait pas une mauvaise restriction, mais évidemment ça n'est pas compatible avec l'historique et pour un langage autre que le C/C++ ça créerait des problèmes pour l’interopérabilité avec le C..

  • [^] # Re: Séparateur de chiffre

    Posté par  . En réponse au journal C++14. Évalué à 3.

    Et bien personnellement j'aurai pris le choix suivant: le _ est ignoré DANS et IMMÉDIATEMENT APRÈS un nombre donc
    123_456 est interprété comme 123456, 123456_ aussi.
    123_42_m est équivalent à 42m (literal m)
    mais abc_def est toujours interprété comme abc_def.

    Il y a peut être un problème avec cette règle mais je ne le vois pas..

    Le seule défaut que je vois est que ça qui implique qu'on ne pourrait pas avoir d'user definied literal commençant par un _ mais bon déjà il me semble que les noms commençant par un _ sont "réservé", non?

  • [^] # Re: Séparateur de chiffre

    Posté par  . En réponse au journal C++14. Évalué à 0.

    le _ fait partie du nom

    Merci, je ne savais pas, encore un truc pas très bien fichu en C++ (à mon avis), ils cumulent..

  • [^] # Re: Séparateur de chiffre

    Posté par  . En réponse au journal C++14. Évalué à 2.

    Oui, ça ne parait pas plus ambigu que la "surcharge" des ', d'autant plus que je pense que les "user defined literal" ne doivent pas pouvoir commencer par un chiffre (comme tout les identificants en C/C++).

    Le _ étant déjà utilisé comme séparateur pour les nombres dans pleins de langages, c'est vraiment à se demander si le comité n'a pas sélectionner le ' pour faire ch… le mondel'originalité?

  • [^] # Sauf que les contructeurs n'en ont rien à faire de la norme

    Posté par  . En réponse au journal UEFI, je chie ton nom. Évalué à 10.

    Le plus gros problème est que la norme est beaucoup trop permissive.

    Sauf que les constructeurs n'en ont rien à faire de la norme, ce qui compte pour eux, c'est que ça démarre Windows, point (autre exemple bien connu l'ACPI) ce qui est tout a fait logique d'un point de vue économique.

    En fait, c'est un problème de part de marché, et tant que celle de Linux resteront ridicule, ça ne changera pas. Et c'est pour ça qu'à chaque fois que je lis que "moi je n'en ai rien à faire des PdM Linux", ça me fait rigoler (enfin rigoler jaune)..

  • [^] # Re: Munich et la roue

    Posté par  . En réponse au journal La ville de Gummersbach vient de terminer sa migration Linux. Évalué à 1.

    RDP n'est pas le truc parfait et ideal, VNC desole, il faudrait etre fou pour utiliser ca plutot que NX

    Pour le moment, mais note que NX implique X qui implique que les toolkits continuent de supporter X..
    Avec Wayland qui arrive, j'ai comme un doute que ça va durer longtemps: les techno desktop et la compatibilité sous Linux, hum.

    Après Weston a une backend RDP(enfin en théorie*) donc logiquement les autres compositeurs Wayland (KDE, Gnome, Enlightment) devraient intégrer aussi une backend similaire..

    *: aucune idée de savoir si elle marche bien ou pas: jamais vu aucun retour sur le sujet..

  • [^] # Re: Process VS thread

    Posté par  . En réponse au journal Des nouvelles d'Electrolysis. Évalué à 3.

    Consommation en ressource vs architecture 'saine' le débat est éternel..
    J'aime beaucoup Chrome mais je l'ai abandonné sur un PC qui n'a "que" 4 Go de RAM à cause de sa consommation mémoire, se faire 'swapper' le bureau c'est très désagréable..

  • [^] # Re: Avant de chercher les causes, il faut peut-être vérifier le postulat de départ.

    Posté par  . En réponse au journal Un billet de réflexion sur l'échec de Linux sur le Desktop. Évalué à 1.

    Il n'y a pas que la création, il y plein de geek qui ont voulu/veulent adapter Linux pour le grand public, par exemples les devs de Gnome.

    Donc pour le moment, on peut dire que l'adaptation est un échec oui, coté PdM en tout cas..

  • [^] # Re: Quelqu'un peut-il m'expliquer le problème avec l'ABI de KDE

    Posté par  . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à 2.

    Oups, je confonds avec le C ou par défaut tes fonctions sont publiques et il faut ajouter 'static' pour avoir des fonctions 'privée' au fichier.

    Manque de sommeil..

  • [^] # Re: Quelqu'un peut-il m'expliquer le problème avec l'ABI de KDE

    Posté par  . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à 1.

    Les principaux problèmes d'ABI causant des mots de têtes aux packagers sont assez différents.

    L'un vient du fait que la taille des types est décidée à la compilation en C++.

    Je me demande si les librairies compilées ne posent pas plus de problème qu'ils en résolvent et si un système à la ANDF ne serait pas intéressant..

    Et puis ça permettrait potentiellement de "reconfigurer la librairie" en fonction de l'application: une application qui a un gros besoin de performance? Un int C reste un entier avec débordement silencieux, autrement un int devient un entier 'vérifié' qui arrête l'application en cas de débordement (sémantique autorisée par le C/C++).

    Pour l'utilisation de vtable et d'un vrai "appel par message" en plus, je trouve ta suggestion intéressante après tout c'est juste l'API externe qui nécessite d'être déclarée ainsi (si on veut maximiser les perf) et bien délimiter/définir l'API externe est une bonne idée je pense.
    Dans le même genre, j'ai toujours trouver dommage qu'en C++ les méthodes étaient publique par défaut au lieu de privée.

  • [^] # Re: Autre problème, autre solution?

    Posté par  . En réponse au journal Disruptive innovation comme y disent aux states. Évalué à 2.

    Oui enfin l'immobilisme d'X et l'inadaptation entre les toolkits (p… il y en a que 2 qui comptent pas f… de collaborer??) et X est un gros gâchis pas la peine de revenir la dessus..

    Avec Wayland, on va gagner un système efficace pour l'embarqué ( http://www.collabora.com/about-us/blog/2014/08/13/wayland-x11-arm-mali/ ) au prix d'un affichage distant sous-optimal (en théorie), je pense que pour beaucoup ce n'est pas trop cher, même si c'est dommage car on aurait probablement pu avoir les deux..

  • [^] # Re: Autre problème, autre solution?

    Posté par  . En réponse au journal Disruptive innovation comme y disent aux states. Évalué à 3.

    Oui, les toolkits n'exploitent pas bien X à l'heure actuelle.

    Note quand même que dans TOUT les cas si l'utilisateur, les applications ou les toolkits ne jouent pas le jeux, ça peut créer des problèmes pour l'affichage distant: avec Wayland il a été évoqué de compresser les buffers avant de les envoyer pour réduire la bande passante utilisé, ce n'est pas difficile d'imaginer un thème de bureau ou des applications qui réduise l'efficacité de cette compression: genre un effet de flamme dynamique en papier peint avec des fenêtres translucides, trop cool comme thème non?

    Et hop la bande passante qui explose avec Wayland (avec X ça dépendrait de la façon de faire, ça peut être la même chose ou 'moins pire')..

  • [^] # Re: Autre problème, autre solution?

    Posté par  . En réponse au journal Disruptive innovation comme y disent aux states. Évalué à 3.

    Pour moi, une vrai transparence réseau, c'est assez orthogonal au serveur d'affichage.

    Hum, pas tout a fait, la conception de Wayland ne peut pas être aussi efficace en distant qu'une architecture 'à la X' (puisqu'avec X tu peux passer des buffer comme avec Wayland mais pas l'inverse: pas de commande de dessin à distance avec Wayland) après les utilisateurs se fichent de la conception ce qu'ils comparent eux ce sont des implémentations, à voir en pratique donc..

  • # Autre problème, autre solution?

    Posté par  . En réponse au journal Disruptive innovation comme y disent aux states. Évalué à 3.

    pour ce qui est de Wayland, si tu es de bonne fois tu admettras quand même que le problème que tu cherche à résoudre est juste 1000 fois plus compliqué que ce cherche a faire Wayland (un affichage local efficace)..
    Et en fait le bon point de départ pour ta "transparence 2.0" ne serait pas Wayland mais X où on peut noter que l’amélioration de la transparence réseau plutôt basique qu'X propose a attiré relativement peu de monde et n'a pas été réintégré dans X: NX ou autre, ça devrait être utilisé pour faire un "X12" plutôt que d'être un élément séparé!

  • [^] # Re: Elitisme

    Posté par  . En réponse au journal Médailles Fields en vue. Évalué à 8.

    Le problème, c'est pas l'intégrisme

    Ah? Pourtant respecter intégralement les préceptes de la religion, moi je trouve que c'est un problème quand la religion dit qu'il faut tuer ceux qui ont quitté la religion, les femmes infidèles, etc.

  • # Des articles sympas sur les vainqueurs des médailles Fields

    Posté par  . En réponse au journal Médailles Fields en vue. Évalué à 3.

    .. mais en Anglais, le lien vers celui pour Maryam Mirzakhani: http://www.simonsfoundation.org/quanta/20140812-a-tenacious-explorer-of-abstract-surfaces/
    mais il y a un article pour chacun des vainqueurs.