Vincent Pelletier a écrit 75 commentaires

La table de partition contient 4 entrées, donc il peut y avoir au maximum 4 partitions principales.
Mais dès qu'on veut en ajouter une, il faut enlever une partition principale, crééer une partiton étendue (qui sera à la place de l'entrée de la table de partition qu'on vien de supprimer), mettre la partition ancienement principale dans cette étendue, et créer la nouvelle partition dans une partition étendue contenue dans la partition étendue qu'on vient de créer (euh... vous m'avez suivi ?).
Ca donne (P=partition, E=partition étendue) :
Avant :

|--P1--|--P2--|--P3--|--P4--|

Après :

|--P1--|--P2--|--P3--|--E1--|

E1 = |--P4--|--E2--|

E2 = |--P5--|-vide-|

(la partition étendue n'est pas forcément à la place de la 4ème partition)

Mais il y a plus, car dans les partitions étendues, il y a une table de partition complète ! C'est à dire qu'idéalement, chaque partition étendue pourait contenir directement 4 partitions, ou 3+une étendue. Hors, une seule de ces entrées est utilisée, la seconde étant réservée pour une deuxième étendue.
C'est tous ces petits champs inutilisés et sans documentation vraiment officielle qui a fait que je me suis lancé dans SPT.

le code du bootloader est tres petit
Justement, je peux augmenter l'espace libre avant la table de partitions, pour permettre un plus gros bootloader. Avant de fixer une taille, j'attend d'en savoir plus sur la place demandée par grub pour tenir entièrement en un morceau.

Les informations CHS sont à ma conaissance ignorées, puisqu'elles sont dépassées à partir de 8Go. Il se peut par contre que d'anciens BIOS ne sachent que "parler" CHS, dans quel cas il faudra effectivement faire une conversion.

Je n'ai rien vu de tel dans les spécifications, ou alors j'ai mal lu.
J'entend par là que comme SPT n'est pour le moment utilisé nulle part, ça peut être modifié.

Par contre, je suppose que cette limite doit être fixée une fois pour toute
Ca peut être fait à des valeurs différentes pour plusieurs versions. Par exemple, une variante pour systèmes embarqués avec des partitions adressées sur 4 octets et une table sur un secteur, puis une autre variante pour gros serveurs très fragmentés avec une table sur plusieurs blocs...
A partir du moment ou chaque variante s'attribue un numéro de version spécifique, elle peut définir un nouveau format. Il ne faudra conserver que la magic string et le numéro de version, la suite des champs étant lue en fonction du numéro de version.

L'utilisation de liste chaînée est si gênante ?
Je en l'ai pas implémentée pour me concentrer sur la première version, et parce qu'elle revient au principe des partitions étendues (la force d'une chaîne, ... comme l'a dit arachne plus haut). Mais à l'origine, il aurait dû y avoir quelque chose comme ça :
Disque :
1) bootloader
2) partitions chaînées
Partition chaînée :
1) bloc décrivant la partition
2) Partition proprement dit
Avec distinctoin sur la magic string (SPTc par exemple)
Cela pourait convenir à un système de sauvegarde où l'écriture se ferait en une fois.

Dansl'article, par "aucune compatibilité n'est prévue", j'entend une compatibilité "par le bas", c'est à dire que la table de partition soit compatible. Je n'exclu bien entendu pas l'écriture d'un driver pour que le système d'exploitation prene en charge SPT.

C'est toujours une fois les données perdues qu'on trouve les idées qui auraient permis d'éviter le massacre. Dans le sens où je ne connais personne qui imprime ses tables de partitions. Et puisque pour SPT je suis parti d'une feuile blanche et de mon expérience de la table de partitions DOS, pourquoi ne pas simplifier le problème à la racine ?

Pour ce qui est de [c]fdisk. Les outils de partitionnement ou de lecture des informations pour SPT sont encore à inventer.
Peut-être un utilitaire pour imprimer à la chaîne les tables de partitions des disques d'un serveur. Ou peut être ajouter un champ pour savoir si une table a été sauvée ou non depuis sa dernière modification, et un petit rappel au boot si ça n'a pas été fait.

