Comme écrit plus haut ce n'est pas le programme qui est vendu dans le cas de la GPL, c'est le support - généralement - qui représente ce que je considère comme étant une garantie de fonctionnement du logiciel.
Ce que je ne comprends et n'accepte pas c'est que l'on puisse vendre un programme/produit sans en être responsable. Aujourd'hui que l'on prenne un OS MS Windows( payant et fermé ) ou un OS GNU/Linux ( ouvert et gratuit ), personne n'est responsable de son fonctionnement. Pour l'utilisateur les risques et périls sont les mêmes. Si c'est normal et logique dans le cas ouvert et gratuit, je trouve ça complètement anormal et illogique dans le cas payant et fermé. Le CLUF de MS Windows et de nombreux autres logiciels ne devrait pas être légal.
Mais sinon j'aime bien taper 2/3 lignes de code de temps en temps dans des langages ésotériques (Python, Erlang) pour essayer de rencontrer la logique de leur concepteurs. Et lancer des trolls sur Debian, la LSB, et un tas de choses que j'estime conservatrices et qui m'irritent.
Je ne suis pas autant pro-libre qu'anti-CLUF-débiles. Comment peut-on oser vendre un logiciel en déclinant toute responsabilité ? Ça me semble même légalement attaquable.
Imaginez qu'un constructeur automobile vende un véhicule en déclinant toute responsabilité : personne ne l'achèterai. Pour moi c'est la même chose en informatique : si c'est vendu c'est que le fonctionnement est garanti par ceux qui programment. Sinon ça ne devrait pas pouvoir légalement être vendu.
SPIP c'était le bon vieux temps des modems 56ko, son système de cache des articles ( bien avant l'utilisation massive des reverse proxy ) faisait des merveilles à l'époque pour limiter la charge du serveur par rapport aux "postnuke". Et ses capacités de personnalisation allaient très très loin. En terme de publication on pouvait tout faire à partir de SPIP.
Mais aujourd'hui j'ai désactivé le cache de pratiquement tout mes navigateurs parce que la récupération d'une information via le réseau est plus rapide que sur le disque dur. Le débit de toutes les pages html du monde est infinitésimal par rapport au volume du streaming vidéo.
Le résultat d'appel de chaque Hashtag devrait être stocké en Ram ( au minimum les 100 derniers résultats ).
Le cache de SPIP a été conçu pour limiter les appels à la BDD en stockant une page pendant plusieurs heures. C'est exactement à l'opposé du concept d'un "twitter like" dont l'objectif est de délivrer le plus rapidement et massivement possible une information qui a au maximum quelques minutes ( secondes même plus probablement ).
Utiliser SPIP pour faire un twitter-like c'est comme essayer d'enfoncer un marteau dans un mur à l'aide d'un clou…
Comme je connais très bien SPIP et que je suis assez bien rentré dans ses concepts de boucles et balises je pense qu'il est intéressant de jeter un coup d'oeil à Seenthis.
Maintenant, et même sans avoir regardé le code ou les possibilités du programme, je ne vois pas comment on peut faire quelque chose de suffisamment réactif à partir de SPIP 2.1 pour en faire un "twitter like". Peu ou pas de Javascript ni de xmlhttprequest pour la mise à jour, Pas de bdd de type "map-reduce" derrière, d'entrée de jeu on sent que pour un passage à l'échelle on risque d'être sérieusement handicapé.
Même si j'adore SPIP, j'ai quand même comme l'auteur du premier commentaire de nombreux doutes sur la pertinence de l'architecture de départ. Il me semble qu'il aurait été plus judicieux de construire quelque chose autour d'Ejabberd/Mnesia - partir sur de l'Erlang/XMPP c'est déjà beaucoup plus rassurant pour les performances à forte charge ( dizaines de milliers d'utilisateurs simultanés ).
y'a des trucs cool qui arrivent dans mesa qui ont besoin de ce kernel (compteurs de performances et OpenCL).
OpenCL n'est pas ce que j'appelle un truc cool, mais un truc ABSOLUMENT ESSENTIEL !!!!
;-)
Félicitations poour le travail sur nouveau au passage. Je n'achèterai pas du Nvidia quand même, mais je tire mon chapeau à tout ceux qui se battent( et à mon avis le terme n'est pas trop fort) pour réaliser des drivers graphiques libres : nouveau, Lima, etc…
Donc le schema n'a de sécurisé que le fait qu'il soit inhabituel et non courant. Et on peut dire autant de "mettre ton repertoire windows sur D:/win32", qui arrète (ou du moins à l'époque, il y a 10 ans) une bonne part des malwares qui hardcodent des chemins.
Merci d'avoir compris ce que j'ai voulu décrire assez rapidement. Le "D:/Win32" m'a aussi rappelé de vieux souvenirs ;-)
C'est aussi une des raisons pour laquelle je suis très défavorable à la LSB : si tout le monde range ses bijoux dans la boîte à bijoux de la salle de bain les cambriolages durent moins de 10 mn - et les chances de se faire prendre sont faibles. Si chacun range ses bijoux dans un endroit différent c'est beaucoup plus difficile… et le risque pour le cambrioleur augmente à chaque minute, ce qui a de bonnes chances de le faire renoncer.
Donc et pour revenir au sujet de l'article je suis très favorable à ce nouveau format de paquet.
C'était un exemple rapide et non développé, un peu comme le commentaire que j'ai critiqué, assez - et avec du recul trop - vertement j'avoue.
L'architecture proposée n'est valable que pour des applications très particulières - multithreadées, sans état, etc etc… c'est sûr qu'il ne s'agit pas de faire tourner Libreoffice !
Mon objectif était avant tout de sortir de la pensée unique qui consiste à dire sécurité = mises à jour.
Peut-être aujourd'hui est-ce simple, mais dans mon souvenir ( Knoppix 3.2 ) ça ne l'était pas vraiment.
Du coup j'étais allé faire un tour du côté du Morphix d'abord, puis j'ai découvert Thinstation que j'ai longtemps utilisé pour de petits projets. J'avais réalisé d'ailleurs à cette époque la traduction française de TS-O-matic dont je trouvais le concept absolument génial.
Si les concepts de TS sont excellents, la fréquence de mise à jour des paquetages était assez catastrophique. Le passage sur base CRUX de la 5.0 a probablement amélioré les choses, mais l'inflation en taille est pour moi insupportable - si on veut du lourd autant partir d'une debian…
Depuis que j'ai découvert Tiny Core Linux je retrouve le même plaisir de "bricolage" qu'à l'époque de Thinstation - à savoir créer des terminaux mono-applicatifs en boot PXE.
Je dois d'ailleurs à Knoppix d'avoir "redécouvert" le boot PXE car sa mise en oeuvre était d'une simplicité déconcertante. Et puis la mise à jour des drivers était exemplaire : c'était la distribution qui exploitait le mieux le matériel récent. Ceci dit elle restait dans mon esprit un "proof of concept" par la quantité assez invraisemblable d'applications largement redondantes qu'elle proposait.
Peut-être cette nouvelle version est-elle l'occasion de voir si la remasterisation est vraiment devenue simple - mais j'imagine mal qu'elle puisse être devenue aussi simple que dans TCL ( Tiny Core Linux ).
Voilà, ce type de commentaire c'est ce que je reproche souvent à Linuxfr : une vision totalitaire, conservatrice et archaïque de l'informatique.
Comme si un ordinateur c'était forcément un CPU, un disque dur et un ou plusieurs OS en multiboot forcément installés en R/W sur le disque dur. C'est à dire l'IBM PC AT des origines.
Ce que tu viens d'écrire est une des visions possibles de la sécurité ( qui plus est totalement dépendante des développeurs des libs pour la correction des failles de sécurité - ce qui est absolument inacceptable pour moi ). La sécurité est ici déléguée à des tiers jugés "de confiance" : développeurs de libs et réalisateurs de paquetages logiciels.
Imaginons la situation suivante : 3 CPU en load balancing et un OS en read-only. En permanence 2 sur les 3 fonctionnent et le 3ème est en situation de reboot. Imaginons que l'on cycle le reboot de l'OS sur chacun des CPU toutes les 2 mn ( si 2 mn est le temps de reboot de l'OS sur le CPU ): dans le pire des cas une faille de sécurité ne peut être exploitée que pendant 6 mn. Et un Hacker ne fait pas grand chose en 6 mn. Sauf s'il sait PRECISEMENT ce qu'il cherche. Et toutes les 6 mn il va devoir réitérer son exploit de 0. A mon avis il va être vite dégoûté…
C'est une autre vision de la sécurité qui ne repose pas sur la rapidité de correction des failles de sécurité mais sur l'impossibilité de les exploiter efficacement.
Celui qui mise uniquement sur les patchs et correctifs de sécurité n'a pas vraiment besoin de sécurité…
La bureautique c'est du html/js avec le css adéquat, les présentations c'est du html/js avec le css adéquat, les graphiques c'est dojotoolkit, et les tableaux/calculs c'est du SQL 92 ;-D. Pour le travail collaboratif le tout est sur un logiciel de suivi de version : CVS/Subersion/autres…
Mais je recherche toujours un bon editeur de CSS pour placer mes "div" aussi précisemment que dans Scribus. Ou plutôt j'aimerais que Scribus devienne un éditeur de CSS :-)
Sinon les tableurs je n'en pense que du mal - ils servent à tout mais surtout à n'importe quoi aujourd'hui. Le nombre de documents Word dont la mise en page est faite avec des tableaux et des cellules… l'abus de tableurs est dangereux pour la santé mentale.
Ceci dit je dois aux tableaux croisés dynamiques de MS office des tonnes de rapports bourrés de graphiques réalisés en 2h chrono qui m'ont permis de passer des heures devant ma console de jeu. Donc merci MS.
On parlait de comparer VP8 et x/H264 sur un cas concret là, pas de Wayland ;-)
Effectivement Wayland devrait le permettre. Sauf que personnellement je m'en moque : toutes mes applications se lancent automatiquement en plein écran via compiz, j'en ai une par bureau virtuel et j'ai 16 bureaux virtuels. Parce que faire glisser des fenêtres à longueur de temps à la souris et les redimensionner toutes les 5 mn je ne supporte pas. Et parce que j'aime travailler ainsi, à grands coups de ctrl+droite et gauche pour passer d'une application à l'autre.
A condition de placer les conditions de base - qui correspondent à ce que l'on veut faire :
driver "screen" de VLC ( la capture d'écran de VLC quoi )
résolution d'écran de 1024x768
une fenêtre de 300x300 que l'on déplace sur le bureau pendant 10s.
Et on compare la charge CPU pendant la capture+encodage, la taille du fichier obtenue et la qualité de l'image sur un screenshot après pause.
Es-tu toujours aussi sûr de toi ? Le VP8 a été plutôt optimisé spécialement pour cet usage = tableau blanc partagé+fenêtre de webcam. Le H264 a été optimisé pour l'encodage de films.
alors que tout ce qu'on demandait c'était d'avoir un affichage fluide avec des effets visuels utiles et accésoirement sexy.
Même pas. Tout ce que je demandais c'était de rentabiliser le prix de mon GPU. Et en désactivant toutes les options c'est exactement ce que j'ai obtenu.
Déplacer des fenêtres, changer de bureau, et ne jamais entendre le ventilo de mon portable se déclencher. Voir mon CPU à 8%. Que du bonheur compiz.
Un poste client qui consomme 200 watts avec une carte réseau utilisée à 0,1%, un GPU utilisé à 0,1% et un taux d'occupation des disque durs < 1%, oui, et c'est aussi ça le problème qu'il faut résoudre.
Sinon il y a le VP8 qui est extrêmement efficace pour tous les objets/fonds fixes ( je me demande même s'il les compresse… ).
Traiter séparément le texte les images et la vidéo serait techiquement optimal, mais créerait selon moi une complexité abominable du côté du serveur graphique et des drivers : texte envoyé en vectoriel, images compressées par le CPU, vidéo compressé par le GPU, le serveur graphique qui se charge d'assembler tout ça en gérant les synchronisations avant de l'envoyer à la carte réseau… il faut être masochiste pour programmer ça °_° ( ou avoir programmé X avant, ce qui revient à peu près au même ;-) )
Compter sur les progrès incessants des chipsets graphiques en terme de performances et celles des encodeurs vidéos (H265/VP9) qui les accompagnent me paraît nettement moins risqué.
La première fois que j'ai installé Compiz avec les drivers i915 intel sur mon portable le ventirad a gagné 5 années de vie… Je pense que les puces graphiques sont encore aujourd'hui TRES largement sous-exploitées.
D'ailleurs il me semble que les dernières puces Mali, la série des T600 intègrent l'encodage/décodage hard en VP8, ce qui fait que je suis l'évolution du driver Lima de TRES TRES près en prévision d'un achat futur ;-)
Bien plus gourmand ? Et bien ce n'est franchement pas l'impression que j'ai eu en utilisant VLC.
Peut-être est-ce un problème d'implémentation ou de paramètres, mais l'encodage du "screen" en h264 et en VP8 sous VLC c'est le jour et la nuit question consommation CPU.
Exactement - idem pour la place prise par les OS - gaspillage sans fin de ressources et d'énergie juste pour taper du texte et inclure 2/3 images ou vidéos.
Sans compter l'importance du point de vue de la sécurité. c'est surtout sur ce point que l'affichage distant est une quasi obligation en entreprise.
0 données non volatiles sur le poste client, c'est la base de tout projet sérieux de mon point de vue.
[^] # Re: Me reproduire
Posté par Loïc Ibanez . En réponse au sondage Votre métier. Évalué à 5.
Comme écrit plus haut ce n'est pas le programme qui est vendu dans le cas de la GPL, c'est le support - généralement - qui représente ce que je considère comme étant une garantie de fonctionnement du logiciel.
Ce que je ne comprends et n'accepte pas c'est que l'on puisse vendre un programme/produit sans en être responsable. Aujourd'hui que l'on prenne un OS MS Windows( payant et fermé ) ou un OS GNU/Linux ( ouvert et gratuit ), personne n'est responsable de son fonctionnement. Pour l'utilisateur les risques et périls sont les mêmes. Si c'est normal et logique dans le cas ouvert et gratuit, je trouve ça complètement anormal et illogique dans le cas payant et fermé. Le CLUF de MS Windows et de nombreux autres logiciels ne devrait pas être légal.
# Me reproduire
Posté par Loïc Ibanez . En réponse au sondage Votre métier. Évalué à 2.
Mon vrai boulot c'est de me reproduire.
Mais sinon j'aime bien taper 2/3 lignes de code de temps en temps dans des langages ésotériques (Python, Erlang) pour essayer de rencontrer la logique de leur concepteurs. Et lancer des trolls sur Debian, la LSB, et un tas de choses que j'estime conservatrices et qui m'irritent.
Je ne suis pas autant pro-libre qu'anti-CLUF-débiles. Comment peut-on oser vendre un logiciel en déclinant toute responsabilité ? Ça me semble même légalement attaquable.
Imaginez qu'un constructeur automobile vende un véhicule en déclinant toute responsabilité : personne ne l'achèterai. Pour moi c'est la même chose en informatique : si c'est vendu c'est que le fonctionnement est garanti par ceux qui programment. Sinon ça ne devrait pas pouvoir légalement être vendu.
[^] # Re: Je ne travaille pas dans l'informatique ni dans l'enseignement ou la recherche.
Posté par Loïc Ibanez . En réponse au sondage Votre métier. Évalué à 2.
Tant qu'ils ne tombent pas le taf est fait ;-D
[^] # Re: SPIP ?
Posté par Loïc Ibanez . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 0.
SPIP c'était le bon vieux temps des modems 56ko, son système de cache des articles ( bien avant l'utilisation massive des reverse proxy ) faisait des merveilles à l'époque pour limiter la charge du serveur par rapport aux "postnuke". Et ses capacités de personnalisation allaient très très loin. En terme de publication on pouvait tout faire à partir de SPIP.
Mais aujourd'hui j'ai désactivé le cache de pratiquement tout mes navigateurs parce que la récupération d'une information via le réseau est plus rapide que sur le disque dur. Le débit de toutes les pages html du monde est infinitésimal par rapport au volume du streaming vidéo.
Le résultat d'appel de chaque Hashtag devrait être stocké en Ram ( au minimum les 100 derniers résultats ).
Le cache de SPIP a été conçu pour limiter les appels à la BDD en stockant une page pendant plusieurs heures. C'est exactement à l'opposé du concept d'un "twitter like" dont l'objectif est de délivrer le plus rapidement et massivement possible une information qui a au maximum quelques minutes ( secondes même plus probablement ).
Utiliser SPIP pour faire un twitter-like c'est comme essayer d'enfoncer un marteau dans un mur à l'aide d'un clou…
[^] # Re: SPIP ?
Posté par Loïc Ibanez . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 0.
Premier test sur le site de seenthis, je clique sur #histoire et j'ai… un chargement COMPLET de page… 0_0
Définitivement le système de gestion de cache de SPIP ne me semble pas adapté à la problématique.
L'effort est louable - tous les efforts le sont - mais là il me semble que c'est une impasse.
[^] # Re: SPIP ?
Posté par Loïc Ibanez . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 0.
Je dirais plutôt SPIP 2.1, choix curieux.
Comme je connais très bien SPIP et que je suis assez bien rentré dans ses concepts de boucles et balises je pense qu'il est intéressant de jeter un coup d'oeil à Seenthis.
Maintenant, et même sans avoir regardé le code ou les possibilités du programme, je ne vois pas comment on peut faire quelque chose de suffisamment réactif à partir de SPIP 2.1 pour en faire un "twitter like". Peu ou pas de Javascript ni de xmlhttprequest pour la mise à jour, Pas de bdd de type "map-reduce" derrière, d'entrée de jeu on sent que pour un passage à l'échelle on risque d'être sérieusement handicapé.
Même si j'adore SPIP, j'ai quand même comme l'auteur du premier commentaire de nombreux doutes sur la pertinence de l'architecture de départ. Il me semble qu'il aurait été plus judicieux de construire quelque chose autour d'Ejabberd/Mnesia - partir sur de l'Erlang/XMPP c'est déjà beaucoup plus rassurant pour les performances à forte charge ( dizaines de milliers d'utilisateurs simultanés ).
[^] # Re: OpenCL et Intel
Posté par Loïc Ibanez . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 2.
C'est à peu près ma question et frayeur numéro une à l'heure actuelle, et ce qui me fait reculer indéfiniment l'achat d'un PC.
Je sens que tout ça va finir avec une Cubieboard A20 et un Mali400, du moment que Lima supporte l'OpenCL.
Trop ras-le-bol de la politique un peu libre/un peu non libre d'AMD/Intel/Broadcom et consorts…
Au moins la politique d'Apple et de Nvidia est claire : je sais que je n'en achèterai jamais :-)
[^] # Re: Que du bon
Posté par Loïc Ibanez . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 5.
OpenCL n'est pas ce que j'appelle un truc cool, mais un truc ABSOLUMENT ESSENTIEL !!!!
;-)
Félicitations poour le travail sur nouveau au passage. Je n'achèterai pas du Nvidia quand même, mais je tire mon chapeau à tout ceux qui se battent( et à mon avis le terme n'est pas trop fort) pour réaliser des drivers graphiques libres : nouveau, Lima, etc…
[^] # Re: Argument bidon!
Posté par Loïc Ibanez . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 1.
Merci.
Je connaissais le second lien, mais pas le premier. Je vais regarder tout ça de plus près.
[^] # Re: Miam
Posté par Loïc Ibanez . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 0.
Merci d'avoir compris ce que j'ai voulu décrire assez rapidement. Le "D:/Win32" m'a aussi rappelé de vieux souvenirs ;-)
C'est aussi une des raisons pour laquelle je suis très défavorable à la LSB : si tout le monde range ses bijoux dans la boîte à bijoux de la salle de bain les cambriolages durent moins de 10 mn - et les chances de se faire prendre sont faibles. Si chacun range ses bijoux dans un endroit différent c'est beaucoup plus difficile… et le risque pour le cambrioleur augmente à chaque minute, ce qui a de bonnes chances de le faire renoncer.
Donc et pour revenir au sujet de l'article je suis très favorable à ce nouveau format de paquet.
[^] # Re: Miam
Posté par Loïc Ibanez . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 1.
C'était un exemple rapide et non développé, un peu comme le commentaire que j'ai critiqué, assez - et avec du recul trop - vertement j'avoue.
L'architecture proposée n'est valable que pour des applications très particulières - multithreadées, sans état, etc etc… c'est sûr qu'il ne s'agit pas de faire tourner Libreoffice !
Mon objectif était avant tout de sortir de la pensée unique qui consiste à dire sécurité = mises à jour.
Petite piqure de rappel.
# Remasterisation simple ?
Posté par Loïc Ibanez . En réponse à la dépêche Knoppix : un vent d'enthousiasme. Évalué à 0.
Peut-être aujourd'hui est-ce simple, mais dans mon souvenir ( Knoppix 3.2 ) ça ne l'était pas vraiment.
Du coup j'étais allé faire un tour du côté du Morphix d'abord, puis j'ai découvert Thinstation que j'ai longtemps utilisé pour de petits projets. J'avais réalisé d'ailleurs à cette époque la traduction française de TS-O-matic dont je trouvais le concept absolument génial.
Si les concepts de TS sont excellents, la fréquence de mise à jour des paquetages était assez catastrophique. Le passage sur base CRUX de la 5.0 a probablement amélioré les choses, mais l'inflation en taille est pour moi insupportable - si on veut du lourd autant partir d'une debian…
Depuis que j'ai découvert Tiny Core Linux je retrouve le même plaisir de "bricolage" qu'à l'époque de Thinstation - à savoir créer des terminaux mono-applicatifs en boot PXE.
Je dois d'ailleurs à Knoppix d'avoir "redécouvert" le boot PXE car sa mise en oeuvre était d'une simplicité déconcertante. Et puis la mise à jour des drivers était exemplaire : c'était la distribution qui exploitait le mieux le matériel récent. Ceci dit elle restait dans mon esprit un "proof of concept" par la quantité assez invraisemblable d'applications largement redondantes qu'elle proposait.
Peut-être cette nouvelle version est-elle l'occasion de voir si la remasterisation est vraiment devenue simple - mais j'imagine mal qu'elle puisse être devenue aussi simple que dans TCL ( Tiny Core Linux ).
[^] # Re: J'en parlais
Posté par Loïc Ibanez . En réponse à la dépêche Bonita BPM Community. Évalué à 1.
Mon cerveau hurle FOUTAISES ! dès que je lis : BPM, ERP, CRM, ITIL et… java…
[^] # Re: Miam
Posté par Loïc Ibanez . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 6.
Voilà, ce type de commentaire c'est ce que je reproche souvent à Linuxfr : une vision totalitaire, conservatrice et archaïque de l'informatique.
Comme si un ordinateur c'était forcément un CPU, un disque dur et un ou plusieurs OS en multiboot forcément installés en R/W sur le disque dur. C'est à dire l'IBM PC AT des origines.
Ce que tu viens d'écrire est une des visions possibles de la sécurité ( qui plus est totalement dépendante des développeurs des libs pour la correction des failles de sécurité - ce qui est absolument inacceptable pour moi ). La sécurité est ici déléguée à des tiers jugés "de confiance" : développeurs de libs et réalisateurs de paquetages logiciels.
Imaginons la situation suivante : 3 CPU en load balancing et un OS en read-only. En permanence 2 sur les 3 fonctionnent et le 3ème est en situation de reboot. Imaginons que l'on cycle le reboot de l'OS sur chacun des CPU toutes les 2 mn ( si 2 mn est le temps de reboot de l'OS sur le CPU ): dans le pire des cas une faille de sécurité ne peut être exploitée que pendant 6 mn. Et un Hacker ne fait pas grand chose en 6 mn. Sauf s'il sait PRECISEMENT ce qu'il cherche. Et toutes les 6 mn il va devoir réitérer son exploit de 0. A mon avis il va être vite dégoûté…
C'est une autre vision de la sécurité qui ne repose pas sur la rapidité de correction des failles de sécurité mais sur l'impossibilité de les exploiter efficacement.
Celui qui mise uniquement sur les patchs et correctifs de sécurité n'a pas vraiment besoin de sécurité…
[^] # Re: macosx / dmg
Posté par Loïc Ibanez . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 3.
Oui, c'est le même système que les .scm de tiny core linux ou l'appimagekit format.
Il me semble que c'est Knoppix qui avait introduit ça à l'époque ( des cloop au début - des squashfs aujourd'hui)
L'avantage c'est qu'il n'y a aucune fragmentation et que l'on peut monter intégralement l'application en ramdisk. Ce que je trouve TRES pratique.
[^] # Re: Argument bidon!
Posté par Loïc Ibanez . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à -1.
C'est pas dégueu, c'est mon rêve °_°
# Amaya...
Posté par Loïc Ibanez . En réponse au sondage Quelle est votre suite bureautique principale ou préférée ?. Évalué à -1.
La bureautique c'est du html/js avec le css adéquat, les présentations c'est du html/js avec le css adéquat, les graphiques c'est dojotoolkit, et les tableaux/calculs c'est du SQL 92 ;-D. Pour le travail collaboratif le tout est sur un logiciel de suivi de version : CVS/Subersion/autres…
Mais je recherche toujours un bon editeur de CSS pour placer mes "div" aussi précisemment que dans Scribus. Ou plutôt j'aimerais que Scribus devienne un éditeur de CSS :-)
Sinon les tableurs je n'en pense que du mal - ils servent à tout mais surtout à n'importe quoi aujourd'hui. Le nombre de documents Word dont la mise en page est faite avec des tableaux et des cellules… l'abus de tableurs est dangereux pour la santé mentale.
Ceci dit je dois aux tableaux croisés dynamiques de MS office des tonnes de rapports bourrés de graphiques réalisés en 2h chrono qui m'ont permis de passer des heures devant ma console de jeu. Donc merci MS.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 1.
On parlait de comparer VP8 et x/H264 sur un cas concret là, pas de Wayland ;-)
Effectivement Wayland devrait le permettre. Sauf que personnellement je m'en moque : toutes mes applications se lancent automatiquement en plein écran via compiz, j'en ai une par bureau virtuel et j'ai 16 bureaux virtuels. Parce que faire glisser des fenêtres à longueur de temps à la souris et les redimensionner toutes les 5 mn je ne supporte pas. Et parce que j'aime travailler ainsi, à grands coups de ctrl+droite et gauche pour passer d'une application à l'autre.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 1.
Je suis d'accord pour le benchmark.
A condition de placer les conditions de base - qui correspondent à ce que l'on veut faire :
Et on compare la charge CPU pendant la capture+encodage, la taille du fichier obtenue et la qualité de l'image sur un screenshot après pause.
Es-tu toujours aussi sûr de toi ? Le VP8 a été plutôt optimisé spécialement pour cet usage = tableau blanc partagé+fenêtre de webcam. Le H264 a été optimisé pour l'encodage de films.
[^] # Re: priorités?
Posté par Loïc Ibanez . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 2.
Même pas. Tout ce que je demandais c'était de rentabiliser le prix de mon GPU. Et en désactivant toutes les options c'est exactement ce que j'ai obtenu.
Déplacer des fenêtres, changer de bureau, et ne jamais entendre le ventilo de mon portable se déclencher. Voir mon CPU à 8%. Que du bonheur compiz.
[^] # Re: PetiteVidéo forte intéressante
Posté par Loïc Ibanez . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 1.
Fabrice Bellard.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 0.
Un poste client qui consomme 200 watts avec une carte réseau utilisée à 0,1%, un GPU utilisé à 0,1% et un taux d'occupation des disque durs < 1%, oui, et c'est aussi ça le problème qu'il faut résoudre.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Sinon il y a le VP8 qui est extrêmement efficace pour tous les objets/fonds fixes ( je me demande même s'il les compresse… ).
Traiter séparément le texte les images et la vidéo serait techiquement optimal, mais créerait selon moi une complexité abominable du côté du serveur graphique et des drivers : texte envoyé en vectoriel, images compressées par le CPU, vidéo compressé par le GPU, le serveur graphique qui se charge d'assembler tout ça en gérant les synchronisations avant de l'envoyer à la carte réseau… il faut être masochiste pour programmer ça °_° ( ou avoir programmé X avant, ce qui revient à peu près au même ;-) )
Compter sur les progrès incessants des chipsets graphiques en terme de performances et celles des encodeurs vidéos (H265/VP9) qui les accompagnent me paraît nettement moins risqué.
La première fois que j'ai installé Compiz avec les drivers i915 intel sur mon portable le ventirad a gagné 5 années de vie… Je pense que les puces graphiques sont encore aujourd'hui TRES largement sous-exploitées.
D'ailleurs il me semble que les dernières puces Mali, la série des T600 intègrent l'encodage/décodage hard en VP8, ce qui fait que je suis l'évolution du driver Lima de TRES TRES près en prévision d'un achat futur ;-)
[^] # Re: prise en charge du protocole RDP
Posté par Loïc Ibanez . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 1.
Bien plus gourmand ? Et bien ce n'est franchement pas l'impression que j'ai eu en utilisant VLC.
Peut-être est-ce un problème d'implémentation ou de paramètres, mais l'encodage du "screen" en h264 et en VP8 sous VLC c'est le jour et la nuit question consommation CPU.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Loïc Ibanez . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 1.
Exactement - idem pour la place prise par les OS - gaspillage sans fin de ressources et d'énergie juste pour taper du texte et inclure 2/3 images ou vidéos.
Sans compter l'importance du point de vue de la sécurité. c'est surtout sur ce point que l'affichage distant est une quasi obligation en entreprise.
0 données non volatiles sur le poste client, c'est la base de tout projet sérieux de mon point de vue.