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')..
oui enfin y a pas que pour systemd que ça serait bénéfique.
Ça tombe bien, il ne semble pas avoir suggéré ça.
On peut mettre beaucoup de chose sur le dos de systemd mais faut pas tout mélanger non plus.
Quand je lis ça: http://lwn.net/Articles/580194/ ça me laisse à penser que l'implication des devs de systemd a quand même bien aidé pour cette nouvelle tentative d'avoir d-bus dans le kernel.
Oui enfin ça n'a pas l'air de déplaire les développeurs emblématiques de Linux car ils y participent eux mêmes!
Une question: pourquoi trouves-tu nécessaire d'ajouter ça?
Je n'ai en aucun cas critiqué l'intégration de KDBUS ou suggéré que ça dérangeait ou déplaisait à quelqu'un.
Il faut arrêter la parano: ce n'est pas parce que certains sont contre systemd que tout le monde l'est..
Oui enfin sur la discussion sur lkml systemd est évoqué. La raison principal de l'effort d'intégration de d-bus dans le noyau est parce que systemd l'utilise..
N'importe quoi.. Je remarque qu'on ne voit ou sont les boutons dans le style flat (il n'y a pas suffisamment de distinction entre le texte et les élements actifs menus/boutons) et tu me parles des panneaux de circulations qui n'ont pas de boutons, de menus donc comme contre exemple..
L'ésthétique (et non L'ésthétisme, barbare d'auteur) qui n'est ici, en passant, pas défini - participe de l'ergonomie.
Faux, ça peut être le cas mais au contraire il arrive que l'esthétique prime sur l'ergonomie: cas d'école le design flat si a la mode actuellement: on ne voit pas ou sont les boutons, du point de vue ergonomie c'est très mauvais..
Ce n'est pas la première fois que je lie ça donc j'imagine que ça doit être vrai, bon je trouve ça plutôt surprenant: la vectorisation 'automatique' c'est plutôt pour des boucles très régulières et dans ces cas là un compilateur intelligent (comme tu en donne un exemple) n'a même pas besoin d'introduire des check..
# 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')..
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 5.
Ça tombe bien, il ne semble pas avoir suggéré ça.
Quand je lis ça: http://lwn.net/Articles/580194/ ça me laisse à penser que l'implication des devs de systemd a quand même bien aidé pour cette nouvelle tentative d'avoir d-bus dans le kernel.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Une question: pourquoi trouves-tu nécessaire d'ajouter ça?
Je n'ai en aucun cas critiqué l'intégration de KDBUS ou suggéré que ça dérangeait ou déplaisait à quelqu'un.
Il faut arrêter la parano: ce n'est pas parce que certains sont contre systemd que tout le monde l'est..
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 4.
Oui enfin sur la discussion sur lkml systemd est évoqué. La raison principal de l'effort d'intégration de d-bus dans le noyau est parce que systemd l'utilise..
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 0.
Mais une "partie de systemd" va être dans le noyau: KDBUS, pour améliorer les perfs et la sécurité.
[^] # Re: Ergonomie
Posté par reno . En réponse au sondage Quelle importance a pour vous l’esthétisme de ce qui s'affiche sur votre écran ?. Évalué à 4.
N'importe quoi.. Je remarque qu'on ne voit ou sont les boutons dans le style flat (il n'y a pas suffisamment de distinction entre le texte et les élements actifs menus/boutons) et tu me parles des panneaux de circulations qui n'ont pas de boutons, de menus donc comme contre exemple..
[^] # Re: Ergonomie
Posté par reno . En réponse au sondage Quelle importance a pour vous l’esthétisme de ce qui s'affiche sur votre écran ?. Évalué à 3.
Faux, ça peut être le cas mais au contraire il arrive que l'esthétique prime sur l'ergonomie: cas d'école le design flat si a la mode actuellement: on ne voit pas ou sont les boutons, du point de vue ergonomie c'est très mauvais..
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par reno . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Ce n'est pas la première fois que je lie ça donc j'imagine que ça doit être vrai, bon je trouve ça plutôt surprenant: la vectorisation 'automatique' c'est plutôt pour des boucles très régulières et dans ces cas là un compilateur intelligent (comme tu en donne un exemple) n'a même pas besoin d'introduire des check..