benoar a écrit 4244 commentaires

On peut savoir en quoi les paquets Debian ne sont "pas assez entretenus" ?
Vu la taille de la communauté, si tu trouves Debian pas assez entretenue j'ai bien peur que tu n'en trouves pas d'autre qui le fasse mieux ...

Oui les puces d'accélération actuelles sont toutes basées sur un DSP, donc c'est tout a fait envisageable d'avoir un support DSP pour le VP8 mais la vrai question est est ce que les fournisseurs vont le faire?

Moi j'ai une autre proposition : qu'on libère les specs des DSP pour pouvoir les programmer avec des outils libres. Un peu comme Intel a libéré les specs du x86. (je parle donc juste de "l'ISA" du DSP, si on peut dire)

Comme indiqué plus bas, TI met beaucoup de C64x dans ses SoCs récents, et ce DSP est basé sur une archi qui a largement plus de 20 ans. Mais cette archi a toujours été un secret super bien gardé et méga fermé. Aujourd'hui, les DSP sont de plus en plus répandus dans le grand public, ça me paraîtrait normal de les "libérer" un peu.

Ça permettra d'éviter d'avoir toutes ces emmerdes avec les industriels qui utilisent leur matos comme moyen de pression sur des choses qui vont pour moi bien au-delà de leurs prérogatives.

Pourquoi "va te faire foutre"? La GPL V2 te dis, si tu utilise ce code dans un produit que tu distribue, tu dois redonner les modifications faites à la communauté et permettre à ton client de le regénérer, pas de reflasher un firmware.

Effectivement, la GPLv2 ne dit pas qu'on doit pouvoir flasher le firmware. Mais ça a été ajouté formellement dans la GPLv3 car c'était contre "l'esprit" de la GPL. Ce qui en fait donc (chez FT) des enculeurs de mouches.
Et puis bon, reconstruire le firmware, bon courage vu les "trous" qu'il y a.

Il me semble que pour les packages disponible sur le site, les conditions sont a peu prêt remplies.

J'aime bien le "à peu près". Après tant d'années de violation, faire du "à peu près" ne fait pas très sérieux.

Donc, même si Orange doit respecter les licences, on doit se douter qu'il doit être en train de se retourner vers Sagem et Thomson soit pour avoir lui même le code soit pour avoir le droit de le diffuser. Si les industriels n'ont pas été très propre, ca peut demander un peu de temps de détourer proprement ce qui est GPL de ce que ne l'est pas.

