WhiteCat a écrit 699 commentaires

T'as déjà vu une spécification gratuite mais non lisible (au sens 'accessible en lecture') ?

Non mais ce n'est pas ce que je cherchais à montrer non plus. Je voulais souligner le fait "lisible mais non gratuite" de H264 (et non l'inverse évidemment).

Bah… La drogue, c'est toujours la même façon d'amener les nouveaux drogués : la première (et deuxième) dose est gratuite. Ca fonctionne comme ça depuis… Longtemps.

Ce sont donc les mêmes méthodes que la MPEG LA. Sauf qu'avec la MPEG LA on le sait. Avec Google tu spécules sur ses intentions futures.

Skype est gratuit aussi, mais "ça pue" va comprendre…)
Skype ne puera plus quand le client sera libre, et qu'on aura des spécifications pour pouvoir implémenter et utiliser gratuitement un serveur Skype libre.

on ne sait pas trop pourquoi d'un coup libre et synonime de gratuit pour certains "libristes" qui ont oublié ou n'ont jamais su ce qu'est le libre

Je ne fais pas l’amalgame, mais j'insiste pour dire qu'un logiciel libre et une spécification libre sont 2 choses différentes.
Avoir un logiciel privateur empêche de le modifier. C'est très gênant.
Avoir une spécification lisible et gratuite mais non modifiable, c'est très dommage mais c'est pas le plus important dans une spécification.

Google fait de l'argent en utilisant du libre, et en n'attaquant personne avec ses brevets. En libérant même du code et des brevets (VP8). Ce sont des salauds donc.

Microsoft, Apple, Blackberry, etc. font de l'argent avec leur code proprio brevetés. Ils attaquent leur concurrent avec des histoires de brevets logiciels. Il va donc de soit qu'il faut absolument utiliser leurs technologies aujourd'hui car sinon Google risque de faire pareil qu'eux dans 5 ou 10 ans.

En résumé :
VP8/9 -> libre* aujourd'hui
VP8/9 -> libre demain
VP10 -> inconnue (sûrement libre mais bon)

H264/265 -> pas libre aujourd'hui
H264/265 -> pas libre demain

OK, fonçons sur H264, ils sont plusieurs à contrôler le format alors donc c'est plus sain.

Évidemment un consortium pour gérer une norme c'est mieux qu'une seule boîte, mais à part ça j'ai du mal à comprendre ce raisonnement vu que ça n'apporte aucun avantage.

* j'utilise le mot libre au sens large (pas de restrictions d'usage, gratuit), pas au sens "logiciel libre"

Si Opera est si invisible que ça, pourquoi il apparaît encore sur les stats de Linuxfr ? Et d'une manière générale à chaque fois qu'on parle de part de marché des navigateurs ?

Si je fais une analogie avec les navigateurs Web, Opera est invisible aussi alors ?

C'est pas Motorola qui a commencé à faire chier. C'est Microsoft.
http://www.pcinpact.com/news/69162-guerre-brevets-apple-microsoft-motorola-google.htm

OK, pour toi qu'on mélange libre et gratuit ne te dérange pas, admettons. Pour moi, faire la différence est important. Chacun ses priorités, pour libre c'est la liberté de modifier, pas la liberté d'utiliser en étant dépedant d'une entreprise unique quand à l'évolution.

Sauf que je fais la différence entre un logiciel libre et une spécification (de format vidéo en l’occurrence) libre. Même si la spécification n'est pas libre (c'est très dommage j'en conviens) on peut quand même écrire un encodeur et un décodeur libre, utilisable par n'importe qui sans avoir peur de se prendre un procès sur la gueule à cause des brevets logiciels.

