Je crois qu'on peut dire que Phoronix est un site déplorable.
Déplorable tu exagères..
Tout ce que tu dis est vrai mais il a quand même parfois des infos que d'autres non pas (par exemple des liens a des blogs que je ne connaissais).
Et parfois dans le forum il y a des développeurs qui interviennent (ça en fait un des forums les plus bizarre que je connaisse: rempli de trolleur qui n'y connaissent rien et critiquent tout mais avec de temps en temps des développeurs qui interviennent!).
Il y a plein de site avec des bizarrerie, des biais, il faut le savoir et filtrer, mais de la a déplorer qu'ils existent, non.
Par contre j'avais lu qu'avec Wayland on pouvait ouvrir une fenêtre(*) transparente faisant tout l'écran qui permettrait d'écouter le clavier ?
Pas vraiment: avec Wayland (Weston en fait) tu peux effectivement ouvrir une fenêtre transparente qui couvrirait l'écran sans que l'utilisateur sans aperçoive puisque les décorations sont affichées par le programme donc tu n'aurais pas de fenêtre "bizarre" affichées a l'écran, après ça ne sert à rien car il ne suffit pas de recevoir les évènements souris/clavier il faut aussi les rediriger vers les applications "en dessous" autrement tes applications arrêtent de recevoir des évènements et donc de fonctionner, ce qui n'est pas très discret!
Et il me semble que Wayland/Weston n'a pas la fonctionnalité de redirection des évènements..
Maintenant comment ça va fonctionner pour les clavier "virtuels" avec Wayland, des applications qui doivent légitimement envoyer des évènements, là j'avoue que je ne sais pas..
Je vois 2 possibilités: Wayland vérifie que le programme qui envoient des évenements a des privilèges particulier (comment il peut faire ça??) ou bien les claviers virtuels font partie de Weston, mais ça n'est pas souple du tout..
Je faisais du code récursif en Pascal alors la récursion comme concept propre au fonctionnel..
De même le pattern matching est très similaire au case of/select..
La fermeture, OK, ça c'est quelque-chose qui vient du fonctionnel effectivement.
J'ai lu sur Scala que c'était un mélange fonctionnel/objet donc les deux me paraissent non-exclusif en effet.
Pour le reste, le fonctionnel pur ça serait plutôt en Haskell qu'en OCaml.
Ca peut être un problème de performance?
Quand tu rajoutes des choses pour amméliorer la perf (par ex les RISC qui sont passés d'instruction 32bit uniquement au 16/32bit), ça complique la programmation..
Au dela du CPU, si j'ai bien suivi les problèmes du R Pi sont le port Ethernet sur le chipset USB (ce qui limite les perf et utilise du CPU je crois) et la fiabilité du support USB:
-le Cubieboard fait-il aussi de l'Ethernet sur USB?
-y a t'il déjà des tests/revue du Cubieboard (des prototypes par exemples)?
Mouai sauf que la "closed source backend" tourne sur un autre processeur.
Mais j'aurai du m'en douter: Téo est plus sensible à l'esprit qu'à la lettre..
Je ne suis pas d'accords: ils ont annoncé qu'ils ont libéré leur pilote. C'est ce qu'ils ont fait, POINT, donc ce n'est pas du pipeau (ne pas confondre pilote et firmware).
Corollaire: tout le code tournant sur l'ARM peut maintenant être open-source, et conséquence positive OpenBSD devrait pouvoir être porté sur Raspberry Pi.
Après leur pilote est pour des accéder des interfaces "haut niveau" fournie par le GPU (qui a un compilateur embarqué) et non pas des interfaces "bad niveau":
1) ça rends ces pilotes beaucoup plus figés et plus fragile, ce que tu appelle (correctement) "bridé".
2) c'est moins intéressante pour ceux qui aiment bien "mettre les mains dans le cambouis"
Et oui vivement de pouvoir se brancher directement sur le silicium, ras le bol de ces interfaces pénibles que sont les yeux, les doigts…
Hum, si je ne me trompes pas, ceux qui utilisent des capteurs pour piloter quelque-chose doivent apprendre a s'en servir, c'est donc beaucoup plus pénible que d'utiliser les yeux et les doigts: ceux-là tu a déjà appris à t'en servir quand tu étais bébé..
Pour le reste, je n'ai pas vu ce documentaire, mais bon parler d'"humanité totalement artificielle" c'est comme parler d'aller dans le système solaire le + proche (4.7 années-lumières) quand on est juste aller sur la lune à l'heure actuelle, c'est plus proche du fantasme que de la réalité.
Y'a un truc que je comprends pas très bien: Wayland incorporerait le gestionnaire de fenêtres, mais avec Weston, ce sont les clients qui dessinent leurs décorations. Il est où le gestionnaire de fenêtre dans tout ça?
Oui, une partie des fonctionnalités du gestionnaire de fenêtre "a la X" est faite par le client (le dessin et la gestion des décorations des fenêtres) quand on utilise Weston, mais il reste le déplacement des fenetres (le client détecte que l'utilisateur veut déplacer la fenetre et dit à Weston "je suis en mode de déplacement" qui déplace ensuite la fenetre de manière autonome jusqu'à ce que l'utilisateur relache le boutton puis il rend la main), prendre la main sur les clients qui ne "ping" plus, etc.
incorporer le toolkit dans le serveur graphique.
M'étonnerait, tu perds en souplesse et (sauf en cas distant) je ne pense pas que tu gagne beaucoup en performance.
OK, le texte aurait put être plus clair, mais l'idée était de dire que faire que des appli X ayant un look cohérent dans Y, ça a demandé des efforts et qu'ajouter les décorations dans la liste des choses a adapter, c'est juste un item de plus a rajouter dans la liste des choses a synchroniser pas une nouvelle problématique.
Mais c'est clair que ça fait du boulot de synchro en plus.
Il m'a toujours semblé que c'était plus un problème de Linux et de toolkit que d'X.Org mais les gens aiment bien taper sur X, je ne sais pas pourquoi..
Supposons qu'une application ait obtenu un tampon dans une carte et qu'on souhaite changer de carte --> problème!
Relis l'article "Un serveur Wayland joue à la fois le rôle de compositeur, de gestionnaire de fenêtres et de serveur d’affichage.", et toi tu marque "s'il s'agit d'un serveur complet", pffff.
La source: http://wayland.freedesktop.org/architecture.html
En condensé: c'est surtout mieux pour les développeurs, pour le reste Wayland ~= extension DRI2 de X.Org donc perf similaire à X en première approximation(si le toolkit utilise l'extension DRI2) mais il y a quand même quelques différences :
1) serveur Wayland = (serveur d'affichage + compositeur + gestionnaire de fenêtre) donc possibilité d'interagir avec une fenêtre transformée et moins d'IPC donc perf potentiellement légèrement meilleure.
2) l'API de Wayland contient une notification pour prévenir quand l’image fournie a été affichée: possibilité de faire des animations fluides.
3) si la gestion des décorations de fenêtre est faite par le client, le redimensionnement des fenêtres sera 'tear free'/sans cisaillement mais potentiellement saccadé si l'application est lente a répondre.
Pourquoi tu réponds non?
Ce qu'il dit au début est correct (serveur Wayland == serveur d'affichage), donc si tu veux avoir un gestionnaire de fenetre alternatif, il faut en fait créer (par exemple en forkant Weston) un serveur d'affichage complet.
Là ou c'est plus douteux c'est quand il considère que c'est mort puisque KDE et Gnome (etc) bossent pour que leur gestionnaires de fenetres soient des serveur d'affichage Wayland, donc ça me parait bien parti!
scope [coupé] Donc ça ne remplace pas vraiment les exceptions.[coupé]Je ne vois pas non plus comment tu peut gérer certains cas avec.
Oh, ça ne remplace en aucun cas les exceptions, c'est juste une syntaxe en complément bien plus lisible que le try .. finally, qui est beaucoup lisible quand elle est applicable.
Donc on peut dire que c'est juste de la syntaxe et juste pour certains cas, mais de mon point de vue la gestion des ressources lors d'une transaction est un cas assez courant pour mériter un support particulier.
[^] # Re: SDCard
Posté par reno . En réponse au journal android 4.2 et nouveau nexus. Évalué à 3.
Ah? Alors il faut dire ça à Nokia car mon téléphone actuel le fait..
[^] # Re: En parlant de TCP...
Posté par reno . En réponse à la dépêche MPTCP, TCP dans un monde ultra‐connecté. Évalué à 2.
Donc Coded TCP fonctionne sur le principe des codes correcteurs d'erreurs, tu peux m'expliquer ce qu'il y a de génial la dedans?
[^] # Re: Pétard mouillé
Posté par reno . En réponse à la dépêche Broadcom libère la pile graphique du Raspberry Pi. Évalué à 3.
Déplorable tu exagères..
Tout ce que tu dis est vrai mais il a quand même parfois des infos que d'autres non pas (par exemple des liens a des blogs que je ne connaissais).
Et parfois dans le forum il y a des développeurs qui interviennent (ça en fait un des forums les plus bizarre que je connaisse: rempli de trolleur qui n'y connaissent rien et critiquent tout mais avec de temps en temps des développeurs qui interviennent!).
Il y a plein de site avec des bizarrerie, des biais, il faut le savoir et filtrer, mais de la a déplorer qu'ils existent, non.
[^] # Re: Sécurité dans la pile graphique
Posté par reno . En réponse à la dépêche Entretien avec Martin Peres, développeur Nouveau. Évalué à 4.
Pas vraiment: avec Wayland (Weston en fait) tu peux effectivement ouvrir une fenêtre transparente qui couvrirait l'écran sans que l'utilisateur sans aperçoive puisque les décorations sont affichées par le programme donc tu n'aurais pas de fenêtre "bizarre" affichées a l'écran, après ça ne sert à rien car il ne suffit pas de recevoir les évènements souris/clavier il faut aussi les rediriger vers les applications "en dessous" autrement tes applications arrêtent de recevoir des évènements et donc de fonctionner, ce qui n'est pas très discret!
Et il me semble que Wayland/Weston n'a pas la fonctionnalité de redirection des évènements..
Maintenant comment ça va fonctionner pour les clavier "virtuels" avec Wayland, des applications qui doivent légitimement envoyer des évènements, là j'avoue que je ne sais pas..
Je vois 2 possibilités: Wayland vérifie que le programme qui envoient des évenements a des privilèges particulier (comment il peut faire ça??) ou bien les claviers virtuels font partie de Weston, mais ça n'est pas souple du tout..
# concepts propre au fonctionnel?
Posté par reno . En réponse au message Paradigme fonctionnel : juste un habillage ?. Évalué à 2.
Je faisais du code récursif en Pascal alors la récursion comme concept propre au fonctionnel..
De même le pattern matching est très similaire au case of/select..
La fermeture, OK, ça c'est quelque-chose qui vient du fonctionnel effectivement.
J'ai lu sur Scala que c'était un mélange fonctionnel/objet donc les deux me paraissent non-exclusif en effet.
Pour le reste, le fonctionnel pur ça serait plutôt en Haskell qu'en OCaml.
[^] # Re: 3D
Posté par reno . En réponse à la dépêche Entretien avec Martin Peres, développeur Nouveau. Évalué à 2.
Ca peut être un problème de performance?
Quand tu rajoutes des choses pour amméliorer la perf (par ex les RISC qui sont passés d'instruction 32bit uniquement au 16/32bit), ça complique la programmation..
[^] # Re: Ha?
Posté par reno . En réponse au journal Un monde sans humain ?. Évalué à 2.
Ça peut, ça peut aussi aller en marche arrière cf le concorde.
# Je me demande s'il résoud les problèmes du R Pi?
Posté par reno . En réponse au journal Ouverture du crowdfunding pour le Cubieboard. Évalué à 3.
Au dela du CPU, si j'ai bien suivi les problèmes du R Pi sont le port Ethernet sur le chipset USB (ce qui limite les perf et utilise du CPU je crois) et la fiabilité du support USB:
-le Cubieboard fait-il aussi de l'Ethernet sur USB?
-y a t'il déjà des tests/revue du Cubieboard (des prototypes par exemples)?
[^] # Re: Ca vient de la souris ....
Posté par reno . En réponse au message C'est moi, firefox, ou xfce ?. Évalué à 2.
Très curieux, je me demande s'il serait possible de "logger" les évènements envoyés par l'ancienne souris?
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par reno . En réponse à la dépêche Broadcom libère la pile graphique du Raspberry Pi. Évalué à 0.
Mouai sauf que la "closed source backend" tourne sur un autre processeur.
Mais j'aurai du m'en douter: Téo est plus sensible à l'esprit qu'à la lettre..
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par reno . En réponse à la dépêche Broadcom libère la pile graphique du Raspberry Pi. Évalué à 4.
Je ne suis pas d'accords: ils ont annoncé qu'ils ont libéré leur pilote. C'est ce qu'ils ont fait, POINT, donc ce n'est pas du pipeau (ne pas confondre pilote et firmware).
Corollaire: tout le code tournant sur l'ARM peut maintenant être open-source, et conséquence positive OpenBSD devrait pouvoir être porté sur Raspberry Pi.
Après leur pilote est pour des accéder des interfaces "haut niveau" fournie par le GPU (qui a un compilateur embarqué) et non pas des interfaces "bad niveau":
1) ça rends ces pilotes beaucoup plus figés et plus fragile, ce que tu appelle (correctement) "bridé".
2) c'est moins intéressante pour ceux qui aiment bien "mettre les mains dans le cambouis"
[^] # Re: C'est crade mais ...
Posté par reno . En réponse au message [Samba] Comment présenter les liens symboliques comme s'ils étaient des fichiers classiques ?. Évalué à 2.
Tu pourrais peut-être faire une suggestion de fonctionnalité au projet Samba?
[^] # Re: Ha?
Posté par reno . En réponse au journal Un monde sans humain ?. Évalué à 2.
Hum, si je ne me trompes pas, ceux qui utilisent des capteurs pour piloter quelque-chose doivent apprendre a s'en servir, c'est donc beaucoup plus pénible que d'utiliser les yeux et les doigts: ceux-là tu a déjà appris à t'en servir quand tu étais bébé..
Pour le reste, je n'ai pas vu ce documentaire, mais bon parler d'"humanité totalement artificielle" c'est comme parler d'aller dans le système solaire le + proche (4.7 années-lumières) quand on est juste aller sur la lune à l'heure actuelle, c'est plus proche du fantasme que de la réalité.
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 2.
Oui, une partie des fonctionnalités du gestionnaire de fenêtre "a la X" est faite par le client (le dessin et la gestion des décorations des fenêtres) quand on utilise Weston, mais il reste le déplacement des fenetres (le client détecte que l'utilisateur veut déplacer la fenetre et dit à Weston "je suis en mode de déplacement" qui déplace ensuite la fenetre de manière autonome jusqu'à ce que l'utilisateur relache le boutton puis il rend la main), prendre la main sur les clients qui ne "ping" plus, etc.
M'étonnerait, tu perds en souplesse et (sauf en cas distant) je ne pense pas que tu gagne beaucoup en performance.
[^] # Re: Petite correction
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 2.
Je ne sais pas si le logiciel a déjà cette fonctionnalité mais c'est clairement quelque-chose de nécessaire.
[^] # Re: Petite correction
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 2.
OK, le texte aurait put être plus clair, mais l'idée était de dire que faire que des appli X ayant un look cohérent dans Y, ça a demandé des efforts et qu'ajouter les décorations dans la liste des choses a adapter, c'est juste un item de plus a rajouter dans la liste des choses a synchroniser pas une nouvelle problématique.
Mais c'est clair que ça fait du boulot de synchro en plus.
[^] # Re: Gestionnaire de fenêtres
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 1.
Tu ne modifie que la partie du serveur qui gère les fenêtres: http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html
[^] # Re: wayland
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 3.
Il m'a toujours semblé que c'était plus un problème de Linux et de toolkit que d'X.Org mais les gens aiment bien taper sur X, je ne sais pas pourquoi..
Supposons qu'une application ait obtenu un tampon dans une carte et qu'on souhaite changer de carte --> problème!
[^] # Re: Gestionnaire de fenêtres
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 3.
Relis l'article "Un serveur Wayland joue à la fois le rôle de compositeur, de gestionnaire de fenêtres et de serveur d’affichage.", et toi tu marque "s'il s'agit d'un serveur complet", pffff.
La source: http://wayland.freedesktop.org/architecture.html
[^] # Re: wayland
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 9.
En condensé: c'est surtout mieux pour les développeurs, pour le reste Wayland ~= extension DRI2 de X.Org donc perf similaire à X en première approximation(si le toolkit utilise l'extension DRI2) mais il y a quand même quelques différences :
1) serveur Wayland = (serveur d'affichage + compositeur + gestionnaire de fenêtre) donc possibilité d'interagir avec une fenêtre transformée et moins d'IPC donc perf potentiellement légèrement meilleure.
2) l'API de Wayland contient une notification pour prévenir quand l’image fournie a été affichée: possibilité de faire des animations fluides.
3) si la gestion des décorations de fenêtre est faite par le client, le redimensionnement des fenêtres sera 'tear free'/sans cisaillement mais potentiellement saccadé si l'application est lente a répondre.
[^] # Re: Gestionnaire de fenêtres
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 5.
Pourquoi tu réponds non?
Ce qu'il dit au début est correct (serveur Wayland == serveur d'affichage), donc si tu veux avoir un gestionnaire de fenetre alternatif, il faut en fait créer (par exemple en forkant Weston) un serveur d'affichage complet.
Là ou c'est plus douteux c'est quand il considère que c'est mort puisque KDE et Gnome (etc) bossent pour que leur gestionnaires de fenetres soient des serveur d'affichage Wayland, donc ça me parait bien parti!
[^] # Re: dommage
Posté par reno . En réponse au journal The Future of Functional Programming Languages. Évalué à 2.
Merci
[^] # Re: dommage
Posté par reno . En réponse au journal The Future of Functional Programming Languages. Évalué à 1.
Merci pour le lien mais lire un gros PDF avec GoogleDoc c'est pour les masochistes!
[^] # Re: dommage
Posté par reno . En réponse au journal The Future of Functional Programming Languages. Évalué à 3.
D: http://dlang.org/
Un langage principalement développé par des "vieux chibab" en C++..
[^] # Re: dommage
Posté par reno . En réponse au journal The Future of Functional Programming Languages. Évalué à 2.
Oh, ça ne remplace en aucun cas les exceptions, c'est juste une syntaxe en complément bien plus lisible que le try .. finally, qui est beaucoup lisible quand elle est applicable.
Donc on peut dire que c'est juste de la syntaxe et juste pour certains cas, mais de mon point de vue la gestion des ressources lors d'une transaction est un cas assez courant pour mériter un support particulier.