Ce n'est _pas_ mon problème. J'ai horreur qu'on me sorte ce genre d'argument.
Bon, pour aller directement sur le problème : oui, c'est Broadcom qui fournit le SDK à la plupart des constructeurs (qui ne sortent juste qu'un PCB avec les composants qu'ils veulent basés sur le kit de chez Broadcom) et ce constructeur est le plus "grand" violeur de GPL dans le monde de l'embarqué. Le hic, c'est qu'il ne vend rien directement aux consommatteurs, et vend seulement aux intégrateurs. Et que donc on nous sort toujours l'excuse "c'est pas moi, c'est Broadcom qui nous a filé le SDK sans les sources". Mais encore une fois, on n'en a rien à foutre de ça : c'est leur cuisine. Mais comme tu dis "ils ont mal joué". Mais ça fait des années et des années que ça dure, et c'est _très_ chiant (perso, je subis les problèmes avec Broadcom depuis 6 ans, en commençant par le bcm43xx, et ça doit faire plus longtemps pour plein d'autres gens).

Heu ... ce serait une petite boîte qui utilise du libre depuis pas très longtemps, OK. mais là ...

L'utilisation de linux, ça ne se fait pas du jour au lendemain non plus. Ils savaient depuis le début les implications qu'il y avait derrière l'utilisation. Ou peut-être pas, mais plaider l'ignorance à tous les coups ...
En tous cas, ça fait un bout de temps qu'ils profitent du libre, qu'ils le savent très bien (j'ai eu le CD des sources entre les mains il y a déjà 2 ans, j'ai bien été tenté de le "sortir" ...) et qu'ils basent beaucoup de leurs projets dessus (dont un projet à plus de 10 millions d'€ (qui n'est jamais sorti ...)). Au bout d'un moment, ça ne peut plus passer.

Et puis je sais pas moi, si j'explique que j'ai des petits problèmes de trésorerie à Orange et que je ne payerai ma facture que dans 6 mois (= je ne respecte pas le contrat) je pense qu'ils vont être assez prompts à me signaler qu'ils ne sont pas d'accords ...

Je vois bien que tu essayes de balancer les différents avis. Mais quand même, à la base, le logiciel libre est fait pour _libérer_ les utilisateurs. Quand je code sous GPL, j'ai mis des conditions à l'utilisation de mon code. Là, on voit un gros industriel qui vole ton code et te dit "va te faire foutre", ainsi qu'à tous les utilisateurs qui espéraient être libres. Ça fait assez "moyen" pour être poli.

Après, si cette licence ne leur plait pas, ils peuvent très bien ne pas utiliser ce code. Ha mais merde, aujourd'hui une boîte seule n'a plus les compétences de faire un OS entier : que c'est dommage ! Alors, qu'ils acceptent les conditions des différents contributeurs (et qu'ils réalisent que leurs contributions seront aussi sous la même licence, ce qui fait que leurs concurrents seront eux aussi contraints aux mêmes exigences, et comme ça tout le monde est logé à la même enseigne ... génial, non ? Ha, on me dit dans l'oreillette que mon envie d'égalité est un peu utopique)

Oui, bien sûr, on connaît les subtilités. Mais en général, les violations que j'ai vu c'est sur des softs effectivement en GPL (regarde les sources des Livebox : il y a tout ce qu'il faut pour faire un tel routeur, quasi aucun dev supplémentaire n'est nécessaire) et sur des produits que, même si je n'ai pas forcément, je pourrai acheter en 5 min dans n'importe quel magasin.

À priori, si tu gardes la solution tunnel SSH, je ne vois pas de moyen "facile" de faire ça. Je te dirais de passer par un VPN à ce moment là.
Après, je ne vois pas trop l'intérêt d'accéder à tes partages locaux Samba, mais bon ...

Cet article se fait proprement démonter dans les commentaires : c'est une grosse connerie, ils ne comptent pas si la RAM est utilisée comme cache ou non.

C'est une histoire de compromis. Bien sûr, rien n'est 100% sécurisé. Mais si tu fous une option dans l'interface web du firmware bien visible "niquer france telecom", ça ne passera pas.

Manquerait plus qu'on tienne le constructeur pour responsable de l'usage qui est fait par l'utilisateur, tiens!

Je dirais que l'analogie est un peu foireuse. Même si effectivement, la loi française sur les télécommunications rend le constructeur responsable de "bloquer" l'utilisation de ses produits hors des normes.

Une des principales raisons que je vois, c'est que ça peut déranger les militaires et les services d'urgence (sûrement que les premiers ont un bon pouvoir de pression). Alors qu'un mec qui tune sa voiture, il ne dérange "personne" (au sens de ma phrase précédente, hein).

Je sais pas pour toi, mais moi dans mon monde des informaticiens, on connaît très bien ce problème mais on arrive à se comprendre quand même.

(bon, pour le début de ton commentaire, je n'ai pas très bien compris si tu abondes dans mon sens ou non)

Le constructeur n'ont pas "à faire avec". La taille des secteurs est prévu d'être fournis. Ensuite, les auteurs de FS doivent prendre en compte cette information. La gestion est très proche d'une gestion de cluster, la seul différence est la possibilité d'une écriture partielle sur un bloc vierge.

C'est bien d'avoir les choses en place en théorie. Le truc c'est qu'en pratique on a encore du Windows XP partout. Et qu'il faut bien faire avec (= blocs logiques de 512o).

Bon, à priori, si c'est pour un Vista/Seven, ça devrait marcher. C'est ça ? C'était il n'y a pas très longtemps ?
Mais de toutes façons, "secteurs exposés du périphérique bloc", ça ne veut pas dire grand chose. Je viens de relire la norme ATA, et depuis la version 7 on dispose de commandes pour savoir quelle est la taille de bloc logique / physique, ainsi que l'alignement.

Peut-être que le firmware n'est pas encore prêt, et qu'ils n'ont pas encore bien testé les disques comme ça. Il faudra attendre un peu ...

Des secteurs logiques de 4kio ? Ou physiques, mais présentés en 512o ? Ou alors c'est les secteurs du FS dont tu nous parles ? (vu l'appellation, je pense que c'est ça)

D'après ce que j'ai compris, le jumper sur les WD sert uniquement à mettre l'alignement à -1 bloc en cas d'OS ne pouvant pas être aligné (de façon à ce que le 63 bloc soit aligné).

Pourtant, je peux parfaitement ne pas utiliser la Livebox et mettre n'importe quel autre modem à la place.. C'est à se demander ce qui leur est passé par la tête en écrivant ça.

Et ton autre modem, tu peux le flasher ? Non, il doit aussi respecter la législation en vigueur ...

Regarde un peu ce qui s'est passé pour le N770, puis pour les N8x0, et tu comprendras peut-être un peu mieux.

La fragmentation n'est pas "géré", il est fait comme si elle n'existait pas avec un pseudo système journalisé, qui forcément dégrade les performances pour faire les copies quand il n'y a plus de place dispo.

Je parle de la fragmentation sous la forme du wear-leveling : au contraire des disques classiques, il faut essayer de répartir les écritures sur le plus de zones possibles (enfin, tout en rassemblant les données le plus possible dans des blocs entiers).

Un "TRIM", c'est juste un "erase" pour rendre le secteur vierge.

Oui, et ? Sans TRIM, tu copies l'équivalent de la capacité de ton disque dessus et tu n'as plus aucun secteur libre ...

La taille des zones peut être lu sur les SSD.

C'est arrivé avec le 2.6.31 quand même ... Mais surtout, je n'ai vu absolument _aucun_ constructeur communiquer dessus. C'est un secret industriel qui n'est que rarement dévoilé. Et j'ai vérifié sur deux SSD chez moi (un "maison" avec des cartes CF, et un Photofast) et aucun n'indique sa taille de "bloc" (d'ailleurs, normalement un SSD n'a pas vraiment de zone (enfin, c'est flou, comme tout ce qui tourne autour des SSDs) contrairement aux SD/CF, car il fait du wear-leveling sur tout le disque ; on pourrait par contr ese demander quelle est sa taille de page et la taille des erase block).

Cela serait bien plus propre gérer au niveau FS. C'est "juste" une couche supplémentaire.

Oui enfin bon, là, cette possibilité, ça fait "longtemps" que les constructeurs l'ont oublié. Maintenant il faut faire avec ...

Bon, en fait ce n'est pas exactement un problème de fragmentation dont je parle, mais de l'histoire d'arriver à faire du wear-leveling correct, surtout quand le disque devient plein (donc encore plus problématique quand le SSD ne gère pas le TRIM). Les performances et la longévité du SSD vont grandement diminuer quand le SSD ne trouve pas facilement de place "libre" pour écrire tes données. En plus, s'il faut qu'il libère un bloc avant de pouvoir écrire (dans le cas où peu de blocs sont disponibles), tu vas avoir droit à un cycle de read/modify/write de la taille d'un erase bloc (plusieurs dizaines de ko, voire plusieurs mégas pour les SSD dans le futur, cf http://www.hardware.fr/news/imprimer/10713/ ), ce qui va prendre du temps.

Mais effectivement, ce n'est pas une histoire de temps d'accès dû à une contrainte physique ; c'est la "logique" derrière qui peut ralentir.

Tu n'as pas du bien comprendre : les SSD utilisent bien ce même "hack" (si tu veux l'appeler ainsi). Ils ont des blocs physiques de 4ko ou plus, mais exposent des blocs logiques de 512o. Comme tout périphérique de type bloc depuis des dizaines d'années. Parce que sans ça, ils ne fonctionneraient pas avec un Windows inférieur à Vista.

D'où le problème que tu cites avec l'alignement, qui est exactement le même sur les WD. C'est dû au décalage taille de bloc physique / logique qu'on trouve dans ces deux types de disque.

Le truc c'est que si tu fais des disques avec des blocs logiques de 4ko, tu peux dire bye-bye à tout Windows inférieur à Vista. Ce qui aurait fâché trop de gens ...

Il a déjà été montré plusieurs choses (dont je n'ai plus les références malheureusement) :
- adapter le kernel à une taille de bloc supérieure à une taille de page (4ko) serait un travail énorme
- le choix de 4ko est un compromis par rapport à l'utilisation qui est faite des petits fichiers

Bref, ce n'est pas si facile à changer, et surtout, ça a été réfléchi avant, quand même.

Les expressions régulière tel que présentées plus haut ne posent pas de problèmes avec les " n'importent où.

Et si, dans le cas où on a un guillemet échappé dans la chaîne ... OK, tu vas me dire, "ça arrivera jamais, aucune ville n'a de guillemet dans son nom", mais "on sait jamais" ... (je ferais bien plus attention aux erreurs de traitement qui pourraient par exemple intégrer un guillemet inséré à cause d'un bug de double échappement ou un truc du genre)

Ma "logique" c'était que tant qu'on a une lib qui suit la "norme" sans se prendre la tête avec les regexp, tout en ayant un langage qui permet d'aussi facilement l'utiliser, autant en profiter.

Enfin, mes excuses pour la pique sur les "vrais langages", c'est vrai que j'ai vu des morceaux de sed et awk assez impressionnant sur ce forum.

Moi je parle de problème de consistance des données en cas de "panne". Actuellement, une écriture de 512 octets est garantie pour être atomique (i.e. quand tu envoies l'écriture au disque et qu'il valide la commande, tu peux être sûr que c'est bien inscrit sur le disque, et pas en cache), mais pour 4ko (physique, et toujours 512o logique) je ne suis pas sûr, vu qu'il faut faire un read de 4ko, modifier les 512o, et écrire 4ko. S'il y a une coupure en plein milieu, je ne sais pas si le disque a le temps ou non d'écrire tout et de garantir l'atomicité.