À ma connaissance, Qt est l'une des bibliothèques avec la meilleure documentation qu'il soit... Et vu les domaines couverts par les classes de Qt, c'est nickel quoi (Gtk ne couvre finalement qu'une partie de QtGui, il faut y ajouter la stl pour QtCore, libxml pour QtXml, libwebkit-gtk pour QtWebkit ... et la documentation sur tout ça n'est centralisée nulle part)
Quant à Solaris, ça vivote toujours autour des évolutions d'opensolaris, non ?
L'annonce n'est pas passée sur Linuxfr, mais depuis l'acquisition par Oracle, ça pue vraiment pour Solaris et OpenSolaris.
Notamment le groupe de direction d'OpenSolaris (? Opensolaris Governing Board), chargé de gérer les interactions avec la communauté, a menacé de se faire hara kiri si Oracle ne se bouge pas le cul pour au moins dire ce qu'il advient de solaris/opensolaris. La version 2010.1H, prévue comme son nom l'indique pour la première moitié de l'année 2010 (et encore, initialement c'était février, puis mars), n'est pas encore sortie... Aucune nouvelle version depuis 13 mois quand même...
Certes, mais ton application C n'est pas toute seule dans son coin.
Elle va par exemple lire l'adresse IP depuis la ligne de commande, ou dans une interface graphique, ou depuis un fichier de configuration.
Toutes les expressions régulières, tous les validateurs des champs... sont-ils corrects ?
Sinon Java a, depuis au moins Java 1.4.2 (flemme de remonter plus avant dans le temps), une classe InetAddress gérant l'IPv4 et l'IPv6...
Même maintenant, pour être portable proprement avec certains compilateurs tordus, pour avoir une gestion propre de l'unicode partout, une API "claire" et lisible... il vaut mieux faire des doublons de la STL.
Également, pour réaliser de l'introspection sans passer par le RTTI, le choix de moc me semble raisonnable.
Quand tu dis "gros morceaux de pré-processeur partout", je pense d'ailleurs que tu n'as pas vu de code en Qt depuis très longtemps...
Faut que je trouve comment se debarasser de cet héritage que je n'apprécie pas trop
Lequel ?
Tu peux n'hériter que de QWidget par exemple et faire ceci :
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from PyQt4 import uic, QtCore, QtGui
import sys
class myForm(QtGui.QWidget):
def machin(self):
print "test !"
Tu dois me confondre avec quelqu'un d'autre. Moi j'ai juste dis que le binding était pourris.
Effectivement, mea culpa…
Sinon pour le chose.setupUi(chose), c'est un choix dans mon implémentation…
J'aurais pu/du créer un QWidget à part et faire chose.setupUi(mon_beau_widget)
Non... Je parle de PyQT depuis le départ.
Alors n'affirme pas que Qt n'a pas d'équivalent à GTKBuilder, affirme que PyQt ne fait pas bien son boulot en choisissant de ne pas implémenter de bindings pour QUITools…
Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.
Ce n'est plus le cas sur les dernières versions de PyQt, même en Python 2…
Sinon pour ton histoire de signaux et slots je vois pas non plus le problème…
Voici un exemple de code :
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from PyQt4 import uic, QtCore, QtGui
import sys
app = QtGui.QApplication(sys.argv)
(f, c) = uic.loadUiType("test.ui")
class m(f, c):
def machin(self):
print "test !"
Ha en fait tu confonds Qt et les bindings Qt pour Python, c'est ça ?
Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html
- Le fait que Qt impose (c'est pas forcement vrai, mais c'est difficile de sortir du moule) vraiment la façon de penser Qt, l'utilisation de la lib Qt.
Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.
De plus, il y a dedans des choses très utiles comme GTKBuilder, que Qt n'as pas.
Hoo fud.
Qt a Qt Designer pour dessiner les fenêtres, et QUILoader pour charger les .ui dynamiquement.
La décision de normaliser et simplifier l'accès à la configuration des pilotes et du noyau te paraît stupide ? Fichtre !
Après, libre à toi de monter le sysfs où tu veux, même dans un /etc/sys si ça te plaît…
Le hurd supprime bien /usr hein.
Et la présence d'éléments qui ne soient pas liées aux processus ou à l'aspect logiciel du système dans /proc est plus ou moins perturbante.
Pourquoi avoir un /proc/acpi ? Je veux dire, quelle est la logique derrière ce placement ?
Au passage, c'est mignon de taper sur /sys, mais ça date déjà de plus de 5 ans...
En fait c'était pas forcément très malin de mettre tout ce bordel dans /proc (d'où un surnom de /porc...) au départ.
Donc on ne fait que corriger des erreurs du passé...
Ce n'est ni le travail de KDE, ni le travail de GNOME.
C'est le boulot du Network Manager…
Perso je trouvais ça trop pénible donc je fais tout en console avec du ifup/ifdown, et ça «juste marche»…
Au contraire, il y a de nombreux cas où je trouve ça très pratique.
Dans le cas de X.org ça permet de se retrouver avec un fichier de configuration par pilote plutôt qu'un gros fichier global, simplifiant donc la gestion des mises à jour en cas de modification des options par défaut d'un fichier de conf.
Et y'a encore un xorg.conf "global" si nécessaire.
- Une interface graphique qui ne crashe pas les fenêtres d'applications quand elle s'arrête.
+1, on peut espérer que dans le "mouvement DRI2" ce changement devienne implémentable...
- Une interface graphique en CTRL+ALT+F7 , ou CTRL+ALT+F9 , mais qui me laisse la possibilité, pour d'autres ressources , d'en lancer une autre en CTRL+ALT+F8 ou CTRL+ALT+F10 ...
- Des consoles virtuelles ( ttyv ) en mode texte toujours accessibles.
Heu, il me semble avoir ça depuis des années. À une époque je faisais tourner Looking Glass sur un serveur X en Ctrl+Alt+F8, et j'avais encore mes consoles texte.
- Dans les outils des gestionnaires de bureau, des machins qui touchent au système, à la compil, et aux choix de modules du noyau.
Un make xconfig intégré à KDE ou Gnome ?
- une simple console accessible permettant de lancer des applications graphiques, que ce soit une console texte ou un "fond d'écran+menu K/Gnome/XFCE "
Yakuake ? Krunner ? Ou un retour de l'applet d'exécution d'une commande ça serait fun tiens, à coder si ça n'existe pas...
- un outil me permettant de réellement choisir les drivers à appliquer à tel ou tel matos, avec une sauvegarde simple du mode précédent. Pareil pour les logiciels-sous-couche aux applications ( ALSA, OSS ... )
Mauvais problème : il faudrait ne pas avoir de choix pour le pilote, avoir un seul pilote qui soit fonctionnel, libre, intégré au noyau, stable...
- Une interface facilement modulable pour réduire l'épaisseur de ces énormes bordures de fenêtres , ou de la même façon cliquer pour avoir la possibilité de restaurer la session ou de choisir, en fonction des sessions, le lancement de telle ou telle application.
Heu, il me semble qu'il y a tout ça dans KDE...
- Une possibilité de jouer avec toutes les résolutions d'écran, soit en " lissant " par le calcul la résolution obtenue, soit en laissant tel quel ( avec comme conséquences : pixellisation et flou sur les LCD ) .
Un écran LCD est fait pour une seule résolution, ne cherche pas...
- plus généralement, la possibilité facilement de jouer avec toutes les entrées sorties, en désactivant simplement Bluetooth Webcam ou Wifi ,ou modifier le keymap " à la volée".
Perso je change à la volée le keymap uniquement de mon typematrix avec un simple setxkbmap -device 42 fr bepo...
Mais sinon, je suis d'accord avec l'auteur du journal: tout ce qui s'est passé ces 2 dernières années avec l'intégration de HAL et le nouveau grub a été très mal documenté , très mal expérimenté, et les méthodes "pour s'en sortir' sont beaucoup moins connues que lorsqu'il s'agissait de faire un simple X -configure , démarrer X avec ce xorg.conf.new , et le tuer à l'aide d'un CTRL+ALT+BACKSPACE .
D'ailleurs sur le Web, à ce sujet, c'est le désert le plus total...
C'est pire que ça : tu trouves pas d'aide parce que ça va dépendre de la distribution, de sa version et de l'âge du capitaine.
Truc drôle : tu parles de l'intégration de HAL à X.org... Tu sais que ce n'est plus le cas désormais et que xorg.conf fait son retour sous la forme d'un dossier xorg.conf.d ?
Regarde, ils ont enlevé des trucs de /proc, c'est affreux, c'est parti dans /sys...
Regarde, ton devfs est dynamique, c'est terrible.
Diantre, où est mon /etc/lilo.conf ? Ha, c'est grub, donc /boot/grub/menu.lst ? Ho mon dieu, /boot/grub/grub.cfg ? Ça ne finira jamais ?
Puis bon, sous Windows c'est pas mieux hein...
Où sont les autoexec.bat, les command.com, les C:\Documents and Settings, le NTLDR...
C'est vrai que c'est assez terrible pour nous "informaticiens" : étant donné le flot continu de changement, quand on regarde légèrement en arrière, on est vite impressionné et submergé par le nombre de changements....
Nouveau souci : il n'y a pas de bouton pour quitter X. J'ai tenté des "init" avec un petit chiffre, mais rien ne m'a rendu la main avec une console texte pure.
C'est si compliqué d'arrêter le service kdm/gdm ?
Je veux dire, je fais ça sur diverses distribs depuis au moins 4 ans, le init N n'a jamais été un gage de bon fonctionnement (exemple : debian par défaut en init 2 y compris avec le serveur X, alors qu'un init 2 sur une mandriva va arrêter le serveur X).
- dégueulasse : si, car pour moi la fin ne justifie pas les moyens. En utilisant les mêmes armes qu'Apple, la MoFo a perdu des point dans l'estime que j'avais d'elle. Qu'elle refuse de payer la licence, je la comprend à 100%, qu'elle refuse de faire une interface sur le backend et laisser la responsabilité à l'OS, en attendant que WebM se démocratise, je ne l'accepte pas.
C'est marrant, à titre personnel, je suis fort reconnaissant à la MoFo d'avoir agi comme ça, pleinement satisfait de leurs choix, et plus enclin à utiliser leurs produits sachant que eux au moins respectent leurs principes.
Faut que tu m'expliquer comment tu peux voir Flash+H264 être mieux que HTML5+H264 (car H.264 est la, qu'on le veuille ou non).
Boarf, à choisir entre la peste et le cholera... J'ai choisi la peste, désolé.
Plus sérieusement, des solutions libres arrivent à lire le code Flash d'un site comme youtube il me semble.
Sinon, pour le fait de faire une sandbox : c'est une sandbox pour tous les plugins, et donc pour d'éventuels plugins libres (exemple : Java, mplayerplugin...)
Et en quoi Flash a une forme de suprématie sur le web ? Perso, j'en ai rien à carrer des vidéos en ligne, je les désactive par défaut et je ne m'en porte pas plus mal. (Mon client youtube est youtube-dl)
[^] # Re: PyGtk/Python3
Posté par Pinaraf . En réponse à la dépêche Python 2.7. Évalué à 2.
[^] # Re: erreur de ta part (!)
Posté par Pinaraf . En réponse au journal Qui a dit qu'AIX était mort ?. Évalué à 6.
L'annonce n'est pas passée sur Linuxfr, mais depuis l'acquisition par Oracle, ça pue vraiment pour Solaris et OpenSolaris.
Notamment le groupe de direction d'OpenSolaris (? Opensolaris Governing Board), chargé de gérer les interactions avec la communauté, a menacé de se faire hara kiri si Oracle ne se bouge pas le cul pour au moins dire ce qu'il advient de solaris/opensolaris. La version 2010.1H, prévue comme son nom l'indique pour la première moitié de l'année 2010 (et encore, initialement c'était février, puis mars), n'est pas encore sortie... Aucune nouvelle version depuis 13 mois quand même...
[^] # Re: Stockage d'adresses IP : utiliser un type générique
Posté par Pinaraf . En réponse à la dépêche La pénurie d'adresse IPv4 sera-t-elle pour le 12/12/2012 ?. Évalué à 5.
Elle va par exemple lire l'adresse IP depuis la ligne de commande, ou dans une interface graphique, ou depuis un fichier de configuration.
Toutes les expressions régulières, tous les validateurs des champs... sont-ils corrects ?
Sinon Java a, depuis au moins Java 1.4.2 (flemme de remonter plus avant dans le temps), une classe InetAddress gérant l'IPv4 et l'IPv6...
[^] # Re: PyGtk/Python3
Posté par Pinaraf . En réponse à la dépêche Python 2.7. Évalué à 2.
Également, pour réaliser de l'introspection sans passer par le RTTI, le choix de moc me semble raisonnable.
Quand tu dis "gros morceaux de pré-processeur partout", je pense d'ailleurs que tu n'as pas vu de code en Qt depuis très longtemps...
[^] # Re: PyGtk/Python3
Posté par Pinaraf . En réponse à la dépêche Python 2.7. Évalué à 2.
Lequel ?
Tu peux n'hériter que de QWidget par exemple et faire ceci :
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from PyQt4 import uic, QtCore, QtGui
import sys
class myForm(QtGui.QWidget):
def machin(self):
print "test !"
app = QtGui.QApplication(sys.argv)
(uiForm, container) = uic.loadUiType("test.ui")
chose = myForm()
uiGenerator = uiForm()
uiGenerator.setupUi(chose)
chose.show()
app.exec_()
Je vois pas pourquoi l'héritage de QWidget serait un problème…
[^] # Re: PyGtk/Python3
Posté par Pinaraf . En réponse à la dépêche Python 2.7. Évalué à 3.
T'as alors une liste de slots avec un bouton + en dessous de la liste…
[^] # Re: PyGtk/Python3
Posté par Pinaraf . En réponse à la dépêche Python 2.7. Évalué à 2.
Effectivement, mea culpa…
Sinon pour le chose.setupUi(chose), c'est un choix dans mon implémentation…
J'aurais pu/du créer un QWidget à part et faire chose.setupUi(mon_beau_widget)
[^] # Re: PyGtk/Python3
Posté par Pinaraf . En réponse à la dépêche Python 2.7. Évalué à 1.
Alors n'affirme pas que Qt n'a pas d'équivalent à GTKBuilder, affirme que PyQt ne fait pas bien son boulot en choisissant de ne pas implémenter de bindings pour QUITools…
Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.
Ce n'est plus le cas sur les dernières versions de PyQt, même en Python 2…
Sinon pour ton histoire de signaux et slots je vois pas non plus le problème…
Voici un exemple de code :
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from PyQt4 import uic, QtCore, QtGui
import sys
app = QtGui.QApplication(sys.argv)
(f, c) = uic.loadUiType("test.ui")
class m(f, c):
def machin(self):
print "test !"
chose = m()
chose.setupUi(chose)
chose.show()
app.exec_()
Dans le fichier test.ui j'ai une fenêtre avec un slot machin() défini et connecté au clic sur un bouton… Et ça marche…
[^] # Re: PyGtk/Python3
Posté par Pinaraf . En réponse à la dépêche Python 2.7. Évalué à 3.
Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html
- Le fait que Qt impose (c'est pas forcement vrai, mais c'est difficile de sortir du moule) vraiment la façon de penser Qt, l'utilisation de la lib Qt.
Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.
[^] # Re: Évolution...
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 2.
Mais /sys me semble logique et légitime, c'est tout…
[^] # Re: PyGtk/Python3
Posté par Pinaraf . En réponse à la dépêche Python 2.7. Évalué à 7.
Hoo fud.
Qt a Qt Designer pour dessiner les fenêtres, et QUILoader pour charger les .ui dynamiquement.
http://doc.trolltech.com/4.6/quiloader.html
Au moins Qt a un bon support du buffer souris.
[^] # Re: Évolution...
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 2.
Après, libre à toi de monter le sysfs où tu veux, même dans un /etc/sys si ça te plaît…
[^] # Re: OOo
Posté par Pinaraf . En réponse au journal gtk-qt-engine, firefox, firefox et firefox :(. Évalué à 2.
[^] # Re: Évolution...
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 2.
Gros coup de vieux, ça fait 7 ans…
[^] # Re: Évolution...
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 3.
Et la présence d'éléments qui ne soient pas liées aux processus ou à l'aspect logiciel du système dans /proc est plus ou moins perturbante.
Pourquoi avoir un /proc/acpi ? Je veux dire, quelle est la logique derrière ce placement ?
Au passage, c'est mignon de taper sur /sys, mais ça date déjà de plus de 5 ans...
[^] # Re: Évolution...
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 3.
Donc on ne fait que corriger des erreurs du passé...
[^] # Re: grub2
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 4.
C'est le boulot du Network Manager…
Perso je trouvais ça trop pénible donc je fais tout en console avec du ifup/ifdown, et ça «juste marche»…
[^] # Re: Évolution...
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 2.
Dans le cas de X.org ça permet de se retrouver avec un fichier de configuration par pilote plutôt qu'un gros fichier global, simplifiant donc la gestion des mises à jour en cas de modification des options par défaut d'un fichier de conf.
Et y'a encore un xorg.conf "global" si nécessaire.
[^] # Re: Évolution...
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 5.
+1, on peut espérer que dans le "mouvement DRI2" ce changement devienne implémentable...
- Une interface graphique en CTRL+ALT+F7 , ou CTRL+ALT+F9 , mais qui me laisse la possibilité, pour d'autres ressources , d'en lancer une autre en CTRL+ALT+F8 ou CTRL+ALT+F10 ...
- Des consoles virtuelles ( ttyv ) en mode texte toujours accessibles.
Heu, il me semble avoir ça depuis des années. À une époque je faisais tourner Looking Glass sur un serveur X en Ctrl+Alt+F8, et j'avais encore mes consoles texte.
- Dans les outils des gestionnaires de bureau, des machins qui touchent au système, à la compil, et aux choix de modules du noyau.
Un make xconfig intégré à KDE ou Gnome ?
- une simple console accessible permettant de lancer des applications graphiques, que ce soit une console texte ou un "fond d'écran+menu K/Gnome/XFCE "
Yakuake ? Krunner ? Ou un retour de l'applet d'exécution d'une commande ça serait fun tiens, à coder si ça n'existe pas...
- un outil me permettant de réellement choisir les drivers à appliquer à tel ou tel matos, avec une sauvegarde simple du mode précédent. Pareil pour les logiciels-sous-couche aux applications ( ALSA, OSS ... )
Mauvais problème : il faudrait ne pas avoir de choix pour le pilote, avoir un seul pilote qui soit fonctionnel, libre, intégré au noyau, stable...
- Une interface facilement modulable pour réduire l'épaisseur de ces énormes bordures de fenêtres , ou de la même façon cliquer pour avoir la possibilité de restaurer la session ou de choisir, en fonction des sessions, le lancement de telle ou telle application.
Heu, il me semble qu'il y a tout ça dans KDE...
- Une possibilité de jouer avec toutes les résolutions d'écran, soit en " lissant " par le calcul la résolution obtenue, soit en laissant tel quel ( avec comme conséquences : pixellisation et flou sur les LCD ) .
Un écran LCD est fait pour une seule résolution, ne cherche pas...
- plus généralement, la possibilité facilement de jouer avec toutes les entrées sorties, en désactivant simplement Bluetooth Webcam ou Wifi ,ou modifier le keymap " à la volée".
Perso je change à la volée le keymap uniquement de mon typematrix avec un simple setxkbmap -device 42 fr bepo...
Mais sinon, je suis d'accord avec l'auteur du journal: tout ce qui s'est passé ces 2 dernières années avec l'intégration de HAL et le nouveau grub a été très mal documenté , très mal expérimenté, et les méthodes "pour s'en sortir' sont beaucoup moins connues que lorsqu'il s'agissait de faire un simple X -configure , démarrer X avec ce xorg.conf.new , et le tuer à l'aide d'un CTRL+ALT+BACKSPACE .
D'ailleurs sur le Web, à ce sujet, c'est le désert le plus total...
C'est pire que ça : tu trouves pas d'aide parce que ça va dépendre de la distribution, de sa version et de l'âge du capitaine.
Truc drôle : tu parles de l'intégration de HAL à X.org... Tu sais que ce n'est plus le cas désormais et que xorg.conf fait son retour sous la forme d'un dossier xorg.conf.d ?
# Évolution...
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 7.
Regarde, ils ont enlevé des trucs de /proc, c'est affreux, c'est parti dans /sys...
Regarde, ton devfs est dynamique, c'est terrible.
Diantre, où est mon /etc/lilo.conf ? Ha, c'est grub, donc /boot/grub/menu.lst ? Ho mon dieu, /boot/grub/grub.cfg ? Ça ne finira jamais ?
Puis bon, sous Windows c'est pas mieux hein...
Où sont les autoexec.bat, les command.com, les C:\Documents and Settings, le NTLDR...
C'est vrai que c'est assez terrible pour nous "informaticiens" : étant donné le flot continu de changement, quand on regarde légèrement en arrière, on est vite impressionné et submergé par le nombre de changements....
# Services...
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 6.
C'est si compliqué d'arrêter le service kdm/gdm ?
Je veux dire, je fais ça sur diverses distribs depuis au moins 4 ans, le init N n'a jamais été un gage de bon fonctionnement (exemple : debian par défaut en init 2 y compris avec le serveur X, alors qu'un init 2 sur une mandriva va arrêter le serveur X).
P.S : "service kdm stop" sur ubuntu
[^] # Re: grub2
Posté par Pinaraf . En réponse au journal Vive la simplification !. Évalué à 7.
[^] # Re: Bravo mozilla
Posté par Pinaraf . En réponse au journal HTML 5 et vidéo : peux me faire. Évalué à 3.
Safari va utiliser Quicktime sous windows, Firefox utiliserait les codecs DirectMachin… Ce ne sont pas forcément les mêmes…
[^] # Re: Bravo mozilla
Posté par Pinaraf . En réponse au journal HTML 5 et vidéo : peux me faire. Évalué à 10.
C'est marrant, à titre personnel, je suis fort reconnaissant à la MoFo d'avoir agi comme ça, pleinement satisfait de leurs choix, et plus enclin à utiliser leurs produits sachant que eux au moins respectent leurs principes.
[^] # Re: Bravo mozilla
Posté par Pinaraf . En réponse au journal HTML 5 et vidéo : peux me faire. Évalué à 2.
Boarf, à choisir entre la peste et le cholera... J'ai choisi la peste, désolé.
Plus sérieusement, des solutions libres arrivent à lire le code Flash d'un site comme youtube il me semble.
Sinon, pour le fait de faire une sandbox : c'est une sandbox pour tous les plugins, et donc pour d'éventuels plugins libres (exemple : Java, mplayerplugin...)
Et en quoi Flash a une forme de suprématie sur le web ? Perso, j'en ai rien à carrer des vidéos en ligne, je les désactive par défaut et je ne m'en porte pas plus mal. (Mon client youtube est youtube-dl)
Hé oui, on peut très bien vivre sans flash.