Mon post est peut être pas clair, mais je dis justement qu'un branch on overflow( que le risc V n'a meme pas) n'est pas suffisant et que des instructions 'a la mips' seraient une très bonne idée mais le risc V ne les a pas..
Ta réaction m'a fait penser à "Mon CPU passe tout mon temps a attendre que j'entre des commandes donc si j'ai un CPU peu puissant je ne m'en rends pas compte", mmh?
Pas très futé comme remarque? Bah la tienne non plus..
En plus le coté moche ou pas moche n'était PAS ce que je mettais en avant (ça c'est subjectif) mais la facilité de trouver ses icones sur l'écran: plus ton fond d'écran est coloré/psychédélique plus ça demande un effort pour retrouver ses icones (petit certes l'effort mais présent quand même).
Le fond d'écran ça se change trivialement, maintenant je m'interroge quand même: y a t'il des devs KDE qui BOSSENT avec KDE?
Parce que bon avec un fond d'écran pareil ça n'aide pas.. Une image plus neutre pour distinguer facilement les icones serait un meilleur fond d'écran par défaut.
Jonathan Blow un créateur de jeux vidéos est en train d'écrire un nouveau langage qui, entre autre, essaye de simplifier le réusinage.
Un exemple si tu veux passer d'un 'array of struct' (AoS) classique à un struct of array (SoA) et bien il suffit d'ajouter une annotation sur UNE déclaration et il n'y a pas besoin de modifier le reste du code.
Juste un avertissement, Firefox v40 n'arrive pas a restaurer mes bookmark et pourtant la dernière sauvegarde a été faite juste après un 'refresh', les vieilles sauvegardes ne passent pas non plus.
J'ignore s'il s'agit d'un nouveau bug de FFv40 ou d'un ancien bug, mais c'est très agaçant
1) de perdre ses bookmarks
1) de voir l'outil d'import JSON s'interrompre sans donner le moindre indice sur ou le problème se trouve ('Unable to process the backup file') avec un message d'erreur comme ça je vais aller loin..
Très propre?
Minimaliste plutôt: un mauvais clone du MIPS.. Et ça je trouve que c'est un problème: on est au 21ème siècle, les ordinateurs sont supposés être connecté à Internet, ce qui devrait se refléter dans le CPU.
Le problème c'est qu'ajouter de la "vrai" sécurité dans le CPU (isolation mémoire), c'est très coûteux, sauf qu'il y a quand même quelques fonctionnalités de sécurité light/par cher qui existent mais le RISC-V ne les implémentent pas (à mon avis car ils ont tout misé sur la faible consommation en énergie pour concurrencer ARM) et ça j'ai du mal a l'avaler.
Plus concrètement:
-Pas de détection des débordement entier. La version originale du MIPS avait pour chaque opération entière une variante qui déclenchait un TRAP en cas de débordement entier.
Être sûr que X+1 est supérieur à X ou bien que ton programme se plante gratuitement(1), personnellement j'adore (c'est compatible avec la sémantique du C/C++ et au niveau implémentation hardware c'est quasiment gratuit, le plus gros problème est que ça occupe un bit supplémentaire dans l'encodage des instructions).
-Faciliter les calculs avec des entiers long: avec un CCR, on peut faire des calculs entiers longs efficacement, calculs long qui sont très utile pour le chiffrement.
Le chiffrement c'est plutôt utile a l'heure actuelle non?
Mais le RISC-V n'a ni variante d'instructions avec TRAP, ni CCR..
Désolé mais un Mill d'un point de vue technique, ça me fait plus saliver qu'un RISC-V (même s'ils déposent des brevets pour leur design et que je doute de leur succès).
1: Avec juste un CCR et un compilateur ajoutant dans 'branch on overflow', l’histoire a montré que comme cela ralentit le code 'normal' (même si c'est très faible) ce ne sera pas très utilisé..
Pour avoir un ordinateur libre, il faudrait que ça commence 'depuis la base': un hardware libre, puis un firmware libre et des software libre, hors je note que Debian vient de retirer le support du SPARC pour cause de manque d'intérêt et le SPARC est probablement le seul CPU 'réel' LEON dont l'ISA est libre.
Il y a d'autre projets pour faire des CPU libres (par exemple RISC-V (1)), mais bon il y a déjà (au moins) une ISA libre avec des vrais CPU ET elle peut supportée/utilisée alors y a t'il un réel désirs d'avoir des ordinateurs vraiment libre?
J'en doute, c'est VRAIMENT confortable, tellement simple d'utiliser un x86, un ARM..
1: je m'abstiendrais de commenter le projet RISC-V car ce n'est pas le sujet mais je n'en pense pas grand bien techniquement.
si tu as un background Scheme/Lisp, tu vois probablement les choses sous un autre angle.
Je n'ai pas un background Scheme/Lisp, mais je me suis bien cassé les dents sur les langages de configurations 'classiques' qui semblent plus simples, mais qui ne tiennent pas la 'montée en charge'..
Mais tu as raison, le Lisp ça reste pénible à lire, dommage que les Lisp ne soient pas passé aux M-expressions ça aurait été un bon compromis..
Le coté centré sur GNU OK, ça peut être limitant, mais pour le Scheme même si je ne suis pas fana de la lisibilité des Lisp, je suis BIEN MOINS fan des 'language de configuration', je n'ai pas regardé celui de Nix mais tout ceux que j'ai rencontré sont bien pourris (Makefile et bien autre) alors peut-être que celui de Nix est l'exception mais bon, un Lisp pour faire un DSL ça paraît une bonne idée.
C'est probablement le cas, mais en assembleur la gestion des ressources est transparente et comme la moindre fonctionnalités te prend 10 fois plus de code qu'en C, j'imagine que le bloat est très, très limité.
Après deux remarques:
1) ça n'a pas l'air très souple comme système MenuetOS: interface graphique jusqu'à 1280×1024 c'est quoi cette limitation bizarre???
2) l'OS qui m'avait bluffé par sa réactivité était BeOS¹ et il était codé en C++ donc c'est possible de faire efficace avec un langage de "haut niveau", mais ça n'est pas la norme malheureusement.
¹: à l'époque BeOS était beaucoup, beaucoup plus réactif et agréable à utiliser que Windows ou Linux.
Amusant ça la définition circulaire des fonctions qui te laisse le choix d'instancier celle que tu veux, pas sûr que ça soit un réel plus en pratique par rapport au classique 'tu dois définir cette fonction et les autres se basent dessus' mais bon..
Il y a quand même des raisons specifiques a D qui expliquent pourquoi il a eu du mal a prendre (la librairie standard qui utilise le GC, D1 vs D2, l'ancien fork incompatible des librairies, la license de la backend de dmd).
Rust n'a pas ces problèmes, bon évidemment il en a d'autres: la discussion sur lwn http://lwn.net/Articles/644671/ s'est centrée sur l'utilisation de Rust pour écrire un OS: dans la librairie standard actuelle une allocation memoire ne peut pas echouer ce qui ne semble pas adapter pour ecrire un OS, donc si tu veux ecrire un OS en Rust il faut commencer par ecrire sa propre librairie..
Merci pour ton journal, bon travaillant dans un open-space, je ne me vois pas ni utiliser un tapis de marche, ni un bureau assis/debout..
Par contre ayant des problèmes de poids, j'aimerai que tu précise ta phrase "Même l'astuce de bourrer l'estomac avec de la nourriture peu calorique ne fonctionne pas car le signal de satiété est faible par rapport à d'autres.
L'astuce consiste à changer la qualité des aliments, si possible en se restreignant légèrement."
Qu'appelle 'qualité des aliments'?
Les aliments 0%? Ça contredit un peu le début de phrase avec 'la nourriture peu calorique'..
Cette phrase me rend perplexe: le Japon a fait des grosses saloperies (tout comme la France hein) bien plus grave que tout ce qu'a pu faire Microsoft..
ça permet de rapidement mettre en place un container de test, dans lequel on peut tout casser si on a envie, sans rien risquer sur le système sous-jascent
Quand je vois les problèmes qu'à LibreOffice a se débarrasser des commentaires en Allemands.. j'avoue avoir du mal a comprendre l'intérêt des langages 'localisé'.
Bon l'esperanto est un concurrent de l'Anglais comme langage international donc ça a déjà plus de sens que des langages informatiques en Français, mais bon qui croit que l'esperanto va supplanter l'Anglais??
Bah, c'est surtout que comme on a beaucoup de chamanes religieux, ils se sont structurés avec leurs propre chefs religieux, ça n'en reste pas moins des chamanes religieux qui font donc beaucoup de mal..
Les docteurs se comportent aussi parfois comme des chamanes: cf les saignées et autres médicaments 'pourris' qui ont maltraités un grand nombre de patients et ce malgré le serment d'Hippocrate (d'abord ne pas nuire).
Le probleme de wayland c'est que ca fait des annees que c'est cense arriver et que cela n'arrive pas
Pas sûr que tu sois bien renseigné: Wayland est en déjà en prod et l'a été avant Mir, d'autant plus que c'est XMir qui est utilisé en prod, ce qui n'est pas vraiment Mir (XWayland ce n'est pas vraiment Wayland non plus): je ne pense pas que XMir|XWayland fournissent des avantages en performance par rapport à X11(natif) puisqu'il y a une surcouche intermédiaire.
Wayland est considéré comme stable, le gros travail restant est le portage des logiciels (KDE, Gnome).
A mon avis Canonical a fait Mir pour des raisons de contrôle du projet, pas pour la date de livraison, en tout cas si c'était pour la date de livraison, ils se sont plantés en beauté car les deux vont arriver à maturité quasiment en même temps.
Pas crédible ton troll "Mir qui dominera Wayland et tout le monde retournera sa veste pour Mir qui sera plus performant et plus flexible.", je n'ai vu aucun argument technique en faveur de Mir par rapport à Wayland.
Les performances des deux devraient être équivalentes (ça peut varier d'un compositeur à l'autre pour Wayland donc c'est difficile de parler de performance 'Wayland')..
[^] # Re: Pas si sûr que ça intéresse vraiment
Posté par reno . En réponse à la dépêche Librem 13, l’espoir d’avoir un jour un ordinateur libre. Évalué à 2.
Mon post est peut être pas clair, mais je dis justement qu'un branch on overflow( que le risc V n'a meme pas) n'est pas suffisant et que des instructions 'a la mips' seraient une très bonne idée mais le risc V ne les a pas..
[^] # Re: Goût enfin
Posté par reno . En réponse à la dépêche Les évolutions KDE avec KDE Frameworks 5.13, KDE Applications 15.08 et Plasma 5.4. Évalué à -1.
Ta réaction m'a fait penser à "Mon CPU passe tout mon temps a attendre que j'entre des commandes donc si j'ai un CPU peu puissant je ne m'en rends pas compte", mmh?
Pas très futé comme remarque? Bah la tienne non plus..
En plus le coté moche ou pas moche n'était PAS ce que je mettais en avant (ça c'est subjectif) mais la facilité de trouver ses icones sur l'écran: plus ton fond d'écran est coloré/psychédélique plus ça demande un effort pour retrouver ses icones (petit certes l'effort mais présent quand même).
[^] # Re: Goût enfin
Posté par reno . En réponse à la dépêche Les évolutions KDE avec KDE Frameworks 5.13, KDE Applications 15.08 et Plasma 5.4. Évalué à 2.
Quasiment jamais != jamais.
Très peu de gens travaillent sans bureau donc..
[^] # Re: Goût enfin
Posté par reno . En réponse à la dépêche Les évolutions KDE avec KDE Frameworks 5.13, KDE Applications 15.08 et Plasma 5.4. Évalué à 2.
Le fond d'écran ça se change trivialement, maintenant je m'interroge quand même: y a t'il des devs KDE qui BOSSENT avec KDE?
Parce que bon avec un fond d'écran pareil ça n'aide pas.. Une image plus neutre pour distinguer facilement les icones serait un meilleur fond d'écran par défaut.
# Interessant le problème du réusinage/refactoring
Posté par reno . En réponse à la dépêche Je crée mon jeu vidéo E15 : J'arrête.... Évalué à 3.
Jonathan Blow un créateur de jeux vidéos est en train d'écrire un nouveau langage qui, entre autre, essaye de simplifier le réusinage.
Un exemple si tu veux passer d'un 'array of struct' (AoS) classique à un struct of array (SoA) et bien il suffit d'ajouter une annotation sur UNE déclaration et il n'y a pas besoin de modifier le reste du code.
Malheursement il communique sur le sujet principalement par vidéos https://www.youtube.com/channel/UCCuoqzrsHlwv1YyPKLuMDUQ
# Attention a vos bookmarks
Posté par reno . En réponse à la dépêche Sortie de Firefox 40. Évalué à 3.
Juste un avertissement, Firefox v40 n'arrive pas a restaurer mes bookmark et pourtant la dernière sauvegarde a été faite juste après un 'refresh', les vieilles sauvegardes ne passent pas non plus.
J'ignore s'il s'agit d'un nouveau bug de FFv40 ou d'un ancien bug, mais c'est très agaçant
1) de perdre ses bookmarks
1) de voir l'outil d'import JSON s'interrompre sans donner le moindre indice sur ou le problème se trouve ('Unable to process the backup file') avec un message d'erreur comme ça je vais aller loin..
[^] # Re: Pas si sûr que ça intéresse vraiment
Posté par reno . En réponse à la dépêche Librem 13, l’espoir d’avoir un jour un ordinateur libre. Évalué à 9.
Très propre?
Minimaliste plutôt: un mauvais clone du MIPS.. Et ça je trouve que c'est un problème: on est au 21ème siècle, les ordinateurs sont supposés être connecté à Internet, ce qui devrait se refléter dans le CPU.
Le problème c'est qu'ajouter de la "vrai" sécurité dans le CPU (isolation mémoire), c'est très coûteux, sauf qu'il y a quand même quelques fonctionnalités de sécurité light/par cher qui existent mais le RISC-V ne les implémentent pas (à mon avis car ils ont tout misé sur la faible consommation en énergie pour concurrencer ARM) et ça j'ai du mal a l'avaler.
Plus concrètement:
-Pas de détection des débordement entier. La version originale du MIPS avait pour chaque opération entière une variante qui déclenchait un TRAP en cas de débordement entier.
Être sûr que X+1 est supérieur à X ou bien que ton programme se plante gratuitement(1), personnellement j'adore (c'est compatible avec la sémantique du C/C++ et au niveau implémentation hardware c'est quasiment gratuit, le plus gros problème est que ça occupe un bit supplémentaire dans l'encodage des instructions).
-Faciliter les calculs avec des entiers long: avec un CCR, on peut faire des calculs entiers longs efficacement, calculs long qui sont très utile pour le chiffrement.
Le chiffrement c'est plutôt utile a l'heure actuelle non?
Mais le RISC-V n'a ni variante d'instructions avec TRAP, ni CCR..
Désolé mais un Mill d'un point de vue technique, ça me fait plus saliver qu'un RISC-V (même s'ils déposent des brevets pour leur design et que je doute de leur succès).
1: Avec juste un CCR et un compilateur ajoutant dans 'branch on overflow', l’histoire a montré que comme cela ralentit le code 'normal' (même si c'est très faible) ce ne sera pas très utilisé..
CCR: Condition Code Register
# Pas si sûr que ça intéresse vraiment
Posté par reno . En réponse à la dépêche Librem 13, l’espoir d’avoir un jour un ordinateur libre. Évalué à 4.
Pour avoir un ordinateur libre, il faudrait que ça commence 'depuis la base': un hardware libre, puis un firmware libre et des software libre, hors je note que Debian vient de retirer le support du SPARC pour cause de manque d'intérêt et le SPARC est probablement le seul CPU 'réel' LEON dont l'ISA est libre.
Il y a d'autre projets pour faire des CPU libres (par exemple RISC-V (1)), mais bon il y a déjà (au moins) une ISA libre avec des vrais CPU ET elle peut supportée/utilisée alors y a t'il un réel désirs d'avoir des ordinateurs vraiment libre?
J'en doute, c'est VRAIMENT confortable, tellement simple d'utiliser un x86, un ARM..
1: je m'abstiendrais de commenter le projet RISC-V car ce n'est pas le sujet mais je n'en pense pas grand bien techniquement.
[^] # Re: Trés bon mais encore jeune.
Posté par reno . En réponse à la dépêche NixOS 14.12, la distribution Linux sans effet de bord. Évalué à 3.
Je n'ai pas un background Scheme/Lisp, mais je me suis bien cassé les dents sur les langages de configurations 'classiques' qui semblent plus simples, mais qui ne tiennent pas la 'montée en charge'..
Mais tu as raison, le Lisp ça reste pénible à lire, dommage que les Lisp ne soient pas passé aux M-expressions ça aurait été un bon compromis..
[^] # Re: Trés bon mais encore jeune.
Posté par reno . En réponse à la dépêche NixOS 14.12, la distribution Linux sans effet de bord. Évalué à 5.
Le coté centré sur GNU OK, ça peut être limitant, mais pour le Scheme même si je ne suis pas fana de la lisibilité des Lisp, je suis BIEN MOINS fan des 'language de configuration', je n'ai pas regardé celui de Nix mais tout ceux que j'ai rencontré sont bien pourris (Makefile et bien autre) alors peut-être que celui de Nix est l'exception mais bon, un Lisp pour faire un DSL ça paraît une bonne idée.
[^] # Re: Trés bon mais encore jeune.
Posté par reno . En réponse à la dépêche NixOS 14.12, la distribution Linux sans effet de bord. Évalué à 1.
D'ailleurs à ce sujet là, je me demande vraiment pourquoi il y a NixOS ET GNU Guix.
Je sais bien que dans le monde Linux 'chacun fait ce qui lui plait' mais là coté dispersion des efforts ça parait quand même bizarre..
[^] # Re: Intérêt
Posté par reno . En réponse au journal MenuetOS : 1.0. Évalué à 2.
Tu as regardé RiscOS?
[^] # Re: Intérêt
Posté par reno . En réponse au journal MenuetOS : 1.0. Évalué à 7.
C'est probablement le cas, mais en assembleur la gestion des ressources est transparente et comme la moindre fonctionnalités te prend 10 fois plus de code qu'en C, j'imagine que le bloat est très, très limité.
Après deux remarques:
1) ça n'a pas l'air très souple comme système MenuetOS: interface graphique jusqu'à 1280×1024 c'est quoi cette limitation bizarre???
2) l'OS qui m'avait bluffé par sa réactivité était BeOS¹ et il était codé en C++ donc c'est possible de faire efficace avec un langage de "haut niveau", mais ça n'est pas la norme malheureusement.
¹: à l'époque BeOS était beaucoup, beaucoup plus réactif et agréable à utiliser que Windows ou Linux.
[^] # Re: Les traits
Posté par reno . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 4.
Amusant ça la définition circulaire des fonctions qui te laisse le choix d'instancier celle que tu veux, pas sûr que ça soit un réel plus en pratique par rapport au classique 'tu dois définir cette fonction et les autres se basent dessus' mais bon..
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par reno . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 6.
Il y a quand même des raisons specifiques a D qui expliquent pourquoi il a eu du mal a prendre (la librairie standard qui utilise le GC, D1 vs D2, l'ancien fork incompatible des librairies, la license de la backend de dmd).
Rust n'a pas ces problèmes, bon évidemment il en a d'autres: la discussion sur lwn http://lwn.net/Articles/644671/ s'est centrée sur l'utilisation de Rust pour écrire un OS: dans la librairie standard actuelle une allocation memoire ne peut pas echouer ce qui ne semble pas adapter pour ecrire un OS, donc si tu veux ecrire un OS en Rust il faut commencer par ecrire sa propre librairie..
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par reno . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Je crois qu'il y a un lien entre l'article que tu cites et un vendeur d'outils d'analyse C+, ça n'invalide pas forcément l'article mais bon..
# Qu'appelle 'qualité des aliments'?
Posté par reno . En réponse au journal Retour d'expérience : tapis de marche pour un bureau assis/debout. Évalué à 2.
Merci pour ton journal, bon travaillant dans un open-space, je ne me vois pas ni utiliser un tapis de marche, ni un bureau assis/debout..
Par contre ayant des problèmes de poids, j'aimerai que tu précise ta phrase "Même l'astuce de bourrer l'estomac avec de la nourriture peu calorique ne fonctionne pas car le signal de satiété est faible par rapport à d'autres.
L'astuce consiste à changer la qualité des aliments, si possible en se restreignant légèrement."
Qu'appelle 'qualité des aliments'?
Les aliments 0%? Ça contredit un peu le début de phrase avec 'la nourriture peu calorique'..
[^] # Re: Xonsh
Posté par reno . En réponse au journal Batsh - Scripting Bash, et Windows. Évalué à 2.
Oui, j'ai vu xonsh recemment mais a mon avis, il manque un mode ´strict' qui t'empeche un conflit entre les variables et les executables.
[^] # Re: Bushido
Posté par reno . En réponse au journal Microsoft s'en prend à Kyocera sur sept brevets Android. Évalué à 1.
Cette phrase me rend perplexe: le Japon a fait des grosses saloperies (tout comme la France hein) bien plus grave que tout ce qu'a pu faire Microsoft..
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par reno . En réponse au journal Docker, la plateforme à la mode. Évalué à 1.
Certes, mais chroot faisait déjà ça, non?
# Bof
Posté par reno . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 4.
Quand je vois les problèmes qu'à LibreOffice a se débarrasser des commentaires en Allemands.. j'avoue avoir du mal a comprendre l'intérêt des langages 'localisé'.
Bon l'esperanto est un concurrent de l'Anglais comme langage international donc ça a déjà plus de sens que des langages informatiques en Français, mais bon qui croit que l'esperanto va supplanter l'Anglais??
[^] # Re: Trop des deux
Posté par reno . En réponse au journal [HS] Des chefs et des chamans. Évalué à 3.
Bah, c'est surtout que comme on a beaucoup de chamanes religieux, ils se sont structurés avec leurs propre chefs religieux, ça n'en reste pas moins des chamanes religieux qui font donc beaucoup de mal..
Les docteurs se comportent aussi parfois comme des chamanes: cf les saignées et autres médicaments 'pourris' qui ont maltraités un grand nombre de patients et ce malgré le serment d'Hippocrate (d'abord ne pas nuire).
[^] # Re: Marketing!
Posté par reno . En réponse au journal Sortie de Subsurface 4.4.1 le 18/02/2015. Évalué à 4.
Son créateur et aussi la migration GTK --> Qt qui a fait du bruit car c'était parmi les premières d'une série récente..
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 9.
Pas sûr que tu sois bien renseigné: Wayland est en déjà en prod et l'a été avant Mir, d'autant plus que c'est XMir qui est utilisé en prod, ce qui n'est pas vraiment Mir (XWayland ce n'est pas vraiment Wayland non plus): je ne pense pas que XMir|XWayland fournissent des avantages en performance par rapport à X11(natif) puisqu'il y a une surcouche intermédiaire.
Wayland est considéré comme stable, le gros travail restant est le portage des logiciels (KDE, Gnome).
A mon avis Canonical a fait Mir pour des raisons de contrôle du projet, pas pour la date de livraison, en tout cas si c'était pour la date de livraison, ils se sont plantés en beauté car les deux vont arriver à maturité quasiment en même temps.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 7.
Pas crédible ton troll "Mir qui dominera Wayland et tout le monde retournera sa veste pour Mir qui sera plus performant et plus flexible.", je n'ai vu aucun argument technique en faveur de Mir par rapport à Wayland.
Les performances des deux devraient être équivalentes (ça peut varier d'un compositeur à l'autre pour Wayland donc c'est difficile de parler de performance 'Wayland')..