Ben raté : Google a sans doute payé à MPEG (c'est secret certes, mais je doute que ce soit autre chose)

Si c'est secret, comme tu le sais ? Peut-être que la MPEG LA a vu que ses brevets ne valent pas un clou.

x264 est libre.

Oui c'est un point positif pour H264.

Alors certes Google paye pour que les autres entreprises puisent diffuser VP9 gratos, mais rien ne dit que le futur VP10 sera pareil.

Et ben on verra en temps voulu. Je ne vais pas utiliser (et payer pour) H264 maintenant parce que sinon peut-être que VP10 ne sera pas gratuit et libre d'utilisation.

Google sera alors le seul maitres (contre une myriades d'entreprises pour MPEG)

Google ne menace personne avec ses brevets. La MPEG LA ils sont peut-être 1000, mais ils font chier tout le monde avec leurs brevets. Donc je préfère utiliser les produits Google.

tout fork est invisible

Cyanogen Mod ne m'a pas l'air invisible du tout.

J'ignorais précisément ces différences (format gratuit / implémentation libre), mais bon… c'est l'implémentation et le droit d'usage qui sont importants surtout.

Le format n'est pas libre. OK, donc ça veut dire que juste Google est capable de modifier son format (VP8/VP9). Quelqu'un avait l'ambition de le forker de toute façon ?

Par contre l'implémentation libre ça c'est important. Il y a une implémentation libre de référence qui peut être améliorée par n'importe quel spécialiste et entreprise, librement.

Le droit d'usage libre : extrêmement important. VP8 et VP9 sont aujourd'hui présents dans des logiciels libres et non libres, gratuitement.

Au final aujourd'hui je peux regarder au moins un quart des vidéos Youtube (en VP8 sans Flash Player) avec Firefox, sans que personne n'ai eu a payer quoi que ce soit.
Et la MPEG LA ? Non, c'est toujours pas possible de visionner librement et gratuitement du H264 dans un navigateur libre.

Donc merci à Google pour utiliser et nous permettre d'utiliser des outils libres.

Nikel ! Merci d'avoir reporté ça.
J'ai effectivement déjà un compte Bugzilla (j'ai déjà reporté pas mal de bugs) et je comptais justement en créer un.
Ce matin je viens de bien formaliser mes tests, et c'est encore différent selon que j'écris sur NetApp (SMB1) ou Win 7 (SMB2/3).

Je vais mettre tout ça dans le ticket créer par Sachin.

Merci pour tes recommandations.

• Je vais faire une capture réseau avec tcpdump pour voir
• Des sync entre chaque echo ne change rien
• Je ne pense pas que NFS y soit pour quelque chose, car le problème avec CIFS se pose avec l'option "cache" qui ne semble pas exister pour NFS

Ça ne change rien, je peux même mettre en sync ou un umount/mount entre chaque echo.

Je me suis aperçu de ce soucis lorsque mes scripts ne marchaient plus après màj, donc a priori ce n'est pas une erreur de frappe de ma part.

Quoi qu'il en soit, j'ai bien un code retour "0" à chaque fois.

C'est intégré dans quelle distribution ?

Bizarre, moi j'ai pas de compte client, juste un compte sur leur site. Un jour j'ai demandé une évaluation de RHEV c'est tout. Là je suis en train de dl l'iso de la 7beta.

https://access.redhat.com/downloads/content/226/ver=/rhel---7/x86_64/product-downloads

J'ai trouvé l'adresse en moins de 2 après m'être connecté sur leur site.

OK certes mais je me risquerais pas personnellement d'utiliser en prod un fs via fuse. Je préfèrerais encore utiliser btrfs malgré son non-support officiel dans RHEL.

Si c'était vraiment le fs idéal il fonctionnerait sur Linux ;-)

Il y a une quinzaine d'années, j'ai découvert cron, ça a changé ma vie. Tu devrais essayer.

Tu veux dire qu'il faut que je configure moi-même un cron, qui donc va tourner régulièrement, même quand j'en ai pas besoin, pour avoir des informations à jour dans un autre logiciel.
L'ergonomie des outils d'administration Debian me laisse pantois. Heureusement que ce même procédé n'est pas généralisé ailleurs, par exemple sur le Web où pour aller consulter les articles sur linuxfr.org, il faudrait lancer d'abord un cron pour mettre à jour les pages web en local, pour ensuite les consulter dans Firefox.

Y'a régulièrement des màj de sécurité.

Bien vu.

Moi je haie "apt-get".
Déjà la commande est chiante à taper.
Ensuite, la commande pour chercher un paquet s'appelle… "apt-cache" => MEGA LOGIQUE inside.

Je tiens à préciser que je ne comprends pas pourquoi une recherche entraîne la mise à jour de la liste des paquets.

Pour avoir des informations à jour sur les paquets. "apt-get" est capable de te donner des infos pas à jour (très utile donc…) et si je veux avoir des infos correctes, il faut d'abord taper "apt-get update". Devoir taper 2 commandes au lieu d'une, vive l'ergonomie.

Je suis assez d'accord avec toi, on aurait bien aimé avoir un core du filesystem rock stable et des fonctionnalités ajoutées au fur et à mesure.

Mais d'un autre côté, l'intérêt de btrfs c'est notamment :
- réparation auto du système (checksum, etc.)
- RAID intégré
- snapshot (et en gros toutes les joyeusetés possibles grâce au COW)
- compression
- déduplication à la demande (intégré dans le kernel 3.12)
- et pas mal d'autres choses

Donc si tu enlèves toutes les features justement géniales, il reste quoi ? Un fs similaire à ext4 ? Donc qui aurait envie de changer de filesystem si c'est la même chose qu'ext4, qui lui est stable.

Enfin bref, j'ai bien hâte qu'il arrive dans RHEL. Je pense qu'il va rester une Technology Preview dans RHEL 7.0, mais j'espère et j'ose croire qu'il va devenir stable dans les RHEL 7.2 ou 7.3 ? J'ai vraiment hâte de pouvoir l'utiliser ce système de fichiers.

Oui Red Hat fait (quasi ?) exclusivement de l'argent avec le support d'une manière générale (la KB fait partie du support).

Il y a la possibilité d'avoir accès à la Red Hat Knowledgebase aussi.
Je n'ai pas d'abonnement et c'est dommage parce qu'il y a plusieurs articles que j'aurais bien aimeé pouvoir consulter, par exemple :
https://access.redhat.com/site/solutions/442103