Un peu comme dit Guillaume juste au dessus, jamais aucun logiciel libre n'a fait chier avec les modifications que tu lui fais : si on n'a plus le droit de le modifier, c'est qu'il n'est pas vraiment libre. Bref, Debian s'est toujours permis de le faire car tout le monde pensait que c'était "normal", à l'époque, mais depuis on voit que ça a changé dans le libre et qu'aujourd'hui certaines entités (la MoFo) demandent à respecter un droit des marques. Bref, se remettre dans le contexte, voir le rapport de force, et réfléchir avant de balancer des conneries (cf ta réponse à Guillaume).
Je ne dirai pas que c'est "complètement vrai", dans le sens où le trolleur original disait que c'était la raison de départ, _et_ que c'est Debian qui était trop rigide : en gros, Debian pensait pouvoir utiliser le nom même si elle ne pouvait pas utiliser les logos. Il s'est avéré que ce n'était pas possible, et c'est bien des gars de la MoFo qui l'ont fait remarquer, et donc Debian a choisi de changer complètement de nom vu qu'ils ne pouvaient pas trouver d'accord.
Bref, pour moi, la rigidité ne vient pas du côté de Debian ...
Mozilla a commence a gueule quand debian a change le script de rebuild pour virer l'option permet de builder sans la marque.
Source stp. Parce que pour moi c'est complètement faux.
J'avoue que je n'ai même pas lu les liens, mais à la vue du résumé qui a l'air bon, et après avoir déjà lu un texte dans le genre il n'y a pas longtemps dans Libé, j'imagine bien le truc : pour moi, c'est un texte pour dire que tout est pourri, mais qu'il existe des petits rebels qui contrent ce truc. Donc on est peut-être "sauvé"
Pour moi, ça pose beaucoup de problèmes :
1) Déjà, c'est annoncer de manière exagérée plein de choses qui, bien qu'elles soient souvent vraies, font passer les états et les entreprises qui contrôlent le net pour des entités supérieures auxquelles on ne peut rien, ce qui est faux. C'est le principe même d'une démocratie, je dirai (même si beaucoup de pays concernés ne sont pas des démocraties, pas mals en sont quand même aussi dans la liste), et c'est grave de le nier.
2) Ensuite, on dit que des petits génies réussissent à contourner tout ça, faisant croire au combat de David contre Goliath dont l'issue sera positive. Déjà, le rapport de force est très très inégalitaire, et ensuite, même si certains arrivent à contourner les protections, c'est en violant la loi (ce qui rend la chose "excitante" mais dangereuse), et cela fait aussi résonner dans l'esprit des gens que c'est quelque chose pour une élite, et qu'eux soit n'y auront pas accès, soit devront être "soumis" en quelques sortes à ces gens qui leur "sauvent la vie". Ça met un autre rapport de force que je n'aime pas du tout, et c'est surtout faire passer les gens comme des impuissants face à cette situation. Bref, les décourager de faire quoi que ce soit par eux-même.
3) On ne parle même pas de la France, histoire d'ignorer tout ce qui se passe en ce moment, et ça c'est le ponpon pour un journal français. Voudrait-on faire oublier le vote d'HADOPI, montrer que nous on est "clean" donc on n'a pas à s'inquiéter, dans notre beau pays des droits de l'Homme ?
Bref, faire peur aux gens mais leur expliquer que ça va bien aller, mais ce ne sera pas avec leur aide, je trouve ça dégueulasse. Je veux dire, je trouve que c'est désinformer la population au point de la rendre complètement "panurgiste" de la politique, et de lui mettre encore plus profond dans le crâne que de toutes façons, tu n'as aucun pouvoir et puis que tes libertés actuelles, tu vois, elles sont en train de s'évaporer partout dans le monde, alors te plains pas. Et puis surtout, pense au merveilleux monde des "rebelles", ça fait joli comme dans les fictions, mais de toutes façons on sait très bien qu'en réalité ils finissent toujours par se faire niquer.
Pour ceux qui veulent un truc encore plus orienté "libre" (donc y compris le logiciel), il y a BeWelcome : http://www.bewelcome.org/
Un des admins a fait une démo au dernier BarCamp rennais, ça avait l'air vraiment sympa.
Il me semble aussi qu'aujourd'hui, si tu écris des secteurs entiers de zéro sur des blocs qui sont invalides, le disque détecte qu'il faut l'échanger avec un de la "réserve". Il ne le fait pas automatiquement dans les autres cas, si tu n'écris pas que des zéro.
Le formatage bas niveau (dit BIOS) a disparu avec les i486.
T'aurais une référence stp ? À chaque fois j'essaye d'expliquer aux gens que formattage de bas niveau ça veut rien dire, mais j'ai du mal à étayer.
Faut être clair, ici on parle d'écraser l'ensemble des blocs du disque. Aucun outil dit de "formatage" (qui cree le systeme de fichiers) ne le fait à ma connaissance.
dd if=/dev/zero of=/dev/sda ?
Bon, c'est vrai que pour le fonctionnement de TCP je me suis un peu trompé, même si la deuxième partie de ton explication correspond à ce que je décrivais : on pousse jusqu'au max possible avant de perdre des paquets, et là on diminue un peu.
Sinon :
une perte d'un paquet entraîne toujours un ralentissement de l'émission (en plus de la ré-émission du paquet).
Bah oui que ça ralentit l'émission, puisque le client n'a pas reçu les paquets. Mais le serveur, lui, ne voit pas que t'as perdu des paquets magiquement : il le voit en fonction de ton émission des ACKs. C'est pour ça que j'en couclue que c'est bien l'upload qui détermine la vitesse de download (quand on shape, hein, et dans la limite de la taille de connexion en download bien sûr)...
Cf mon lien au dessus, ça paraît un peu bizarre à l'esprit au départ, mais ce n'est pas si illogique que ça.
Bon, c'est vrai que je ne maîtrise peut-être pas tout bien, mais je suis d'accord avec le fait que si des paquets se perdent, TCP va diminuer la fenêtre. Mais, en me basant sur : http://web.archive.org/web/20071101114640/www.digriz.org.uk/(...)
que j'avais utilisé à l'époque et qui marchait très bien, il dit :
N.B.
shaping only works for OUTGOING packets simply so think which interface to use
when you apply shaping to incoming packets you really are saying which ones
are safe to drop (without generating more traffic, FTP data) and which are
unsafe (UDP as it will not slow down the data transfer and has already
consumed your bandwidth and TCP ACK's are examples).
Ce qui n'est pas bête : dropper des paquets qu'on a déjà reçu, ça ne sert à rien d'autre que de perdre de la BP ... donc au final, le shapping se fait toujours sur l'egress ...
D'une part la transition vers des secteurs de 4K est en cours.
Oui, c'est plus pratique aujourd'hui pour s'aligner à la taille des pages en RAM, et s'adapter plus facilement aux FS, et pour les grandes tailles de disque. Mais ça ne change rien pour les SSD qui ont des tailles de page différentes. À moins qu'il y ait un effort d'unification à 4ko ? Mais je n'en ai jamais entendu parler. Et puis ça ne règle pas le problème de la taille des erase-block, ni même des "zones" si on passe par une FTL bas de gamme.
des commandes ATA spécifiques aux SSD apparaissent (voir TRIM/Discard)
Oui enfin encore une fois, c'est une adaptation aux FTL, pour qu'elles soient utilisées un peu mieux (enfin, pour qu'elles ne soient pas complètement nazes ... ce qui est mieux que rien, mais pas top). Et ça existait déjà dans les specs CompactFlash (en mode ATA), même si à priori ça n'a jamais été implémenté par personne ... Et puis surtout ça devient assez drôle au niveau des implications que ça a par rapport aux utilisations un peu inhabituelles comme l'accès direct (sans passer par le FS) ou la récupération de données, cf http://marc.info/?l=linux-ide&m=123266840917245&w=2 et suivants, j'ai le flemme d'expliquer pour l'instant.
Bref, ça n'améliore qu'un peu la situation, et surtout, c'est fait dans l'esprit de garder absolument les FTL, pas d'imaginer de travailler sans.
Le problème est que quand ils te vendent une licence OEM avec un ordinateur, ce n'est pas eux qui ont acheter la licence (contrairement à un achat seule de la licence) et je trouve normal qu'il y ait des économies d'échelles sur le prix de la licence.
Oui enfin là les magasins pourraient se retourner contre ce constructeur pour vente liée également, non ? (dans un monde idéal, bien sûr) C'est ça la recette de MS (et aussi pour d'autres cas en dehors de l'informatique) : faire remonter la responsabilité du problème le plus haut possible dans l'échelle pour que les petits acteurs d'en bas ne puissent rien y faire.
Par exemple si je commande un ordinateur avec plus de ram, je ne paye pas la ram au même prix que si je l'avais achetée à part.
BEEEEEP.
Erreur, comparaison avec du matériel, ce qui n'a rien à voir avec du logiciel.
C'est bizarre, je me suis toujours dit que ça se passait comme ça, merci pour la confirmation. Donc bref, rien n'a changé, c'est toujours la même merde.
Le truc c'est que quand on fait de la QoS, limiter le flux descendant ne sert quasiment à rien. C'est l'upload qui détermine tout.
Explications :
Si un téléchargement est en train d'occuper plein de BP qui fait que le surf sur le web va lentement, et qu'on choisit de "dropper" des paquets de ce gros flux (que ce soit au niveau du DSLAM ou du routeur/*box), l'ordi qui télécharge va juste ACKer les paquets bien arrivés et NACKer les autres, ce qui fait que le serveur en face va en envoyer encore plus pour compenser les paquets "perdus". Ce qui ne va pas arranger la situation.
Quand un serveur envoie du traffic à une machine (qui à priori dans notre cas a un débit plus faible), il va envoyer à bloc au départ et s'adapter en fonction du rythme des ACK de la machine cliente en face. Et c'est donc le rythme d'upload de la machine cliente qui va déterminer la vitesse d'envoi pour le serveur, que ce rythme soit limité parce que l'upload est saturé (genre, quand le client fait du P2P) ou parce que le download l'est (la ligne n'a pas un assez gros début descendant, les paquets font la queue avant le client (genre au DSLAM) et que donc le client ne peut pas ACKer des paquets qu'il n'a pas encore reçu).
Tout ça est géré par TCP, c'est le principe du protocole.
Par contre, pour la TV et le téléphone, je pense que c'est géré autrement car déjà ce n'est pas du TCP, mais par contre c'est du non-connecté donc avec potentielle perte de paquet, mais ça ne fait pas grand chose car ce sont des services "temps réel" donc où on ne renvoit rien si ça foire. De plus, ces débits sont souvent fixes, ce qui facilite le dimensionnage de la QoS descendante.
Comme tous ces magasins ont l'air de proposer des Windows à des prix si bas, pourquoi ne pas essayer de leur en acheter un bon paquet à ce prix et voir leur réaction ?
Si on peut acheter une machine "sans" l'OS, on doit bien pouvoir faire le contraire, non ? Ou alors acheter une souris à 5€ avec chaque licence, pour voir.
Enfin bon, cette histoire d'OEM c'est bien une arnaque made in Microsoft pour faire semblant de respecter la loi sur la vente liée ...
Bon, qu'il n'y ait pas de mécompréhension : je suis complètement d'accord que ce système de bloc ne soit pas du tout adapté aux mémoires Flash (que ce soit SSD ou USB/SD), mais là je suis passé en mode "pragmatique" car aujourd'hui, aucun constructeur ne fait l'effort d'y remédier par un moyen -- même pas idéal -- un tant soit peu "pas mauvais". Tout le monde utilise un FTL, point. Les seuls qui ont un accès direct à la Flash, c'est dans l'embarqué, et encore, juste pour la Flash "de base" (par exemple, il me semble que dans l'iPhone/iPod Touch, le firmware est en accès MTD, mais le stockage de 8/16/32Go est en oneNand, soit le protocole SD, qui marche aussi par bloc de 512). Bref, rien a destination du grand public.
Ensuite, ce coté bloc de 512, quand je disais que c'était inhérant au système de bloc, ce n'est pas que ça, c'est aussi inhérant à la norme ATA ! (et donc SATA) Bref, ce n'est pas qu'un problème de soft, c'est aussi un problème de hard (enfin, moitié/moitié puisque la stack ATA c'est un bout de driver et un bout de hard). Donc ce n'est pas près, selon moi, de changer.
Comme personne n'a poussé pour un système de connexion spécifique aux mémoires Flash (on aurait peut-être pu faire quelque chose "au dessus" du protocole physique SATA, voire encore plus crade mais plus "facile", au dessus des commandes ATA ?) et bien tout le monde fait des FTL. Et effectivement, personne ne sait ce qu'il fait, garder des secrets ça arrange bien les industriels.
Enfin bref, pour les histoires de capacités, c'est peut-être facile aujourd'hui, mais j'ai entendu que pour simplifier le design des puces de grosses capacités, ils voulaient faire des erase block dont la taille se compte en Mb, ce qui ne va pas arranger les choses. D'ailleurs c'est peut-être déjà le cas, mais on n'en sait rien. Encore du secret.
Pour conclure, oui ce serait bien d'arriver à faire un truc adapté (et libre, en plus) mais je ne pense pas que ce soit faisable vu le comportement des industriels aujourd'hui.
Je pense que ce que tu décris, c'est la taille d'un secteur, qui n'est pas la même chose qu'un bloc : effectivement, des périphériques indiquent des tailles de secteur différents de 512 octets, mais les blocs gardent cette taille. À vérifier quand même, mais là il est tard ...
Holala, je n'ai pas de document "sérieux" à te fournir, mais c'est justement le manque de documents sur tous les périphériques de type bloc (Clés USB, carte SD, disque SSD) et puis pleins d'articles que j'ai lu qui me font dire que ça ne sert absolument à rien de vouloir contrer ce que fait la FTL. UBI et consort sont faits pour des périphériques MTD, et c'est tout.
Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc ! Tout le système des block io de linux et des autres OS est basé sur cette assomption.
Ensuite, tu n'as aucun contrôle sur comment est géré le cache, l'écriture, etc. de tes blocs derrière, à moins de tripatouiller dans le système de gestion de périphs bloc du kernel.
Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.
Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ? Peut-être qu'elle flush tout à chaque écriture d'un bloc (= effacement d'un erase block qqpart, récriture du contenu en entier + tes nouvelles données .... super efficace ; je soupçonne les clés USB de faire ça, vu leur durée de vie), ou alors peut-être est-elle plus "intelligente", mais comment va se comporter ton algo avec ça ?
Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.
Voilà, tout ça sans parler du "problème", si votre objectif est de faire quelque chose qui marche partout (vu que vous faites du windows aussi, je suppose que c'est un peu votre objectif) d'arriver à avoir un format assez répandu pour être lu de manière pratique sur beaucoup de machines ...
Je pense qu'il voulais dire que le premier redimensionnement était pour remettre la taille du FS à la taille de la partition (qui n'avait pas bougée).
Sinon, pour l'"ordre", si vraiment tu veux en mettre un, ça dépend de l'opération : si on diminue la taille, on fait d'abord le FS et après la table, et si on agrandi, on fait d'abord la table, et après le FS.
Je me répète, et ça fait longtemps que du monde le dit (mais personne ne le code /o\) mais les news mises "en haut" de première page ne sont pas lisibles du tout. Ça fait une semaine qu'elle est publiée et je viens juste de la voir. Déjà, rien que mettre une fonte plus petite que le reste est débile. Je n'ai pas vraiment de solution, à part peut-être la laisser "en double", en haut mais également dans le fil normal des news, histoire de pas la louper.
Halala, les joies de l'esclav^Wexploita^W^Wla jeunesse qui fait des stages ... Si tu débutes en réseau, commence par quelque chose de plus simple que CARP, genre essaye de voir comment marchent les réseaux ensemble, puis regarde le filtrage, puis CARP. Ça fait du taf, mais sinon tu vas ne rien y comprendre, stresser et faire un truc complètement bancal (si ça marche ...).
Et puis si tu veux que les autres voient ton message, répond dans le thread.
[^] # Re: Inacceptable
Posté par benoar . En réponse au journal Microsoft patche Firefox ... discrètement.. Évalué à 1.
[^] # Re: Inacceptable
Posté par benoar . En réponse au journal Microsoft patche Firefox ... discrètement.. Évalué à 5.
Je ne dirai pas que c'est "complètement vrai", dans le sens où le trolleur original disait que c'était la raison de départ, _et_ que c'est Debian qui était trop rigide : en gros, Debian pensait pouvoir utiliser le nom même si elle ne pouvait pas utiliser les logos. Il s'est avéré que ce n'était pas possible, et c'est bien des gars de la MoFo qui l'ont fait remarquer, et donc Debian a choisi de changer complètement de nom vu qu'ils ne pouvaient pas trouver d'accord.
Bref, pour moi, la rigidité ne vient pas du côté de Debian ...
[^] # Re: Inacceptable
Posté par benoar . En réponse au journal Microsoft patche Firefox ... discrètement.. Évalué à 2.
[^] # Re: Inacceptable
Posté par benoar . En réponse au journal Microsoft patche Firefox ... discrètement.. Évalué à 5.
Source stp. Parce que pour moi c'est complètement faux.
# Les textes alarmistes anticipateurs sont complices de leurs conséquence
Posté par benoar . En réponse au journal Internet : Voyage en Censurie. Évalué à 6.
Pour moi, ça pose beaucoup de problèmes :
1) Déjà, c'est annoncer de manière exagérée plein de choses qui, bien qu'elles soient souvent vraies, font passer les états et les entreprises qui contrôlent le net pour des entités supérieures auxquelles on ne peut rien, ce qui est faux. C'est le principe même d'une démocratie, je dirai (même si beaucoup de pays concernés ne sont pas des démocraties, pas mals en sont quand même aussi dans la liste), et c'est grave de le nier.
2) Ensuite, on dit que des petits génies réussissent à contourner tout ça, faisant croire au combat de David contre Goliath dont l'issue sera positive. Déjà, le rapport de force est très très inégalitaire, et ensuite, même si certains arrivent à contourner les protections, c'est en violant la loi (ce qui rend la chose "excitante" mais dangereuse), et cela fait aussi résonner dans l'esprit des gens que c'est quelque chose pour une élite, et qu'eux soit n'y auront pas accès, soit devront être "soumis" en quelques sortes à ces gens qui leur "sauvent la vie". Ça met un autre rapport de force que je n'aime pas du tout, et c'est surtout faire passer les gens comme des impuissants face à cette situation. Bref, les décourager de faire quoi que ce soit par eux-même.
3) On ne parle même pas de la France, histoire d'ignorer tout ce qui se passe en ce moment, et ça c'est le ponpon pour un journal français. Voudrait-on faire oublier le vote d'HADOPI, montrer que nous on est "clean" donc on n'a pas à s'inquiéter, dans notre beau pays des droits de l'Homme ?
Bref, faire peur aux gens mais leur expliquer que ça va bien aller, mais ce ne sera pas avec leur aide, je trouve ça dégueulasse. Je veux dire, je trouve que c'est désinformer la population au point de la rendre complètement "panurgiste" de la politique, et de lui mettre encore plus profond dans le crâne que de toutes façons, tu n'as aucun pouvoir et puis que tes libertés actuelles, tu vois, elles sont en train de s'évaporer partout dans le monde, alors te plains pas. Et puis surtout, pense au merveilleux monde des "rebelles", ça fait joli comme dans les fictions, mais de toutes façons on sait très bien qu'en réalité ils finissent toujours par se faire niquer.
[^] # Re: Couchsurfing
Posté par benoar . En réponse au journal Vagabond libre cherche lit. Évalué à 3.
Un des admins a fait une démo au dernier BarCamp rennais, ça avait l'air vraiment sympa.
[^] # Re: Attention
Posté par benoar . En réponse au journal De l'utilité de formater plusieurs fois son disque dur. Évalué à 2.
[^] # Re: Question...
Posté par benoar . En réponse au journal Le mobile en France, c'est pas cher !. Évalué à 2.
T'aurais un nom stp ? Parce que pour 5€, on dirait qu'il n'y a que des cartes valables 15j ...
[^] # Re: Attention
Posté par benoar . En réponse au journal De l'utilité de formater plusieurs fois son disque dur. Évalué à 3.
T'aurais une référence stp ? À chaque fois j'essaye d'expliquer aux gens que formattage de bas niveau ça veut rien dire, mais j'ai du mal à étayer.
Faut être clair, ici on parle d'écraser l'ensemble des blocs du disque. Aucun outil dit de "formatage" (qui cree le systeme de fichiers) ne le fait à ma connaissance.
dd if=/dev/zero of=/dev/sda ?
[^] # Re: 3G
Posté par benoar . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 2.
[^] # Re: QoS
Posté par benoar . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 0.
Sinon :
une perte d'un paquet entraîne toujours un ralentissement de l'émission (en plus de la ré-émission du paquet).
Bah oui que ça ralentit l'émission, puisque le client n'a pas reçu les paquets. Mais le serveur, lui, ne voit pas que t'as perdu des paquets magiquement : il le voit en fonction de ton émission des ACKs. C'est pour ça que j'en couclue que c'est bien l'upload qui détermine la vitesse de download (quand on shape, hein, et dans la limite de la taille de connexion en download bien sûr)...
Cf mon lien au dessus, ça paraît un peu bizarre à l'esprit au départ, mais ce n'est pas si illogique que ça.
[^] # Re: QoS
Posté par benoar . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 2.
http://web.archive.org/web/20071101114640/www.digriz.org.uk/(...)
que j'avais utilisé à l'époque et qui marchait très bien, il dit :
N.B.
shaping only works for OUTGOING packets simply so think which interface to use
when you apply shaping to incoming packets you really are saying which ones
are safe to drop (without generating more traffic, FTP data) and which are
unsafe (UDP as it will not slow down the data transfer and has already
consumed your bandwidth and TCP ACK's are examples).
Ce qui n'est pas bête : dropper des paquets qu'on a déjà reçu, ça ne sert à rien d'autre que de perdre de la BP ... donc au final, le shapping se fait toujours sur l'egress ...
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par benoar . En réponse au journal Unified Flash File System. Évalué à 2.
Oui, c'est plus pratique aujourd'hui pour s'aligner à la taille des pages en RAM, et s'adapter plus facilement aux FS, et pour les grandes tailles de disque. Mais ça ne change rien pour les SSD qui ont des tailles de page différentes. À moins qu'il y ait un effort d'unification à 4ko ? Mais je n'en ai jamais entendu parler. Et puis ça ne règle pas le problème de la taille des erase-block, ni même des "zones" si on passe par une FTL bas de gamme.
des commandes ATA spécifiques aux SSD apparaissent (voir TRIM/Discard)
Oui enfin encore une fois, c'est une adaptation aux FTL, pour qu'elles soient utilisées un peu mieux (enfin, pour qu'elles ne soient pas complètement nazes ... ce qui est mieux que rien, mais pas top). Et ça existait déjà dans les specs CompactFlash (en mode ATA), même si à priori ça n'a jamais été implémenté par personne ... Et puis surtout ça devient assez drôle au niveau des implications que ça a par rapport aux utilisations un peu inhabituelles comme l'accès direct (sans passer par le FS) ou la récupération de données, cf http://marc.info/?l=linux-ide&m=123266840917245&w=2 et suivants, j'ai le flemme d'expliquer pour l'instant.
Bref, ça n'améliore qu'un peu la situation, et surtout, c'est fait dans l'esprit de garder absolument les FTL, pas d'imaginer de travailler sans.
[^] # Re: Acheter des licences OEM à 20€ ?
Posté par benoar . En réponse au journal Acheter un ordinateur portable sous Linux (enfin sans système pré-installé). Évalué à 1.
Oui enfin là les magasins pourraient se retourner contre ce constructeur pour vente liée également, non ? (dans un monde idéal, bien sûr) C'est ça la recette de MS (et aussi pour d'autres cas en dehors de l'informatique) : faire remonter la responsabilité du problème le plus haut possible dans l'échelle pour que les petits acteurs d'en bas ne puissent rien y faire.
Par exemple si je commande un ordinateur avec plus de ram, je ne paye pas la ram au même prix que si je l'avais achetée à part.
BEEEEEP.
Erreur, comparaison avec du matériel, ce qui n'a rien à voir avec du logiciel.
[^] # Re: Acheter des licences OEM à 20€ ?
Posté par benoar . En réponse au journal Acheter un ordinateur portable sous Linux (enfin sans système pré-installé). Évalué à 2.
[^] # Re: QoS
Posté par benoar . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 1.
Explications :
Si un téléchargement est en train d'occuper plein de BP qui fait que le surf sur le web va lentement, et qu'on choisit de "dropper" des paquets de ce gros flux (que ce soit au niveau du DSLAM ou du routeur/*box), l'ordi qui télécharge va juste ACKer les paquets bien arrivés et NACKer les autres, ce qui fait que le serveur en face va en envoyer encore plus pour compenser les paquets "perdus". Ce qui ne va pas arranger la situation.
Quand un serveur envoie du traffic à une machine (qui à priori dans notre cas a un débit plus faible), il va envoyer à bloc au départ et s'adapter en fonction du rythme des ACK de la machine cliente en face. Et c'est donc le rythme d'upload de la machine cliente qui va déterminer la vitesse d'envoi pour le serveur, que ce rythme soit limité parce que l'upload est saturé (genre, quand le client fait du P2P) ou parce que le download l'est (la ligne n'a pas un assez gros début descendant, les paquets font la queue avant le client (genre au DSLAM) et que donc le client ne peut pas ACKer des paquets qu'il n'a pas encore reçu).
Tout ça est géré par TCP, c'est le principe du protocole.
Par contre, pour la TV et le téléphone, je pense que c'est géré autrement car déjà ce n'est pas du TCP, mais par contre c'est du non-connecté donc avec potentielle perte de paquet, mais ça ne fait pas grand chose car ce sont des services "temps réel" donc où on ne renvoit rien si ça foire. De plus, ces débits sont souvent fixes, ce qui facilite le dimensionnage de la QoS descendante.
[^] # Re: Depuis le début jusqu'à aujourd'hui .
Posté par benoar . En réponse au journal Internet, circonstance aggravante. Évalué à 2.
Tu parles bien de ça ?
http://www.youtube.com/watch?v=cE6fQwWggVM
# Acheter des licences OEM à 20€ ?
Posté par benoar . En réponse au journal Acheter un ordinateur portable sous Linux (enfin sans système pré-installé). Évalué à 4.
Si on peut acheter une machine "sans" l'OS, on doit bien pouvoir faire le contraire, non ? Ou alors acheter une souris à 5€ avec chaque licence, pour voir.
Enfin bon, cette histoire d'OEM c'est bien une arnaque made in Microsoft pour faire semblant de respecter la loi sur la vente liée ...
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par benoar . En réponse au journal Unified Flash File System. Évalué à 3.
Ensuite, ce coté bloc de 512, quand je disais que c'était inhérant au système de bloc, ce n'est pas que ça, c'est aussi inhérant à la norme ATA ! (et donc SATA) Bref, ce n'est pas qu'un problème de soft, c'est aussi un problème de hard (enfin, moitié/moitié puisque la stack ATA c'est un bout de driver et un bout de hard). Donc ce n'est pas près, selon moi, de changer.
Comme personne n'a poussé pour un système de connexion spécifique aux mémoires Flash (on aurait peut-être pu faire quelque chose "au dessus" du protocole physique SATA, voire encore plus crade mais plus "facile", au dessus des commandes ATA ?) et bien tout le monde fait des FTL. Et effectivement, personne ne sait ce qu'il fait, garder des secrets ça arrange bien les industriels.
Enfin bref, pour les histoires de capacités, c'est peut-être facile aujourd'hui, mais j'ai entendu que pour simplifier le design des puces de grosses capacités, ils voulaient faire des erase block dont la taille se compte en Mb, ce qui ne va pas arranger les choses. D'ailleurs c'est peut-être déjà le cas, mais on n'en sait rien. Encore du secret.
Pour conclure, oui ce serait bien d'arriver à faire un truc adapté (et libre, en plus) mais je ne pense pas que ce soit faisable vu le comportement des industriels aujourd'hui.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par benoar . En réponse au journal Unified Flash File System. Évalué à 4.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par benoar . En réponse au journal Unified Flash File System. Évalué à 4.
Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc ! Tout le système des block io de linux et des autres OS est basé sur cette assomption.
Ensuite, tu n'as aucun contrôle sur comment est géré le cache, l'écriture, etc. de tes blocs derrière, à moins de tripatouiller dans le système de gestion de périphs bloc du kernel.
Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.
Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ? Peut-être qu'elle flush tout à chaque écriture d'un bloc (= effacement d'un erase block qqpart, récriture du contenu en entier + tes nouvelles données .... super efficace ; je soupçonne les clés USB de faire ça, vu leur durée de vie), ou alors peut-être est-elle plus "intelligente", mais comment va se comporter ton algo avec ça ?
Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.
Voilà, tout ça sans parler du "problème", si votre objectif est de faire quelque chose qui marche partout (vu que vous faites du windows aussi, je suppose que c'est un peu votre objectif) d'arriver à avoir un format assez répandu pour être lu de manière pratique sur beaucoup de machines ...
[^] # Re: ^^'
Posté par benoar . En réponse au message Protocol CARP. Évalué à 2.
[^] # Re: Suite et fin
Posté par benoar . En réponse au message Redimensionner un système de fichier. Évalué à 3.
Sinon, pour l'"ordre", si vraiment tu veux en mettre un, ça dépend de l'opération : si on diminue la taille, on fait d'abord le FS et après la table, et si on agrandi, on fait d'abord la table, et après le FS.
# Visibilité de la news
Posté par benoar . En réponse à la dépêche Le Pacte du Logiciel Libre à la conquête du Parlement européen. Évalué à 9.
[^] # Re: ^^'
Posté par benoar . En réponse au message Protocol CARP. Évalué à 2.
Et puis si tu veux que les autres voient ton message, répond dans le thread.