Pour plus de détails, je conseille de visiter le site officiel, j'y ai détaillé autant qu'il m'a parut nécessaire chaque point de ce système et les raisons qui ont conduit à chaque choix.

La plus vieille table de partition référencée dans l'historique de MS-DOS que j'ai trouvé date de la version 2.0, c'est à dire 1983.
La table permettait alors de n'avoir qu'une seule partition de 15Mo. (mais à mon avis peu de gens ont eu un disque de cette capacité à l'époque...)

Je n'ai pas encore abbordé la question du bootloader, mais j'ai lu (je ne retrouves plus où :s ) que le bios se contentait de charger le premier bloc en ram et de lancer l'execution dessus. Si cela est confirmé, la souplesse est complète.

Pas de problème, ça peut être étendu.
Il y a deux solutions, soit on augmente la taille de la liste des partitions, soit on diminue la taille de chaque entrée. Si on considère que l'on n'auras jamais besoin de plus d'une certaine taille (avec 2^64 j'ai pris une marge considérable, c'est 2^32 dans la table dos, ce qui permet déjà de gérer un disque de 2To avec des blocs de 512o) on augmente proportionellement le nombre de partitions maximal.

Je pense qu'il va faloir que je mette en place un forum sur le site officiel pour y rescencer toutes les idées et permettre d'en proposer d'autres de façon structurée.

N'y a-t-il réellement aucun moyen de détecter le format d'une partition par son contenu ?
Je supose qu'en début de partitions liées entre elles en raid logiciel il y a le descriptif d'où trouver l'autre partition, pour que les 2 bonnes partitons soient associées. Dans ce cas, il y a très probablement moyen de reconnaître cette structure.

Si ce n'est pas le cas, pourquoi ne pas rajouter ce champ.
Comme SPT n'est utilisé nulle part pour le moment, on peut le modifier sans problèmes. Et une fois une version basique mise au point, les variantes seront distinguées par leur n° de version.

Pour le moment ce n'est pas prévu.
Mais comme le bootloader de windows est lancé par lilo/grub/..., je crains que le changement n'ait besoin d'être plus en profondeur, et au delà de ce que l'on peut modifier (cette remarque n'est valable que pour le disque sur lequel est windows).
Le driver peut devenir utile pour que windows puisse lire un disque partitionné avec SPT.

Le format EFI ne satisfait pas mon premier critère qui est la simplicité.

Mon idée première est d'avoir un système de partitons à toute épreuve, secourable avec hexedit + la description la plus courte, précise et compréhensible possible de la structure + de quoi convertir un nombre décimal en hexadécimal.

Mais je conçois sans problèmes que l'ont puise espérer d'un système de partitions plus que ce que SPT offre.

Certes mais plutot que de tester si le buffer est assez grand puis de faire un strcpy, autant faire un strncpy, comme ça on s'assure de la propreté du truc, même si jamais le test se retrouve désactivé suite à un patch ou que sais-je.
Je suis partisant du ceinture-bretelles pour ce qui est de la sécurité d'un programme.

Et ça risque même de faire faire un bond en avant pour les logiciels toujours développés :
Il traine tout de même 21,018 strcpy et 4,656 sscanf par exemple. (seuls ces exemples de buffer overflow me viennent à l'esprit à l'instant).

Sans comentaires :
http://www.koders.com/?s=should&_%3Abtn=Search&_%3Ala=*&(...)

about 215,932 results found for 'should'

De toute façon, n'est-on pas sensé ne rebooter que pour changer de noyau ? :)
De ce point de vue là, ça économise des lignes de shell, ce genre de programme/concept.
Il pourrait même être bon d'intégrer ce genre de truc dans les bécanes pour parfaire la portabilité : le bios ou équivalent compile un bootloader qui se charge de charger et/ou compiler la suite, etc.

Hum, je me suis un peu embalé : ce n'est pas télédifusé... Domage.
Ce que j'ai dit reste tout de même applicable.

