J'avoue, oui, il m'arrive de dire des trucs idiots.
Néanmoins, si il y a 50 ans, quelqu'un t'avais montré un téléphone portable, un eeePC, ou même un ordinateur normal, ne l'aurais-tu pas pris pour un fous ?
Je n'ai pas la prétention de dire que je suis visionnaire, mais il ne faut pas tout de suite jeter des idées.
L'algo de compression est "plausible". Un hash, par exemple, est censé être différent pour chaque fichier qu'un hash, ce qui pourrait vouloir dire qu'un simple sha256 peut contenir des informations. Oui, elles sont dégradées, mais c'est juste possible. J'avais remarqué que les disques durs utilisent un certain codage pour transformer des suites de bits en ondes, et que ces ondes avaient une forme "binaire" (soit hautes, soit basses). On pouvait par exemple encoder 12 bits dans une onde ne présentant de 10 changements d'états, donc 10 bits. C'est une compression, indépendante des données. Il se pourrait donc qu'en appliquant une compression de ce type, on sache compresser le fichier encore plus. Maintenant, cela m'étonnerais que ce soit possible, mais je donne l'idée.
Pour les backdoors, voir visuellement les différences entre les fichiers est encore une fois "plausible". Je n'avance jamais rien en tant que vérité absolue, je dis juste quand j'ai trouvé quelque-chose, en espérant trouver quelqu'un pour dire si c'est possible ou pas. Alors évidemment, si tout ce qu'on me dit est «c'est pas possible, retourne jouer à la petite voiture», j'insiste.
De plus, ce que j'avais avancé (des différences minimes si on change un truc) est certes invérifiable en compilé, mais où se situe du bytecode llvm dedans ? Si le programme qui génère les cartes de différences détecte quand il y a un décalage, il est possible de trouver des différences ne jouant que sur quelques octets, mais décalant tout le reste. Encore une fois, c'est très probablement impossible, mais pas à 100%.
Et pour la gestion des dépendances, alors là non. Mon gestionnaire de dépendances marche, il fait ce qu'il doit, il m'installe mes paquets, supprime mes conflits (même un conflit de provide, donc si "machin" est en conflit avec "www-browser", FireFox et Konqueror seront supprimés). Bref, la théorie est un peu osée, mais les exemples en fin de journal étaient là pour montrer que ça marchait, du moins un peu. Depuis, cet algorithme a été amélioré pour gérer plus de choses et être plus intelligent. C'est une base simple mais solide sur laquelle on peut mettre ce qu'on veut.
Et pour le noyau, je n'ai pas parlé de 50 fois plus vite, simplement que c'est plus réactif. C'est un fait, il existe un réglage «Server», «Desktop», «High responsive desktop», et Debian le règle sur «Server», et moi sur «High responsive desktop». Je n'ai rien inventé, je n'ai fait qu'appliquer une option de configuration du noyau qui fait ce qu'elle est censé faire : améliorer la réponse du système et l'ordonnancement des threads. Ça s'applique particulièrement bien au démarrage car des dizaines de processus sont lancés en même temps, demandent le disque en même temps, demandent du processeur en même temps, etc.
Donc oui, il m'arrive d'un peu trop m'avancer, mais c'est pas parce que je dis une fois une bêtise que tout le reste est bêtise. Alors oui, si on part du principe que je ne racconte que des tissus d'ânerie, jamais on va me trouver pertinent, mais si on me laisse une chance, qui sait, on va peut-être trouver quelque-chose d'utile dans tout ce que je dis.
[^] # Re: Fais un blog.
Posté par steckdenis . En réponse au journal Pourquoi j'utilise et utiliserai KDE et KOffice 2. Évalué à 3.
Néanmoins, si il y a 50 ans, quelqu'un t'avais montré un téléphone portable, un eeePC, ou même un ordinateur normal, ne l'aurais-tu pas pris pour un fous ?
Je n'ai pas la prétention de dire que je suis visionnaire, mais il ne faut pas tout de suite jeter des idées.
L'algo de compression est "plausible". Un hash, par exemple, est censé être différent pour chaque fichier qu'un hash, ce qui pourrait vouloir dire qu'un simple sha256 peut contenir des informations. Oui, elles sont dégradées, mais c'est juste possible. J'avais remarqué que les disques durs utilisent un certain codage pour transformer des suites de bits en ondes, et que ces ondes avaient une forme "binaire" (soit hautes, soit basses). On pouvait par exemple encoder 12 bits dans une onde ne présentant de 10 changements d'états, donc 10 bits. C'est une compression, indépendante des données. Il se pourrait donc qu'en appliquant une compression de ce type, on sache compresser le fichier encore plus. Maintenant, cela m'étonnerais que ce soit possible, mais je donne l'idée.
Pour les backdoors, voir visuellement les différences entre les fichiers est encore une fois "plausible". Je n'avance jamais rien en tant que vérité absolue, je dis juste quand j'ai trouvé quelque-chose, en espérant trouver quelqu'un pour dire si c'est possible ou pas. Alors évidemment, si tout ce qu'on me dit est «c'est pas possible, retourne jouer à la petite voiture», j'insiste.
De plus, ce que j'avais avancé (des différences minimes si on change un truc) est certes invérifiable en compilé, mais où se situe du bytecode llvm dedans ? Si le programme qui génère les cartes de différences détecte quand il y a un décalage, il est possible de trouver des différences ne jouant que sur quelques octets, mais décalant tout le reste. Encore une fois, c'est très probablement impossible, mais pas à 100%.
Et pour la gestion des dépendances, alors là non. Mon gestionnaire de dépendances marche, il fait ce qu'il doit, il m'installe mes paquets, supprime mes conflits (même un conflit de provide, donc si "machin" est en conflit avec "www-browser", FireFox et Konqueror seront supprimés). Bref, la théorie est un peu osée, mais les exemples en fin de journal étaient là pour montrer que ça marchait, du moins un peu. Depuis, cet algorithme a été amélioré pour gérer plus de choses et être plus intelligent. C'est une base simple mais solide sur laquelle on peut mettre ce qu'on veut.
Et pour le noyau, je n'ai pas parlé de 50 fois plus vite, simplement que c'est plus réactif. C'est un fait, il existe un réglage «Server», «Desktop», «High responsive desktop», et Debian le règle sur «Server», et moi sur «High responsive desktop». Je n'ai rien inventé, je n'ai fait qu'appliquer une option de configuration du noyau qui fait ce qu'elle est censé faire : améliorer la réponse du système et l'ordonnancement des threads. Ça s'applique particulièrement bien au démarrage car des dizaines de processus sont lancés en même temps, demandent le disque en même temps, demandent du processeur en même temps, etc.
Donc oui, il m'arrive d'un peu trop m'avancer, mais c'est pas parce que je dis une fois une bêtise que tout le reste est bêtise. Alors oui, si on part du principe que je ne racconte que des tissus d'ânerie, jamais on va me trouver pertinent, mais si on me laisse une chance, qui sait, on va peut-être trouver quelque-chose d'utile dans tout ce que je dis.