Ouaip, avec Wayland l'export DISPLAY devient optionnel.. Si le compositeur le supporte c'est possible, sinon..
Sailfish utilise quel compositeur? Parce que si c'est Weston, il a une backend RDP donc tu devrais pouvoir l'utiliser mais bon je n'ai jamais lu aucun retour sur cette backend alors je ne sais pas si elle est fonctionnelle!
Hum, cet article a provoqué pas mal de réaction sur ceux qui utilisent leur touchpad de manière "non-standard": soit c'est l'article soit libinput va faire grincer des dents pas mal de monde..
Pour moi, Rust c'est Ada++: un langage très strictement typé dont les types incluent même la durée de vie des variables, hors je vois que pas mal de gens tapent sur Ada car ils trouvent le compilateur 'trop strict', donc c'est comment Rust en pratique?
Pas trop dur de satisfaire le compilateur pour la gestion des 'durée de vie'?
Ah? Je ne trouve pas moi.
Note que ce diagramme est une simplification de ce qui se passe en réalité: les compositeurs peuvent être empilé par exemple.
Encore?
Ça a été un sujet de discussion sur LWN, bien longue la discussion et finalement la raison pour laquelle ils ont fait ça est que xdg-shell est encore considéré comme étant expérimental donc casser la compatibilité sur un protocole expérimental n'implique pas de mettre à jour le numéro de version majeur du projet ce qui me parait normal: http://lwn.net/Articles/612653/
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.
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..
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.
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..
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..
Posté par reno .
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..
Posté par reno .
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?
Posté par reno .
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é?
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)..
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..
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: A noter: la release a été faite par Pekka Paalanen.
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
Ouaip, avec Wayland l'export DISPLAY devient optionnel.. Si le compositeur le supporte c'est possible, sinon..
Sailfish utilise quel compositeur? Parce que si c'est Weston, il a une backend RDP donc tu devrais pouvoir l'utiliser mais bon je n'ai jamais lu aucun retour sur cette backend alors je ne sais pas si elle est fonctionnelle!
[^] # Re: libinput
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
Hum, cet article a provoqué pas mal de réaction sur ceux qui utilisent leur touchpad de manière "non-standard": soit c'est l'article soit libinput va faire grincer des dents pas mal de monde..
[^] # Re: Touffu de chez touffu
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 1.
Là je suis d'accord, une vue avec un axe des temps serait beaucoup plus lisible pour comprendre ce qui se passe.
Après c'est quand même super pénible/difficile de faire des bons graphiques..
# Une question
Posté par reno . En réponse au journal Bref j'ai créé une bibliothèque Rust et un moteur ibus (et je cherche comment les packager). Évalué à 5.
Pour moi, Rust c'est Ada++: un langage très strictement typé dont les types incluent même la durée de vie des variables, hors je vois que pas mal de gens tapent sur Ada car ils trouvent le compilateur 'trop strict', donc c'est comment Rust en pratique?
Pas trop dur de satisfaire le compilateur pour la gestion des 'durée de vie'?
[^] # Re: Touffu de chez touffu
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 3.
Ah? Je ne trouve pas moi.
Note que ce diagramme est une simplification de ce qui se passe en réalité: les compositeurs peuvent être empilé par exemple.
[^] # Re: triste
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 10.
Tout le monde devrait lire LWN :)
[^] # Re: triste
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 10.
Encore?
Ça a été un sujet de discussion sur LWN, bien longue la discussion et finalement la raison pour laquelle ils ont fait ça est que xdg-shell est encore considéré comme étant expérimental donc casser la compatibilité sur un protocole expérimental n'implique pas de mettre à jour le numéro de version majeur du projet ce qui me parait normal: http://lwn.net/Articles/612653/
[^] # Re: A noter: la release a été faite par Pekka Paalanen.
Posté par reno . 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 reno . 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 reno . 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 reno . En réponse au journal Sur systemd, btrfs & co. Évalué à 6.
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..
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 reno . 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 reno . 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 reno . 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 reno . 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.Pas la moindre idée! Être anonyme ça réduis les risques mais..
[^] # Re: Citation needed
Posté par reno . En réponse au journal Forum sur la gouvernance de l'Internet. Évalué à 1.
"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 reno . 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 reno . 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 reno . En réponse au journal C++14. Évalué à 0.
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 reno . 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 reno . En réponse au journal UEFI, je chie ton nom. Évalué à 10.
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 reno . En réponse au journal La ville de Gummersbach vient de terminer sa migration Linux. Évalué à 1.
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 reno . 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 reno . 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 reno . 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..