Mais je t'en prie, fais-nous une interface de Libreoffice pour un écran tactile de 5". Pareil pour the Gimp. Tes petits enfants la finiront peut-être… :-D
J'ai pas l'impression que les programmeurs de VLC soient des manchots, et pourtant il a fallu attendre un moment pour avoir une interface Android - pas encore stable d'ailleurs. Le tactile et le clavier/souris implique deux interfaces COMPLETEMENT différentes. Il faut TOUT repenser - et probablement modifier légèrement le fonctionnement du programme.
Un butineur c'est 4 boutons : back, forward, home et reload. Ca c'est fastoche. Mais dès qu'on parle d'une application un peu plus aboutie en terme de fonctionnalités ça se complique énormément.
J'ai un Droid avec cette fonction. Le dock Webtop de Motorola.
Et mon opinion après 6 mois/un an d'utilisation c'est que franchement comme il a été écrit plus haut l'interface d'une application pour un smartphone et pour un écran de 22" ne pourront JAMAIS être les mêmes. Dans un sens ou dans l'autre il faudra toujours 2 interfaces COMPLETEMENT différentes.
On va voir si Cannonical va réussir. Mais j'irai pas miser 1 heureux là-dessus vu le risque.
à mon sens, on est très loin d'atteindre le potentiel d'un langage comme Java ou Objective-C (et je ne parle même pas du confort de développement).
Franchement il y a deux mois je pensais exactement la même chose. Tout ce que j'avais vu depuis deux ans avec Canvas et autres technologies du HTML5, bof bof bof. Il me semblait illusoire de vouloir atteindre la vitesse d'une application native en allant dans cette direction. Et je ne donnais pas cher de la peau de FirefoxOS.
Mais depuis que j'ai vu les deux liens que j'ai posté ci-dessus ( même si la démo WebCL s'exécute sur un Mac ), je suis franchement revenu sur cet avis. Maintenant je pense que c'est non seulement possible, mais que c'est la meilleure direction à prendre.
Le confort de développement a rarement été à l'origine de l'engouement pour une technologie, sinon le Javascript serait mort depuis bien longtemps et Python/Zope domineraient le monde ;-)
Je pense que vous utilisez Marionnet parce qu'il emploie du cloisonnement plutôt que de la virtualisation. Ce qui permet de simuler des réseaux complexes en utilisant beaucoup moins de ressources.
Quand un projet n'est plus actif c'est plutôt bon signe : ça veut dire qu'il a abouti ;-D
Sinon CORE est très bien fait et très bien documenté. C'est pas parce qu'il y a un .mil dans le dns que ce n'est pas pour les étudiants.
Il y a une logique dans la stratégie : aller "libérer" les smartphones là où nous laissons pour seul solution opensource Android.
Ah mais sur le principe je suis tout à fait d'accord. Ce que je critique c'est le segment que Canonical attaque.
Les gars qui aiment programmer et bidouiller en ARM achètent des Raspberry Pi,des pc-clés Rockship, des Cubbieboard. Pas des smartphones à 850 $ !!!
Depuis que j'ai vu les démos Samsung sur WebCL, ou la première version d'OpenScalesGL en WebGL je n'ai plus aucun doute sur la réussite de FirefoxOS. Je comprends le pourquoi et le comment. Tout cela me semble parfaitement cohérent.
L'attractivité d'Ubuntu Edge elle est juste au niveau de l'interface utilisateur puisqu'au final il fera tourner 95% d'applications Androïd. Ca me semble bien faible pour justifier un tarif de 850$…
ça voudrait dire déjà intégrer tous les drivers de tous les systèmes de virtualisation connus
Pas tous. Certains matériels émulés sont communs aux virtualiseurs (par exemple intel e-1000 sur virtualbox et qemu ).
Mais c'est vrai qu'ils sont vraiment casse-pied à tous émuler des matériels différents…
ce qui implique qu'il faudrait changer de noyau si on migre d'une solution à l'autre
Pas changer de noyau : changer le pilote de la carte réseau dans certains cas. Et celui de la carte graphique parfois - rarement si on peut se contenter des résolutions du VESA standard.
T'es sûr d'avoir compris le but du projet?
Je pense que oui : il s'agit de montrer directement le fonctionnement d'une application sans passer par les habituelles étapes de configuration/installation des divers éléments partagés ( généralement apache + php + mysql ) et sans buter sur les problèmes de versions de librairies liées aux #*@E de gestionnaires de paquetages, ou aux considérations de sécurité variables des distributions (.htaccess en 127.0.0.1 par défaut, SELinux, etc etc…).
Bref à filer de la démo/installation d'application "clé en main" aux i-pommes générations : je clique install ça marche c'est ok, ça marche pas je jette et je prends autre chose sans chercher à comprendre pourquoi ça ne marche pas.
Après si c'est juste histoire de la ramener parce que TU sais trop bien comment monter un linux aux petits oignons en recompilant tout "from scratch", t'inquiète on a bien compris et je te rassure t'es pas tout seul.
J'avais l'impression d'être plus didactique que ça. Et moins prétentieux.
C'est sur le concept d'appliance que je bute.
Pour moi une appliance c'est une machine (virtuelle ou physique) qui a pour caractéristique principale d'avoir un "just enough operating system".
Et 212 Mo pour une VM Joomla selon moi ce n'est pas "just enough", sauf si on le traduit par JUSTE ENORMEMENT DE LIBRAIRIES EXCEDENTAIRES.
Et puis quitte à faire une "appliance" pour le coup c'est intéressant de compiler l'application en STATIQUE, puisque le système n'est pas censé faire autre chose qu'exécuter UNE application ( donc exit tout l'intérêt des librairies partagées).
Voilà, ça ne m'empêche pas de trouver ça génial et d'être en train de télécharger les VM GIT et StatusNet qui sont de véritables plaies à installer. Parce que je suis fainéant.
Le matos est forcément connu : on parle d'appliance donc soit de machine virtuelle - et le matériel émulé est parfaitement connu, soit de matériel physique cible déterminé. Sinon ce n'est pas une appliance mais une distribution linux standard en version mnimale/basique.
On est donc bien loin de ce que tu décris qui correspondrait plus à l'embarqué qui nécessite de bien connaitre son système et ses besoins à l'avance
Négatif. Pour moi l'embarqué va BEAUCOUP plus loin que ça : le noyau et les bibliothèques sont intégralement recompilées - et sûrement pas avec GCC. Et le noyau est probablement patché temps réel.
Avec Tiny Core on est bien dans l'appliance : noyau standard et on ajoute les composants un à un suivant le besoin - qui peut varier ou évoluer dans le temps. Avec Debian on est dans la distribution linux tout à fait classique et sans optimisation. Ca ou Suse ou Fedora ou Ubuntu pour moi c'est pareil au fond d'écran près.
Selon moi, les personnes visées sont les admins qui veulent monter une maquette rapidement ou les débutants n'ayant pas encore les connaissances sysadmin pour installer/configurer tout le système
Ben justement, pour monter une maquette tranquillement et simplement Tiny Core est assez idéal. "Configurer un système" se résume à 3 actions pour moi : configurer Iptables, Syslog, SSH.
Après si l'application à installer a 150 dépendances comme les horreurs que pondent les gars de Gnome, le mieux c'est d'en choisir une autre. Ou de la recompiler en statique sur une autre machine.
Assez semblable à TS-O-Matic dans l'esprit il me semble.
Le "Base Debian" m'inquiète toujours. Pas parce que c'est Debian, mais parce que c'est généralement la COLOSSALEMENT LOURDE base Debian Netinstall - et je ne partage pas vraiment la même conception de minimal que les développeurs Debian. Est-il possible de virer tous les drivers inutiles du noyau ? Si c'est oui alors je jette un coup d'oeil, si c'est non je ne vais pas plus loin. C'est selon moi la base même du concept d'appliance : strictement rien d'autre que ce qui est nécessaire à l'application - hormis busybox peut-être. Donc hors de question de partir sur la base d'un noyau avec tous ses modules, même non chargés.
Personnellement pour réaliser une appliance aujourd'hui je partirai de TCL/microcore, puis je rajouterai un par un les éléments dont j'ai besoin. Pas sûr que ce soit moins long que d'utiliser ce "générateur"…
Tout à fait. Et c'est le cas sur compiz-fusion il me semble.
En fait la seule chose que je reproche à Xorg actuellement, même en utilisant compiz-fusion, c'est d'exploiter encore beaucoup trop le CPU. Pour moi TOUT l'affichage ne devrait faire intervenir QUE le GPU.
Je n'ai pas l'impression que Wayland fasse un grand pas en avant dans cette direction.
En fait à moins de lancer un calcul de tableau croisés dynamique sous Excel ou une compilation en C mon CPU devrait être à… 0%.
Viperr4 n'a aucune prétention, c'est juste une distribution faite par un passionné de GNU/Linux aimant Fedora et openbox. C'est un peu une preuve de concept
Rien que pour l'honnêteté de cette phrase j'ai envie de l'installer. Sauf qu'elle n'apporte pas grand chose de plus que ma crunchbang…
Merci, c'est à peu près la conclusion à laquelle j'étais arrivé : Weston n'est en aucune mesure au niveau de Compiz-fusion en terme de fonctionnalités et de stabilité, Wayland n'apporte quasiment pas de progrès au niveau de la composition 3D et Compiz-fusion ne supporte pas Wayland.
Je suis un peu perdu sur Wayland/Weston, malgré les nombreux articles et les efforts pour expliquer les avancées de ces projets.
Je n'utilise que Compiz comme compositeur et gestionnaire de fenêtre (emerald) - ni Gnome, ni surtout KDE.
De ce que je comprends Wayland va réutiliser les driver DRI d'Xorg, donc question performance il y a de bonnes chances que ce soit strictement identique à ce que j'avais avec Xorg. Puisque ce sont surtout des drivers graphiques que dépend la performance du compositeur - et d'ailleurs c'est ce que j'en déduis du bricolage de Collabora sur le Raspberry Pi : si le videocore avait eu un driver libre le problème n'aurait pas existé… ( David Braben si tu nous lis sache que la boîte de Frontier Elite est sous cadre et vénérée comme une idole chez moi, je ne peux donc pas dire du mal du Pi, mais quand même ce videocore… argh… ).
Je ne sais pas si Compiz supportera Wayland, mais de ce que j'en comprends c'est Weston qui semble être le compositeur autonome appelé à remplacer Compiz puisqu'il a la bonne idée d'avoir un gestionnaire de fenêtre intégré ( j'ai longtemps eu un gros doute à ce sujet ). Je me doute bien que Weston doit être à l'heure actuelle à des années lumières de la richesse de configuration de Compiz.
Tous les programmes fermés et commercialisés, oui. Je demande la même réglementation que pour un fabriquant de matériel. Si un matériel défectueux est à l'origine d'un accident le fabriquant sera poursuivi. La même règle devrait s'appliquer aux éditeurs de logiciels.
Si un éditeur de logiciel refuse d'endosser cette responsabilité il ne devrait pas être autorisé à commercialiser son produit.
le fil Seenthis parle du contenu et des fonctionnalités de SPIP. Ce qui est critiqué sur Linuxfr ce sont les aspects techniques : charge du serveur web, nombres d'appels à la Bdd, délai de chargement des pages etc…
J'adore SPIP et j'ai beaucoup de respect pour ceux qui ont adapté SPIP pour créer Seenthis, mais le technicien qui sommeille en moi ne peut s'empêcher de penser et de dire que si on passe Seenthis à la moulinette de Yslow on va avoir la confirmation de la lenteur qui s'observe à l'écran.
Présenter Seenthis comme un moteur de blog oui, le présenter comme un "twitter-like" me semble exagéré.
[^] # Re: Même analyse que l'auteur de l'article
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 1.
Le mobile c'est un Galaxy S2… ;-)
[^] # Re: Oui mais.
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 1.
Mais je t'en prie, fais-nous une interface de Libreoffice pour un écran tactile de 5". Pareil pour the Gimp. Tes petits enfants la finiront peut-être… :-D
J'ai pas l'impression que les programmeurs de VLC soient des manchots, et pourtant il a fallu attendre un moment pour avoir une interface Android - pas encore stable d'ailleurs. Le tactile et le clavier/souris implique deux interfaces COMPLETEMENT différentes. Il faut TOUT repenser - et probablement modifier légèrement le fonctionnement du programme.
Un butineur c'est 4 boutons : back, forward, home et reload. Ca c'est fastoche. Mais dès qu'on parle d'une application un peu plus aboutie en terme de fonctionnalités ça se complique énormément.
# Des Benchmarks
Posté par Loïc Ibanez . En réponse au sondage Quel contenu aimeriez-vous voir plus souvent sur LinuxFr.org ?. Évalué à 4.
Pour pouvoir troller pendant des heures sur les conditions scientifiques des mesures.
[^] # Re: Oui mais.
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 2.
On a parlé de Gimp plus haut.
En fait je pense que ces applications seront probablement uniquement utilisables en mode écran.
On aura probablement des applis Androïd en mode tél. et des applis linux en mode écran.
C'est ce qui demande le moins de boulot, donc ce sera probablement la solution de Cannonical :-D --->[]
[^] # Re: Oui mais.
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 1.
Autant faire ça en HTML5/CSS3 me semble réaliste, autant en GTK… bonne chance…
[^] # Re: Oui mais.
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 6.
J'ai un Droid avec cette fonction. Le dock Webtop de Motorola.
Et mon opinion après 6 mois/un an d'utilisation c'est que franchement comme il a été écrit plus haut l'interface d'une application pour un smartphone et pour un écran de 22" ne pourront JAMAIS être les mêmes. Dans un sens ou dans l'autre il faudra toujours 2 interfaces COMPLETEMENT différentes.
On va voir si Cannonical va réussir. Mais j'irai pas miser 1 heureux là-dessus vu le risque.
[^] # Re: Même analyse que l'auteur de l'article
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 3.
Je suis même persuadé que ce tarif sera désormais le tarif max du très haut de gamme.
Ce qui rend encore plus irréaliste le tarif annoncé par Cannonical pour un produit à venir dans 2 ans !
[^] # Re: Même analyse que l'auteur de l'article
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 3.
Franchement il y a deux mois je pensais exactement la même chose. Tout ce que j'avais vu depuis deux ans avec Canvas et autres technologies du HTML5, bof bof bof. Il me semblait illusoire de vouloir atteindre la vitesse d'une application native en allant dans cette direction. Et je ne donnais pas cher de la peau de FirefoxOS.
Mais depuis que j'ai vu les deux liens que j'ai posté ci-dessus ( même si la démo WebCL s'exécute sur un Mac ), je suis franchement revenu sur cet avis. Maintenant je pense que c'est non seulement possible, mais que c'est la meilleure direction à prendre.
Le confort de développement a rarement été à l'origine de l'engouement pour une technologie, sinon le Javascript serait mort depuis bien longtemps et Python/Zope domineraient le monde ;-)
[^] # Re: Hack writing
Posté par Loïc Ibanez . En réponse à la dépêche Sortie de Cloonix 22.2. Évalué à 1.
Je pense que vous utilisez Marionnet parce qu'il emploie du cloisonnement plutôt que de la virtualisation. Ce qui permet de simuler des réseaux complexes en utilisant beaucoup moins de ressources.
Quand un projet n'est plus actif c'est plutôt bon signe : ça veut dire qu'il a abouti ;-D
Sinon CORE est très bien fait et très bien documenté. C'est pas parce qu'il y a un .mil dans le dns que ce n'est pas pour les étudiants.
[^] # Re: L'économie dans le crowdfunding ?
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à -1.
Aucun souci, ça fait longtemps que sur linuxfr
entraîne
[^] # Re: L'économie dans le crowdfunding ?
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 6.
On dit "mademoiselle".
[^] # Re: Même analyse que l'auteur de l'article
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 3.
Ah mais sur le principe je suis tout à fait d'accord. Ce que je critique c'est le segment que Canonical attaque.
Les gars qui aiment programmer et bidouiller en ARM achètent des Raspberry Pi,des pc-clés Rockship, des Cubbieboard. Pas des smartphones à 850 $ !!!
Depuis que j'ai vu les démos Samsung sur WebCL, ou la première version d'OpenScalesGL en WebGL je n'ai plus aucun doute sur la réussite de FirefoxOS. Je comprends le pourquoi et le comment. Tout cela me semble parfaitement cohérent.
L'attractivité d'Ubuntu Edge elle est juste au niveau de l'interface utilisateur puisqu'au final il fera tourner 95% d'applications Androïd. Ca me semble bien faible pour justifier un tarif de 850$…
[^] # Re: Un raté pour Apple ?
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 3.
Pas tout à fait d'accord. Ils sont concentrés sur le tryptique Phablette/montre/casque bluetooth. C'est Sony qui a tiré le premier.
En tant que consommateur cet ensemble me paraît tout à fait cohérent. Je possède smartphone+tablette+casque bluetooth déjà.
Et puis question innovation les Google Glass c'est du lourd quand même…
# Même analyse que l'auteur de l'article
Posté par Loïc Ibanez . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à -2.
1- L'appel aux dons est démesuré.
2- Le tarif du smartphone est démesuré
Je ne comprends pas la stratégie de Canonical. Il n'y a aucune logique dans cette approche du marché.
Le coup du téléphone qui se transforme en PC Motorola le fait depuis bien longtemps sur ses Droid. Et même sur l'Atrix avant. Pour 450 $…
Son cerveau serait pas resté dans l'espace à Shuttleworth ?
[^] # Re: assez similaire à TSoM (TS-O-Matic)
Posté par Loïc Ibanez . En réponse à la dépêche TKLDev : Le générateur d’appliances GNU/Linux fait peau neuve. Évalué à 0.
Pas tous. Certains matériels émulés sont communs aux virtualiseurs (par exemple intel e-1000 sur virtualbox et qemu ).
Mais c'est vrai qu'ils sont vraiment casse-pied à tous émuler des matériels différents…
Pas changer de noyau : changer le pilote de la carte réseau dans certains cas. Et celui de la carte graphique parfois - rarement si on peut se contenter des résolutions du VESA standard.
Je pense que oui : il s'agit de montrer directement le fonctionnement d'une application sans passer par les habituelles étapes de configuration/installation des divers éléments partagés ( généralement apache + php + mysql ) et sans buter sur les problèmes de versions de librairies liées aux #*@E de gestionnaires de paquetages, ou aux considérations de sécurité variables des distributions (.htaccess en 127.0.0.1 par défaut, SELinux, etc etc…).
Bref à filer de la démo/installation d'application "clé en main" aux i-pommes générations : je clique install ça marche c'est ok, ça marche pas je jette et je prends autre chose sans chercher à comprendre pourquoi ça ne marche pas.
J'avais l'impression d'être plus didactique que ça. Et moins prétentieux.
C'est sur le concept d'appliance que je bute.
Pour moi une appliance c'est une machine (virtuelle ou physique) qui a pour caractéristique principale d'avoir un "just enough operating system".
Et 212 Mo pour une VM Joomla selon moi ce n'est pas "just enough", sauf si on le traduit par JUSTE ENORMEMENT DE LIBRAIRIES EXCEDENTAIRES.
Et puis quitte à faire une "appliance" pour le coup c'est intéressant de compiler l'application en STATIQUE, puisque le système n'est pas censé faire autre chose qu'exécuter UNE application ( donc exit tout l'intérêt des librairies partagées).
Voilà, ça ne m'empêche pas de trouver ça génial et d'être en train de télécharger les VM GIT et StatusNet qui sont de véritables plaies à installer. Parce que je suis fainéant.
[^] # Re: assez similaire à TSoM (TS-O-Matic)
Posté par Loïc Ibanez . En réponse à la dépêche TKLDev : Le générateur d’appliances GNU/Linux fait peau neuve. Évalué à -2.
Le matos est forcément connu : on parle d'appliance donc soit de machine virtuelle - et le matériel émulé est parfaitement connu, soit de matériel physique cible déterminé. Sinon ce n'est pas une appliance mais une distribution linux standard en version mnimale/basique.
Négatif. Pour moi l'embarqué va BEAUCOUP plus loin que ça : le noyau et les bibliothèques sont intégralement recompilées - et sûrement pas avec GCC. Et le noyau est probablement patché temps réel.
Avec Tiny Core on est bien dans l'appliance : noyau standard et on ajoute les composants un à un suivant le besoin - qui peut varier ou évoluer dans le temps. Avec Debian on est dans la distribution linux tout à fait classique et sans optimisation. Ca ou Suse ou Fedora ou Ubuntu pour moi c'est pareil au fond d'écran près.
Ben justement, pour monter une maquette tranquillement et simplement Tiny Core est assez idéal. "Configurer un système" se résume à 3 actions pour moi : configurer Iptables, Syslog, SSH.
Après si l'application à installer a 150 dépendances comme les horreurs que pondent les gars de Gnome, le mieux c'est d'en choisir une autre. Ou de la recompiler en statique sur une autre machine.
[^] # Re: Hack writing
Posté par Loïc Ibanez . En réponse à la dépêche Sortie de Cloonix 22.2. Évalué à -1.
C'est à peu près la même chose que le french Marionnet, mais qui lui utilise le cloisonnement plutôt que la virtualisation.
Ou plus près de moi la même chose que Common Open Research Emulator
ça fait de la simulation. Comme une femme, mais en plus technologique ;-D
# assez similaire à TSoM (TS-O-Matic)
Posté par Loïc Ibanez . En réponse à la dépêche TKLDev : Le générateur d’appliances GNU/Linux fait peau neuve. Évalué à 0.
Assez semblable à TS-O-Matic dans l'esprit il me semble.
Le "Base Debian" m'inquiète toujours. Pas parce que c'est Debian, mais parce que c'est généralement la COLOSSALEMENT LOURDE base Debian Netinstall - et je ne partage pas vraiment la même conception de minimal que les développeurs Debian. Est-il possible de virer tous les drivers inutiles du noyau ? Si c'est oui alors je jette un coup d'oeil, si c'est non je ne vais pas plus loin. C'est selon moi la base même du concept d'appliance : strictement rien d'autre que ce qui est nécessaire à l'application - hormis busybox peut-être. Donc hors de question de partir sur la base d'un noyau avec tous ses modules, même non chargés.
Personnellement pour réaliser une appliance aujourd'hui je partirai de TCL/microcore, puis je rajouterai un par un les éléments dont j'ai besoin. Pas sûr que ce soit moins long que d'utiliser ce "générateur"…
[^] # Re: Et compiz ?
Posté par Loïc Ibanez . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à -1.
Tout à fait. Et c'est le cas sur compiz-fusion il me semble.
En fait la seule chose que je reproche à Xorg actuellement, même en utilisant compiz-fusion, c'est d'exploiter encore beaucoup trop le CPU. Pour moi TOUT l'affichage ne devrait faire intervenir QUE le GPU.
Je n'ai pas l'impression que Wayland fasse un grand pas en avant dans cette direction.
En fait à moins de lancer un calcul de tableau croisés dynamique sous Excel ou une compilation en C mon CPU devrait être à… 0%.
Et d'ailleurs même pour les tableurs ce n'est plus si sûr…
[^] # Re: Et compiz ?
Posté par Loïc Ibanez . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 1.
Mouais… et encore pas certain… pour l'instant les benchmarks plus haut parlent de 2D, pas d'OpenGL/OpenCL/Gallium3D etc etc…
Je demande à voir les %CPU et %GPU lors de l'affichage et à vérifier que Wayland utilise massivement moins le CPU et massivement plus le(s) GPU(s).
# Enfin une présentation honnête
Posté par Loïc Ibanez . En réponse à la dépêche Viperr 4 Vipera Aspis. Évalué à 3.
Rien que pour l'honnêteté de cette phrase j'ai envie de l'installer. Sauf qu'elle n'apporte pas grand chose de plus que ma crunchbang…
[^] # Re: Et compiz ?
Posté par Loïc Ibanez . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 2.
Merci, c'est à peu près la conclusion à laquelle j'étais arrivé : Weston n'est en aucune mesure au niveau de Compiz-fusion en terme de fonctionnalités et de stabilité, Wayland n'apporte quasiment pas de progrès au niveau de la composition 3D et Compiz-fusion ne supporte pas Wayland.
Il est par conséquent urgent d'attendre :-)
# Et compiz ?
Posté par Loïc Ibanez . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 2.
Je suis un peu perdu sur Wayland/Weston, malgré les nombreux articles et les efforts pour expliquer les avancées de ces projets.
Je n'utilise que Compiz comme compositeur et gestionnaire de fenêtre (emerald) - ni Gnome, ni surtout KDE.
De ce que je comprends Wayland va réutiliser les driver DRI d'Xorg, donc question performance il y a de bonnes chances que ce soit strictement identique à ce que j'avais avec Xorg. Puisque ce sont surtout des drivers graphiques que dépend la performance du compositeur - et d'ailleurs c'est ce que j'en déduis du bricolage de Collabora sur le Raspberry Pi : si le videocore avait eu un driver libre le problème n'aurait pas existé… ( David Braben si tu nous lis sache que la boîte de Frontier Elite est sous cadre et vénérée comme une idole chez moi, je ne peux donc pas dire du mal du Pi, mais quand même ce videocore… argh… ).
Je ne sais pas si Compiz supportera Wayland, mais de ce que j'en comprends c'est Weston qui semble être le compositeur autonome appelé à remplacer Compiz puisqu'il a la bonne idée d'avoir un gestionnaire de fenêtre intégré ( j'ai longtemps eu un gros doute à ce sujet ). Je me doute bien que Weston doit être à l'heure actuelle à des années lumières de la richesse de configuration de Compiz.
J'ai bon ?
[^] # Re: Me reproduire
Posté par Loïc Ibanez . En réponse au sondage Votre métier. Évalué à -1.
Tous les programmes fermés et commercialisés, oui. Je demande la même réglementation que pour un fabriquant de matériel. Si un matériel défectueux est à l'origine d'un accident le fabriquant sera poursuivi. La même règle devrait s'appliquer aux éditeurs de logiciels.
Si un éditeur de logiciel refuse d'endosser cette responsabilité il ne devrait pas être autorisé à commercialiser son produit.
[^] # Re: Discussion sur SeenThis
Posté par Loïc Ibanez . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 0.
Il n'y a pas vraiment de discussion.
le fil Seenthis parle du contenu et des fonctionnalités de SPIP. Ce qui est critiqué sur Linuxfr ce sont les aspects techniques : charge du serveur web, nombres d'appels à la Bdd, délai de chargement des pages etc…
J'adore SPIP et j'ai beaucoup de respect pour ceux qui ont adapté SPIP pour créer Seenthis, mais le technicien qui sommeille en moi ne peut s'empêcher de penser et de dire que si on passe Seenthis à la moulinette de Yslow on va avoir la confirmation de la lenteur qui s'observe à l'écran.
Présenter Seenthis comme un moteur de blog oui, le présenter comme un "twitter-like" me semble exagéré.