Miair Patreau a écrit 191 commentaires

Marche pas, ma notation.

Ce serait plutôt

char * contenu =
"\044\353\150\220\000\274\175\574"
"\003\520\017\520\137\374\076\033"
...
;

ce qui génère un octet nul à la fin, mais voilà, quoi.

Oui, tu as bien compris ce que je voulais dire, bien que je ne vois pas pourquoi il faudrait coder le fichier en base64 : autant le mettre tel quel.

L'équivalent en source serait quelque chose du genre :

unsigned int taille = 15*1024*1024;
char * contenu =
{
'\044', '\353', '\150', '\220', '\000', '\274', '\175', '\574',
'\003', '\520', '\017', '\520', '\137', '\374', '\076', '\033',
... // Et ainsi de suite pour représenter 15 Mo
};

C'est tout de même assez lourd à faire en source, et je suis même pas certain que gcc l'accepte (tiens, je vais essayer :).)

Bah les limitations... Avec un unsigned int pour indiquer la taille des données ça peut tout de même aller jusqu'à 4Go, c'est pas si mal. Sinon, il y a peut-être une structure permettant de définir un offset dans un fichier de plus de 4Go, ou au pire on peut toujours utiliser 2 unsigned int au lieu d'un. Mais bon, de toute façon, à plus de 512 Mo, la méthode que j'indique devient limitée par la mémoire de pas mal de machines, et il faut trouver autre chose.

Concernant la taille d'un tableau, certes c'est limité, mais je ne suggère pas d'utiliser un tableau, je suggère un pointeur.

Dans un script shell, je sais vraiment pas comment on fait.

Dans un programme auto-extractible binaire, je suppose que le problème se situe dans le fait d'inclure un bloc de données arbitraire et arbitrairement grand, la taille de ce bloc de données, et le moyen d'accéder à ces données.

A priori, je me contenterais de définir deux variables importées dans le fichier C qui contient la fonction main() et l'algorithme de décompression :

extern unsigned int code_size;
extern void* code;