Pourquoi tant d'aigreur ?
Vu la proportion phénoménale d'émissions parlant de logiciels libres présentées par des animateurs habitués à vulgariser des domaines techniques je ne pense pas qu'il soit bon d'être aussi regardants sur le cadre de l'émission.
Et comme je ne veux pas être pessimiste sur le contenu, j'ose croire que J. Bonaldi se sera bien documenté sur le sujet et saura le présenter avec le pétillant qu'il mettait à présenter inventions et découvertes du temps de NPA (je ne l'ai pas beaucoup vu depuis, ne regardant plus beaucoup la TV).
Pour moi il faut absolument sensibiliser les gens à ce que veut dire "logiciels libres" et une rapide mise en bouche de ce qui est fait dans le domaine.

Une question qui serait bonne à poser lors de ce débat porterai plutôt sur les brevets logiciels, à mon avis, et pas sur le fait que le régisseur utilise un logiciel de montage propriétaire.

L'effet en sera plus grand si ça marche...
Ou encore mieux si un geek traine par hasard dans le coin et arrive à le sortir de la mélasse. (non, c'est pas le moment des rtfm)

Il est apparemment pas mal connu au Japon.
Il a inventé un système de concerts original :
des micros sont disposés dans la salle, et à certains moments un choix est proposé sur un écran géant et le côté où la salle hurle le plus fort est choisi et influence le déroulement du concert.
Ca peut vite devenir un "qui hurle le plus fort", mais j'aime bien ce genre d'interactivité.
Je crois même qu'un de ses concerts a été une sorte de jeu de rôle, toujours avec le public qui fesait les choix.

J'en ai fait une (page de règles de sortie) du temps ou je tentais de déveloper pour smoothwall. Je me suis éclaté pendant 2 semaines à remanier la page du forwarding, faire une page pour gérer les conexions sortantes,... et puis rien. Sortie de la RC6, sortie de la 2.0 finale, et pas d'intégration. Comme depuis le support des "port range" a été ajouté, les modifs que j'avais faites sur les pages comme sur les binaires qui appliquent les mofdifs sont surement obsolètes et ne patcheront pas.
Si quelqu'un est intéressé, je garde les pages dans un coin.

Précisément, la faille RPC windows permet à un ordinateur ayant accès à ce port d'uploader et d'executer un programme sur la victime, ce qui arrive très rapidement si jamais ce port n'est pas protégé lorsque l'ordinateur est connecté directement à internet.
Un firewall (ou un NAT) reste absolument nécessaire pour contrer ce genre d'attaques bêtes et méchantes.
Si la faille peut effectivement venir de l'intérieur, elle vient déjà assurément de l'extérieur. Une distro comme celle là permet de ne se concentrer que sur les failles internes une fois le NAT mis en place.

Il doit y avoir moyen d'installer depuis un ftp : 2 disquettes de boot, un serveur ftp en zone GREEN avec le contenu du cd, et hop.
Je n'ai utilisé ce système que sur Smoothwall, d'où IPCop a forké, mais pas sur IPCop directement.

Susumu Hirasawa permet également de télécharger quelques uns de ses morceaux.
http://s-hirasawa.com/(...) (lien "english" en haut à gauche pour les non-japanophones mais néamoins anglophones)
http://s-hirasawa.com/nowar/(...) <- à l'occasion de la guerre en irak
http://www.teslakite.com/freemp3s/e/(...) <- une liste de plages disponibles

Sa musique est asez spéciale, composée d'une mélodie "informatique" (électronique) et de chants traditionnels de plusieurs origines.

On retrouve aussi sur 2 d'entre eux une certaine "Puce sécurité".
http://bd.educnet.education.fr/mipe/recherche.php?id=24(...)
http://bd.educnet.education.fr/mipe/recherche.php?id=26(...)

Qui a dit tcpa ?

Comme disait Coluche :
Tu payes la baraque à crédit, et dans 20 ans les ruines sont à toi.