Tout à fait d'accord. Pour moi son emploi est cantonné au marché de niche de la virtualisation.
Mais je t'assure que sur une batterie de 2000 machines virtuelles ne faisant tourner qu'une application qui est un navigateur web, 10Mo de RAM économisés sur le serveur graphique par chaque machine ça fait une ENORME différence au final.
Et il y a un marché pour la situation que j'évoque, fais-moi confiance ;-)
Regarde la date de la vidéo. Des arm v9 très puissants il n'y en avait des masses en 2008 ;-)
Sans vouloir etre condecendant, directfb c'est mort
La dernière news date du 30/08/2013. Pour un mort il se porte plutôt bien.
Il y a presque plus de chip sans gpu
Si, dans qemu, virtualbox et vmware ;-). Mais je suis d'accord, sur une machine physique moderne ça n'a pas trop de sens.
directfb c'est vraiment uniquement pour ces derniers retardataire et encore l'api de directfb est vraiment terrible.
L'API c'est un problème de programmeur, pas d'utilisateur. Désolé de le dire aussi cruement mais que le travail d'un programmeur soit rendu infernal par une API ce n'est pas mon problème. Mon problème c'est d'optimiser le triangle coût/fonctionnalités/performances.
Le temps d'ecrire direct dans le framebuffer, c'est vraiment les annees 90
C'était le bon temps, à cette époque Linuxfr n'était pas encore "mainstream" comme disent les hipsters aujourd'hui. Et le réseau Internet n'était pas saturé de photos de chats et de vidéos de vacances.
Tiens donc, je me disais bien que le son était décodé sur le PC, mais je pensais qu'ensuite le son était envoyé directement en PCM via bluetooth au périphérique. En d'autre termes j'imaginais que ça fonctionnait un peu comme quand on balance /dev/dsp via netcat vers un autre PC.
Gnome 3 c'est un peu le "Velvet Underground" des bureaux : il y en a peu qui l'installent, mais tout ceux qui le font s'empressent de se lancer dans la programmation d'un bureau ;-D
Il y a DirectFB, , je trouve que tout le monde l'enterre un peu vite… :-(
Tant que Mir ou Wayland n'atteindront pas cette fuidité sur un ARMv9 pour moi ce sera poubelle.
On peut également citer les programmes faisant appel directement au framebuffer comme Netsurf-FB. Cette solution a l'élégance de se passer complètement de serveur graphique. Ce qui supprimerait un bon quart des discussions sur Linuxfr ;-D
Dois-je te rappeler que chaque chipset a sa façon de travailler, son langage?
Je sais, et c'est ce que j'ai du mal à accepter. Je m'explique : à l'image de VESA 2.0 je pense que tous les chipsets devraient avoir une partie "commune" qui permettrait d'implémenter les standards avec des circuits identiques. Et une partie "propriétaire" qui contiendrait des fonctions supplémentaires dont l'accès serait réservé aux développeurs d'entreprises sous licence. Il y aura toujours un marché pour la carte qui permet de gagner 10 fps sur le dernier jeu blockbuster sorti.
Parce que là, si je comprends bien la situation, en imaginant que l'on reprogramme un moteur de rendu comme PovRay en OpenCL, il faudrait le compiler 3 fois, une fois pour chaque fabriquant…
Quel progrès technique franchement… j'ai l'impression de revenir à l'avant IBM PC…. :-/
Je ne vois franchement pas comment on peut se passer d'une phase de stabilisation avant un montage… sauf pour imiter les films volontairement mauvais d'Andy Warhol à l'époque de la Factory…
Avant de pouvoir monter il y a BEAUCOUP de travail si les sources sont variées et multiples.
Je suis d'accord pour Hadoop, mais qu'il s'agisse d'XtreemOS, d'Erlang, d'OpenCL, WebCL, et de bien d'autres languages, beaucoup bénéficieront directement d'un tel cluster.
Et la puissance combinée du CPU et du GPU sur un Allwinner A20 est TRES loin d'être négligeable. Rien à voir avec celle d'un Raspberry Pi.
8x5 watts d'un côté pour un cluster 8xARM, une alim de 300w de l'autre pour un x86, ça fait une ENORME différence quand on passe à l'échelle !
Sauf que je préfère l'option "faire pression économique sur AMD" pour obtenir le retrait des firmwares que l'option rétro-ingénierie des firmwares.
La question 13 en particulier me semble plus lourde de conséquence que les débats Xorg/Mir/Wayland. J'aimerais un jour comprendre pourquoi il faut un SDK par marque (intel, AMD, Nvidia) pour compiler un programme OPENCL alors que c'est un standard approuvé par toutes ces marques !!!! °_° !!!!! TONNERRE DE BREST !
Je ne veux pas les dénigrer, j'imagine bien qu'il y a du travail derrière, mais la dernière fois que j'ai utilisé Avidemux, des plugins il y en avait 3, et c'étaient les plus basiques.
Equivalent de "deshaker" sous linux ? Et pourtant dieu sait que la phase de stabilisation est la première à réaliser avant de débuter n'importe quel montage. A moins de filmer en permanence avec un trepied…
Franchement, l'équivalent de VirtualduB+AviSynth sous linux je ne trouve pas.
Tente de récupérer un vieux film 16mm à 17 i/s, de le stabiliser, de corriger le 3/2 pulldown lors de son catastrophique import en VHS, de corriger les rayures liés à l'import VHS, de le désaturer, de rectifier les couleurs, d'enlever le grain en temporel et spatial, d'enlever les tâches sur la pellicule, d'affiner les contours, de faire de l'interpolation pour monter à 50 i/s. Aucun des logiciels de la liste ne permet de faire 20% de ce travail.
Après c'est sûr que coller deux vidéos d'iphone 4 avec un fondu enchaîné en mettant "mariage de clothilde et benoît" en titre et une musique bidon en fond ça ils doivent sûrement tous y arriver…
Je ne pense pas non. Qui peut couper un film à la seconde près avec une interface graphique ? Impossible d'atteindre la précision d'Avisynth avec un timeline et des ascenseurs.
Gérer les bandes sons et la synchro avec Avisynth n'a rien de bien difficile. Il faut juste comprendre comment ça fonctionne. Et puis chercher permet de comprendre la problématique de l'échantillonage et bien d'autres.
La gestion des espaces de couleurs par exemple est une problématique ESSENTIELLE complètement masqué par les logiciels de la liste. Le résultat sur un vidéoprojecteur / écran TV / écran PC n'est pas du tout le même. Et je ne parle même pas de l'upscaling, du downscaling, de l'entrelacement, etc etc…
ffmpeg est un programme génial pour l'encodage, mais pour gérer les incrustations vidéo avec bon courage… :-)
des alternatives à AviSynth sous Linux j'en ai cherché croyez-moi…
Sans plaisanter je n'ai jamais pu me faire à quoi que ce soit d'autre.
La richesse des plugins, la souplesse du language, il n'y a rien que j'ai essayé et qui arrive à la cheville d'Avisynth.
Et pour pouvoir bénéficier de la puissance de deshaker je rajoute virtualdub+deshaker.
Le montage ? : film c = film a + film b. Et j'exagère à peine…
Honnêtement tous les logiciels cités plus haut sont tellement pauvres en fonctionnalités qu'ils me semblent juste là pour s'entraîner à faire de jolies interfaces sur du vide.
Lequel permet de passer un film en 60 images/s en utilisant de l'extrapolation de mouvement ?
Le fameux Avisynth 3 pour Linux c'est le saint graal du montage vidéo. J'en rêve la nuit…
Le LNC et le language N3 pour l'instant c'est un peu autant l'arlésienne que l'esperanto… ça reste hyper confidentiel, ne serait-ce que parce que la notion d'ontologie est tout de même cantonnée au milieu universitaire.
Ce que je constate c'est plutôt un retour aux languages basiques. J'en veux pour preuve le module Hive de Hadoop par Facebook ou le GQL par Google : comment retomber sur du bon vieux SQL92 que tout le monde comprend au lieu d'Xquery qui doit à peine franchir les portes du W3C… et je pense que le N3 c'est pareil.
Là vous allez très loin question recherche de sécurité. Les FPGA n'auront jamais les performances d'un circuit intégré. Et la performance reste quand même au coeur des préoccupations d'un consommateur au moment de l'achat.
Moi je suis juste horrifié de constater que dans le noyau linux 2.4 il n'y avait même pas - à ma connaissance - de branche "firmware", et qu'aujourd'hui je vois ça : http://packages.debian.org/sid/firmware-linux-nonfree
Si on prend les cartes graphiques, autant je comprends qu'un fabricant puisse développer des circuits spécifiques qui lui permettront de se différencier des autres et dont il partagera le secret sous licence avec quelques éditeurs de jeux vidéos ou autres, autant tout ce qui concerne l'implémentation des standards du khronos group ou VESA on devrait avoir des pilotes libres et sans firmwares.
Mettre un -8 à un commentaire aussi détaillé c'est vraiment de la jalousie…
Mon +1 étant acquis, je dois dire que ces firmwares sont de plus en plus présents dans bon nombre de périphériques aujourd'hui et que je suis inquiet de leur prolifération.
Rendons au système d'exploitation ce qui est logiciel et au matériel ce qui est strictement matériel.
Rien que le BIOS est source de problèmes : celui de mon vieux Toshiba "bloque" les résolutions possibles alors que sa carte graphique intel 915 GM peut monter allègrement à 1920x1080. Du coup j'ai été forcé de rentrer une résolution de 1918x1080 pour passer cette barrière stupide.
Donc je maintiens ma classification de diabolique/sain : je hais les firmwares.
C'est amusant, j'en retiens la même chose que pour les pilotes graphiques 3D : du libre sans en être jamais totalement, et une situation qui devient de plus en plus floue et complexe.
Le cas du bootloader signé me semble être le plus surprenant. Autant je comprends qu'un périphérique puisse ne pas avoir de pilote libre, ce qui est une situation assez analogue à celle existant sur PC, autant ne pas pouvoir démarrer le noyau/OS de mon choix sur du matériel que j'ACHETE ça me choque terriblement.
Si j'ai bien compris il y a 2 situations concernant les périphériques des smartphones : les diaboliques ont un pilote sous la forme d'un firmware intégré au matériel, et les autres ont un pilote logiciel externe comme sur PC.
C'est bien entendu dans cette couche d'abstraction que réside l'implémentation et le support du matériel,
Là j'ai bondi. Ce n'est donc pas dans le noyau que se trouvent les pilotes des périphériques ? Décidément ces smartphones sont très différents des PC.
Et puis sous réserve d'avoir un bon réseau ( avec SURTOUT une faible latence, qui est le point faible du HTML5 aujourd'hui, et la raison pour laquelle Google nous a pondu sa surcouche à UDP ), Fastbook a déjà démontré que l'on peut faire aussi bien que du natif pour les applis standards.
Fanchement pour moi le seul point bloquant du HTML5 c'était la 3D. Mais OpenCL et WebCL ont réglé sont seul défaut.
Donc FirefoxOS va bien dans la bonne direction, surtout que sur le WebCL il est un peu en avance - et à mon avis c'est tout sauf un hasard ;-D
# Compiz-fusion = Unity ?
Posté par Loïc Ibanez . En réponse au sondage 1 an après : quel gestionnaire de fenêtres utilisez‐vous ?. Évalué à 2.
J'utilise compiz-fusion sur Tiny Core Linux pour soulager mon vieux CPU de l'affichage et ne plus entendre démarrer mon ventilo de portable pour rien.
Aucun rapport avec Unity à ma connaissance. Je ne comprends pas pourquoi les deux choix sont liés.
[^] # Re: inutile
Posté par Loïc Ibanez . En réponse au sondage Votre solution pour le son. Évalué à 1.
Tout à fait d'accord. Pour moi son emploi est cantonné au marché de niche de la virtualisation.
Mais je t'assure que sur une batterie de 2000 machines virtuelles ne faisant tourner qu'une application qui est un navigateur web, 10Mo de RAM économisés sur le serveur graphique par chaque machine ça fait une ENORME différence au final.
Et il y a un marché pour la situation que j'évoque, fais-moi confiance ;-)
[^] # Re: inutile
Posté par Loïc Ibanez . En réponse au sondage Votre solution pour le son. Évalué à 1.
Regarde la date de la vidéo. Des arm v9 très puissants il n'y en avait des masses en 2008 ;-)
La dernière news date du 30/08/2013. Pour un mort il se porte plutôt bien.
Si, dans qemu, virtualbox et vmware ;-). Mais je suis d'accord, sur une machine physique moderne ça n'a pas trop de sens.
L'API c'est un problème de programmeur, pas d'utilisateur. Désolé de le dire aussi cruement mais que le travail d'un programmeur soit rendu infernal par une API ce n'est pas mon problème. Mon problème c'est d'optimiser le triangle coût/fonctionnalités/performances.
C'était le bon temps, à cette époque Linuxfr n'était pas encore "mainstream" comme disent les hipsters aujourd'hui. Et le réseau Internet n'était pas saturé de photos de chats et de vidéos de vacances.
[^] # Re: Jack mais en fait j'utilise une autre distribution
Posté par Loïc Ibanez . En réponse au sondage Votre solution pour le son. Évalué à 1.
Tiens donc, je me disais bien que le son était décodé sur le PC, mais je pensais qu'ensuite le son était envoyé directement en PCM via bluetooth au périphérique. En d'autre termes j'imaginais que ça fonctionnait un peu comme quand on balance /dev/dsp via netcat vers un autre PC.
[^] # Re: Jack mais en fait j'utilise une autre distribution
Posté par Loïc Ibanez . En réponse au sondage Votre solution pour le son. Évalué à 1.
Ce n'est pas ce qui se passe avec le bluetooth ?
# Gnome 3 et musique
Posté par Loïc Ibanez . En réponse au journal Gnome: ça faisait longtemps qu'on avait pas lancé un flamewar à propos de notre bureau.... Évalué à 0.
Gnome 3 c'est un peu le "Velvet Underground" des bureaux : il y en a peu qui l'installent, mais tout ceux qui le font s'empressent de se lancer dans la programmation d'un bureau ;-D
# Bluez ?
Posté par Loïc Ibanez . En réponse au sondage Votre solution pour le son. Évalué à 1.
ça fait longtemps que mes enceintes et mon casque sont en bluetooth…
Par conséquent il me semble que je n'ai pas besoin de serveur de son. Mais peut-être que je me trompe.
[^] # Re: inutile
Posté par Loïc Ibanez . En réponse au sondage Votre solution pour le son. Évalué à 8.
Il y a DirectFB, , je trouve que tout le monde l'enterre un peu vite… :-(
Tant que Mir ou Wayland n'atteindront pas cette fuidité sur un ARMv9 pour moi ce sera poubelle.
On peut également citer les programmes faisant appel directement au framebuffer comme Netsurf-FB. Cette solution a l'élégance de se passer complètement de serveur graphique. Ce qui supprimerait un bon quart des discussions sur Linuxfr ;-D
[^] # Re: Parfait. Les questions comme les réponses.
Posté par Loïc Ibanez . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 2.
Je sais, et c'est ce que j'ai du mal à accepter. Je m'explique : à l'image de VESA 2.0 je pense que tous les chipsets devraient avoir une partie "commune" qui permettrait d'implémenter les standards avec des circuits identiques. Et une partie "propriétaire" qui contiendrait des fonctions supplémentaires dont l'accès serait réservé aux développeurs d'entreprises sous licence. Il y aura toujours un marché pour la carte qui permet de gagner 10 fps sur le dernier jeu blockbuster sorti.
Parce que là, si je comprends bien la situation, en imaginant que l'on reprogramme un moteur de rendu comme PovRay en OpenCL, il faudrait le compiler 3 fois, une fois pour chaque fabriquant…
Quel progrès technique franchement… j'ai l'impression de revenir à l'avant IBM PC…. :-/
[^] # Re: Je ne connais qu'un seul NLE correct : Avisynth
Posté par Loïc Ibanez . En réponse à la dépêche Kino, c'est fini. Vive Kino ?. Évalué à 1.
Je veux bien, mais je n'ai pas les moyens
Si je me casse la tête avec mes filtres et mes .avs c'est bien pour obtenir un résultat correct avec peu de moyens…
[^] # Re: Je ne connais qu'un seul NLE correct : Avisynth
Posté par Loïc Ibanez . En réponse à la dépêche Kino, c'est fini. Vive Kino ?. Évalué à 1.
Je ne vois franchement pas comment on peut se passer d'une phase de stabilisation avant un montage… sauf pour imiter les films volontairement mauvais d'Andy Warhol à l'époque de la Factory…
Avant de pouvoir monter il y a BEAUCOUP de travail si les sources sont variées et multiples.
[^] # Re: ARM
Posté par Loïc Ibanez . En réponse au journal Power8 - OpenPower : l'hégémonie du x86 pourrait-elle être bousculée dans le monde serveur ?. Évalué à 1.
Je suis d'accord pour Hadoop, mais qu'il s'agisse d'XtreemOS, d'Erlang, d'OpenCL, WebCL, et de bien d'autres languages, beaucoup bénéficieront directement d'un tel cluster.
Et la puissance combinée du CPU et du GPU sur un Allwinner A20 est TRES loin d'être négligeable. Rien à voir avec celle d'un Raspberry Pi.
8x5 watts d'un côté pour un cluster 8xARM, une alim de 300w de l'autre pour un x86, ça fait une ENORME différence quand on passe à l'échelle !
Un exemple d'application qui en tire parfaitement partie : http://erlangonxen.org/
[^] # Re: ARM
Posté par Loïc Ibanez . En réponse au journal Power8 - OpenPower : l'hégémonie du x86 pourrait-elle être bousculée dans le monde serveur ?. Évalué à 1.
http://cubieboard.org/2013/08/01/hadoophigh-availability-distributed-object-oriented-platform-on-cubieboard/
[^] # Re: Je ne connais qu'un seul NLE correct : Avisynth
Posté par Loïc Ibanez . En réponse à la dépêche Kino, c'est fini. Vive Kino ?. Évalué à 3.
Merci !
Oh que ça m'a plu de lire ça !!!!
[^] # Re: Bel entretien qui me laisse pourtant sur ma faim
Posté par Loïc Ibanez . En réponse à la dépêche Entretien avec Paul Kocialkowski, développeur Replicant. Évalué à 2.
Je viens de comprendre pourquoi son karma est aussi mauvais…
# Parfait. Les questions comme les réponses.
Posté par Loïc Ibanez . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 6.
Sauf que je préfère l'option "faire pression économique sur AMD" pour obtenir le retrait des firmwares que l'option rétro-ingénierie des firmwares.
La question 13 en particulier me semble plus lourde de conséquence que les débats Xorg/Mir/Wayland. J'aimerais un jour comprendre pourquoi il faut un SDK par marque (intel, AMD, Nvidia) pour compiler un programme OPENCL alors que c'est un standard approuvé par toutes ces marques !!!! °_° !!!!! TONNERRE DE BREST !
[^] # Re: Je ne connais qu'un seul NLE correct : Avisynth
Posté par Loïc Ibanez . En réponse à la dépêche Kino, c'est fini. Vive Kino ?. Évalué à 1.
Je ne veux pas les dénigrer, j'imagine bien qu'il y a du travail derrière, mais la dernière fois que j'ai utilisé Avidemux, des plugins il y en avait 3, et c'étaient les plus basiques.
Equivalent de "deshaker" sous linux ? Et pourtant dieu sait que la phase de stabilisation est la première à réaliser avant de débuter n'importe quel montage. A moins de filmer en permanence avec un trepied…
Franchement, l'équivalent de VirtualduB+AviSynth sous linux je ne trouve pas.
Tente de récupérer un vieux film 16mm à 17 i/s, de le stabiliser, de corriger le 3/2 pulldown lors de son catastrophique import en VHS, de corriger les rayures liés à l'import VHS, de le désaturer, de rectifier les couleurs, d'enlever le grain en temporel et spatial, d'enlever les tâches sur la pellicule, d'affiner les contours, de faire de l'interpolation pour monter à 50 i/s. Aucun des logiciels de la liste ne permet de faire 20% de ce travail.
Après c'est sûr que coller deux vidéos d'iphone 4 avec un fondu enchaîné en mettant "mariage de clothilde et benoît" en titre et une musique bidon en fond ça ils doivent sûrement tous y arriver…
[^] # Re: Je ne connais qu'un seul NLE correct : Avisynth
Posté par Loïc Ibanez . En réponse à la dépêche Kino, c'est fini. Vive Kino ?. Évalué à 1.
Je ne pense pas non. Qui peut couper un film à la seconde près avec une interface graphique ? Impossible d'atteindre la précision d'Avisynth avec un timeline et des ascenseurs.
Gérer les bandes sons et la synchro avec Avisynth n'a rien de bien difficile. Il faut juste comprendre comment ça fonctionne. Et puis chercher permet de comprendre la problématique de l'échantillonage et bien d'autres.
La gestion des espaces de couleurs par exemple est une problématique ESSENTIELLE complètement masqué par les logiciels de la liste. Le résultat sur un vidéoprojecteur / écran TV / écran PC n'est pas du tout le même. Et je ne parle même pas de l'upscaling, du downscaling, de l'entrelacement, etc etc…
ffmpeg est un programme génial pour l'encodage, mais pour gérer les incrustations vidéo avec bon courage… :-)
des alternatives à AviSynth sous Linux j'en ai cherché croyez-moi…
# Je ne connais qu'un seul NLE correct : Avisynth
Posté par Loïc Ibanez . En réponse à la dépêche Kino, c'est fini. Vive Kino ?. Évalué à 2.
Sans plaisanter je n'ai jamais pu me faire à quoi que ce soit d'autre.
La richesse des plugins, la souplesse du language, il n'y a rien que j'ai essayé et qui arrive à la cheville d'Avisynth.
Et pour pouvoir bénéficier de la puissance de deshaker je rajoute virtualdub+deshaker.
Le montage ? : film c = film a + film b. Et j'exagère à peine…
Honnêtement tous les logiciels cités plus haut sont tellement pauvres en fonctionnalités qu'ils me semblent juste là pour s'entraîner à faire de jolies interfaces sur du vide.
Lequel permet de passer un film en 60 images/s en utilisant de l'extrapolation de mouvement ?
Le fameux Avisynth 3 pour Linux c'est le saint graal du montage vidéo. J'en rêve la nuit…
[^] # Re: Ubuntu Edge, la course à la convergence.
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.
L'échec n'est pas incompatible non plus avec ce qu'il tente : http://www.lemonde.fr/technologies/article/2013/08/22/le-smartphone-ubuntu-edge-ne-verra-pas-le-jour_3465281_651865.html
Ceci dit il a réussit dans ce qui me semblait être son objectif stratégique de départ : mettre la pression sur les constructeurs de Smartphones.
[^] # Re: Bel entretien qui me laisse pourtant sur ma faim
Posté par Loïc Ibanez . En réponse à la dépêche Entretien avec Paul Kocialkowski, développeur Replicant. Évalué à 1.
Le LNC et le language N3 pour l'instant c'est un peu autant l'arlésienne que l'esperanto… ça reste hyper confidentiel, ne serait-ce que parce que la notion d'ontologie est tout de même cantonnée au milieu universitaire.
Ce que je constate c'est plutôt un retour aux languages basiques. J'en veux pour preuve le module Hive de Hadoop par Facebook ou le GQL par Google : comment retomber sur du bon vieux SQL92 que tout le monde comprend au lieu d'Xquery qui doit à peine franchir les portes du W3C… et je pense que le N3 c'est pareil.
[^] # Re: Bel entretien qui me laisse pourtant sur ma faim
Posté par Loïc Ibanez . En réponse à la dépêche Entretien avec Paul Kocialkowski, développeur Replicant. Évalué à 5.
Là vous allez très loin question recherche de sécurité. Les FPGA n'auront jamais les performances d'un circuit intégré. Et la performance reste quand même au coeur des préoccupations d'un consommateur au moment de l'achat.
Moi je suis juste horrifié de constater que dans le noyau linux 2.4 il n'y avait même pas - à ma connaissance - de branche "firmware", et qu'aujourd'hui je vois ça : http://packages.debian.org/sid/firmware-linux-nonfree
Si on prend les cartes graphiques, autant je comprends qu'un fabricant puisse développer des circuits spécifiques qui lui permettront de se différencier des autres et dont il partagera le secret sous licence avec quelques éditeurs de jeux vidéos ou autres, autant tout ce qui concerne l'implémentation des standards du khronos group ou VESA on devrait avoir des pilotes libres et sans firmwares.
[^] # Re: Bel entretien qui me laisse pourtant sur ma faim
Posté par Loïc Ibanez . En réponse à la dépêche Entretien avec Paul Kocialkowski, développeur Replicant. Évalué à 4.
Mettre un -8 à un commentaire aussi détaillé c'est vraiment de la jalousie…
Mon +1 étant acquis, je dois dire que ces firmwares sont de plus en plus présents dans bon nombre de périphériques aujourd'hui et que je suis inquiet de leur prolifération.
Rendons au système d'exploitation ce qui est logiciel et au matériel ce qui est strictement matériel.
Rien que le BIOS est source de problèmes : celui de mon vieux Toshiba "bloque" les résolutions possibles alors que sa carte graphique intel 915 GM peut monter allègrement à 1920x1080. Du coup j'ai été forcé de rentrer une résolution de 1918x1080 pour passer cette barrière stupide.
Donc je maintiens ma classification de diabolique/sain : je hais les firmwares.
# Bel entretien qui me laisse pourtant sur ma faim
Posté par Loïc Ibanez . En réponse à la dépêche Entretien avec Paul Kocialkowski, développeur Replicant. Évalué à 4.
C'est amusant, j'en retiens la même chose que pour les pilotes graphiques 3D : du libre sans en être jamais totalement, et une situation qui devient de plus en plus floue et complexe.
Le cas du bootloader signé me semble être le plus surprenant. Autant je comprends qu'un périphérique puisse ne pas avoir de pilote libre, ce qui est une situation assez analogue à celle existant sur PC, autant ne pas pouvoir démarrer le noyau/OS de mon choix sur du matériel que j'ACHETE ça me choque terriblement.
Si j'ai bien compris il y a 2 situations concernant les périphériques des smartphones : les diaboliques ont un pilote sous la forme d'un firmware intégré au matériel, et les autres ont un pilote logiciel externe comme sur PC.
Là j'ai bondi. Ce n'est donc pas dans le noyau que se trouvent les pilotes des périphériques ? Décidément ces smartphones sont très différents des PC.
[^] # 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.
Et puis sous réserve d'avoir un bon réseau ( avec SURTOUT une faible latence, qui est le point faible du HTML5 aujourd'hui, et la raison pour laquelle Google nous a pondu sa surcouche à UDP ), Fastbook a déjà démontré que l'on peut faire aussi bien que du natif pour les applis standards.
Fanchement pour moi le seul point bloquant du HTML5 c'était la 3D. Mais OpenCL et WebCL ont réglé sont seul défaut.
Donc FirefoxOS va bien dans la bonne direction, surtout que sur le WebCL il est un peu en avance - et à mon avis c'est tout sauf un hasard ;-D