La compression c'est tout le contraire du bas niveau. C'est justement un truc purement algorithmique et indépendant du matériel.
Je me suis sans doute pas très bien exprimé. Ce que je voulais dire, c'est que c'est souvent implémenté dans des couches assez basses, certes en logiciel, mais souvent dans des micro-contrôleurs, et bien souvent quand même, on les retrouve en ASIC (c'est encore plus vrai pour la compression avec perte).
Mais je viens du codage et de la crypto, ce sont des problématiques qui peuvent être très théoriques mais qui se retrouvent pourtant traitées à assez bas niveau dans les piles, très très souvent en matériel, encore plus en embarqué, ça biaise sans doute ma vision. (Mais nous, on ajoute de la donnée inutile ;) )
Si le problème était résolu, on aurait un algo super efficace de la mort qui tue et il serait implémenté par le premier disque dur/ssd/carte sd venue
Ça peut être résolu au sens où on peut prouver qu'on n'est vraiment pas loin du max sans que ce soit très intéressant dans tous les cas.
(qui ne voudrai pas faire x2 sur sa capacité de stockage affichée?).
Celui qui ne veux pas faire un x3 sur le temps d'accès ? Clairement, le passage au SSD a montré que les gens étaient prêts à renoncer à de la capacité pour gagner en temps d'accès.
Pour continuer sur le stockage, des appliances qui de vendent un FS très compressé (à base de dedup et de compression pure et dure), il y en a quand même pas mal. Mais c'est souvent réservé aux cas où c'est un réel besoin. Du point de vue de l'OS et de l'application métier, c'est un stockage par bloc standard. Là encore c'est une problématique traitée à bas niveau (ou en tout cas en embarqué), celui du contrôleur de disque.
Je ne dis pas que c'est jamais intéressant pour les couches hautes de regarder du côté de la compression, je tente juste une explication de pourquoi on a l'impression de moins le voir. Du point de vue du développeur web, la compression des donnée en transit, c'est
une option de config d'apache/Nginx...
[^] # Re: Comment ça perdu?
Posté par aiolos . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 3.
Je me suis sans doute pas très bien exprimé. Ce que je voulais dire, c'est que c'est souvent implémenté dans des couches assez basses, certes en logiciel, mais souvent dans des micro-contrôleurs, et bien souvent quand même, on les retrouve en ASIC (c'est encore plus vrai pour la compression avec perte).
Mais je viens du codage et de la crypto, ce sont des problématiques qui peuvent être très théoriques mais qui se retrouvent pourtant traitées à assez bas niveau dans les piles, très très souvent en matériel, encore plus en embarqué, ça biaise sans doute ma vision. (Mais nous, on ajoute de la donnée inutile ;) )
Ça peut être résolu au sens où on peut prouver qu'on n'est vraiment pas loin du max sans que ce soit très intéressant dans tous les cas.
Celui qui ne veux pas faire un x3 sur le temps d'accès ? Clairement, le passage au SSD a montré que les gens étaient prêts à renoncer à de la capacité pour gagner en temps d'accès.
Pour continuer sur le stockage, des appliances qui de vendent un FS très compressé (à base de dedup et de compression pure et dure), il y en a quand même pas mal. Mais c'est souvent réservé aux cas où c'est un réel besoin. Du point de vue de l'OS et de l'application métier, c'est un stockage par bloc standard. Là encore c'est une problématique traitée à bas niveau (ou en tout cas en embarqué), celui du contrôleur de disque.
Je ne dis pas que c'est jamais intéressant pour les couches hautes de regarder du côté de la compression, je tente juste une explication de pourquoi on a l'impression de moins le voir. Du point de vue du développeur web, la compression des donnée en transit, c'est
une option de config d'apache/Nginx...