Ainsi, l'algorithme de décompression n'a qu'à se reposer dessus et le fichier compile sans accroc.
Reste à créer un fichier .o qui exporte ces variables avec le contenu correct.
Pour ça je ne peux que suggérer de lire la doc expliquant le format de fichier ELF ( http://en.wikipedia.org/wiki/Executable_and_Linkable_Format ), et d'apprendre à utiliser libelf ( http://www.mr511.de/software/english.html ).

Il n'y a pas besoin de savoir faire grand-chose : juste créer un fichier ELF relocalisable (.o) qui contient des données en lecture seule, exportées sous les noms "code_size" et "code".

Une fois un tel fichier créé, il se lie sans problème avec le fichier qui contient l'algo de décompression, et si l'algo est correct, ça devrait marcher sans problème.

Je suggère de faire des essais avec des problèmes triviaux d'abord.

Oui, enfin, ça ce sera valable pour les habitants de la république du Soleil. Déjà, ce serait un grand coup de bol si la version 1.0 de HURD est lancée pour la première fois là-bas précisément, et ensuite, c'est pas dit qu'on ait pas mis au point des systèmes de transports réseaux capables de transmettre une copie du HURD à une machine située à la Division du Centaure en moins de 7 minutes.

Bref, c'est pas si rassurant.

Le seul ennui, c'est qu'il faudra leur faire écouter de nombreux échantillons de sons différents, progressivement, afin de calibrer la partie auditive de leur cerveau au décodage des sons wma (une fois décryptés par le logiciel intégré au tambour de l'oreille, s'entend).

À chacun son interprétation. Moi ce qui m'intéressait, c'était de dire qu'il n'y a pas besoin de connaître les logiciels microsoft pour dire qu'il n'y a pas d'innovation. Et de le dire tout en restant parfaitement exact et ouvert.

En vacances chez sa famille, au bureau de poste, que sais-je ?

> Pourquoi difficile à croire ?

Parce que s'il n'est qu'une question de volonté (du moins dans son cas) pour que toutes les machines dont on s'occupe utilisent ou non windows ou autre ; en revenche c'est plus difficile de ne jamais se servir de la machine de quelqu'un d'autre ou d'une machine publique sous windows.

Quand j'ai dit extrêmement peu, je voulais dire extrêmement peu. Jamais, c'est jamais.

Si j'étais un tout petit peu de mauvaise foi, je dirais que si on s'est servi d'au moins 10 guichets automatiques différents, on s'est servi d'un produit microsoft. (Éventuellement à notre insu, mais bon...)

S'il est vrai que ça me paraît dur à croire qu'il ne se soit jamais servi de windows, et que je ne le crois tout simplement pas, je pense crédible le fait qu'il s'en serve extrêmement peu.

De plus, vu tout le foin médiatique autour de tout ce que fait Microsoft, je vois pas ce qu'il y a de difficile à juger leur capacité d'innovation, sans même se servir de leurs logiciels. Surtout pour un vieux de la vieille.

Donc oui, il trolle, mais ta remarque passe à côté. Troll sur le trollage ^^.

Ah... Ça te pose problème de faire passer ces valeurs avant l'innovation... Ben pas moi ^^. Après, que ça ne soit pas forcément possible en pratique est une autre question.

Pour ce qui est des attentats, Bush, etc : déjà j'ai pas bien compris son histoire d'une tour pas pas attaquée qui s'écroule quand même, donc je vois pas ce qu'il faudrait en penser. Mais je suppose qu'en anglais, il ne fait tout simplement pas dans le politiquement correct et dit tout haut ce qu'il y a tout de même pas mal de gens qui pensent tout bas. Cela dit, c'est vrai que c'est lui qui a mis ça sur le tapis dès qu'on lui a parlé d'élections. Dangereux terroriste ^^ ?

1st Troll :

Aussi longtemps qu'il y aura l'epitanime, je n'aurai rien contre l'epita.

2nd Troll :

En plus, la dernière fois, yen a un qui bossait sur un de ses projets sous freeBSD et on a passé la fin de la première soirée à troller. Sans lui, je n'aurais pas essayé freeBSD si tôt. La preuve que c'est des gens biens.

En fait, tu parles du stage2, là. Le stage1, c'est ce qu'on met dans le MBR, éventuellement mixé à/accompagné d'un stage1.5.

Oui et non de nouveaux.

Avec grub, ça ne marcherait pas "tel quel", il faudrait lui ajouter un mécanisme de détection de SPT et la gestion de ce système de partitionnement pour que ça marche. C'est parfaitement vrai.

Mais on a toute la place qu'on veut pour ajouter ces fonctions, la taille du MBR n'est pas une limite. C'est à cette question que je répondais.

> heu il faut quand mem savoir que le code du bootloader est tres petit, donc il faut que l'implementation puisse etre facilement codable dans le mbr, sinon meme si l'implementation est tres jolie ca ne servira a rien...

Je pense que ça ne change rien à lilo ou grub, dont la première action est d'aller chercher le reste d'eux-mêmes à un emplacement fixe du disque dur (ou d'un autre), emplacement qui a été défini lors de leur installation sur le MBR.

Il y a le initrd, aussi. Au départ, il est conçu pour ce genre de problèmes de bootstrap, quand même.

J'ai eu un BIOS qui disait ça, mais pour lui C: était le premier disque dur, D: le premier lecteur SCSI et E: le premier lecteur IDE ATAPI -_-°. Ça n'avait aucun rapport avec les partitions, ni même avec les notations windows.

Mais peu importe. En effet, on peut tout-à-fait concevoir des BIOS "évolués" qui interprètent la table des partitions et bootent une partition suivant le standard actuellement le plus répendu. On voit ce genre de monstres sur des portables. Mais tout ça, ce n'est pas en accord avec le comportement standard qu'on est en droit d'attendre d'un BIOS. Normalement, pour tenter de booter sur un disque dur (booter sur le premier disque dur IDE étant généralement appelé "C"), le BIOS vérifie le MBR de ce disque et le charge s'il est marqué bootable, point barre. Je parle bien sûr du cas des PC.

Pas mal de gens travaillent à changer ce standard, mais aucun n'est encore "officiel." Pas que je sache, en tout cas.

Je n'ai pas chialé, j'ai fait savoir que je considérais comme erroné le fait de considérer mon précédent message comme inutile (ouf). (Au passage, ce n'est pas le cas avec celui-là, moinssez tous !) Pourquoi ? Parce que c'était le cas. Et que je m'ennuie un peu. Aussi.
Tant qu'à faire, j'aime savoir pourquoi on est noté "inutile" quand ça me paraît pas évident, et là, il se trouve que je l'ai su.

Et je n'ai aucune intention de "me défouler." C'est pas si immature de demander, pas vrai ? De toute façon, tout cet arbre, à part sa racine, est inutile.

J'ai pas compris pourquoi on m'a moinssé (euh, inutile-é) alors que je recentrais vers ce dont on parle et non pas vers l'intérêt de tel ou tel encodage dans le cas général. Enfin -_-°...

Je doute qu'il existe des cas où ça soit intéressant, mais de toute façon quelles que soient les qualités de l'utf-16, ça ne convient pas pour des fichiers sources de C, voyons ! Et c'est bien de ça qu'on parle.

À la rigueur, ça a du sens en rangeant les textes du programme dans un fichier de ressources à part, mais voilà, quoi.

Chtulhu est parmi nous -_-°.

Euh... De l'utf-16 pour du code source de C ? Ce truc qui redéfinit même l'ASCII en lui mettant systématiquement un octet nul devant ? T'es vraiment sûr de ton coup ?

Je suis même pas sûr qu'il existe une obscure option permettant à gcc de gérer ça...

C'est pas le compilateur (gcc, en l'occurence,) qui pose problème avec les encodages. À quelques exceptions près, on peut mettre ce qu'on veut dans les commentaires ou les chaînes de caractère C. Ce sera inséré tel que représenté par le fichier source dans le code objet créé à la compilation.

Ce qui peut poser problème, c'est l'environnement dans lequel sera exécuté le programme : il s'attend à ce que le programme lui demande d'afficher ses textes en quel encodage ?

Un autre point sur lequel j'insiste est que lors d'un dépot de brevet, le déposant protège son invention à une seule condition, dévoiler au public le fonctionnement de son invention.... C'est la raison pour laquelle on dit qu'un brevet est un moteur de l'innovation...

Oui, enfin... Ya encore des gens qui savent pas comment marche FAT ? (et qui ont besoin de le savoir, je veux dire).
Pour le reste, ç'a déjà été tant et tant discuté...

Ne soyons pas trop extrémistes. C'est ce qu'on craint, mais ce n'est pas trop ce qu'on voit.

Il n'y a pas besoin de vraiment porter accusation quand on est une grosse boîte qui a plein de brevets. Le seul fait que les gens sachent qu'on en a, fait que chaque programmeur et chaque petite boîte de logiciels sait qu'il ou elle a une grosse épée de Damoclès au-dessus de la tête et qu'il y a de gros risques à se lancer dans un projet un peu vaste, quel qu'il soit.

Autrement dit c'est bel et bien nuisible, mais les détenteurs de brevets sont difficilement accusables.


Concernant l'idée de considérer le logiciel libre comme de la recherche, c'est intéressant. Deux points noirs :
- Reste à voir si effectivement les brevets ne s'appliquent pas à la recherche "publique", et si n'importe qui peut considérer que ses recherchent sont publiques du moment qu'il les publie.
- Tout le monde ne considère pas les logiciels libres comme de la recherche, et certains ont de solides arguments.