🚲 Tanguy Ortolo a écrit 12689 commentaires

C'est surtout un raisonnement normalisateur : presque tout le monde fait comme ça donc on n'a pas à permettre de faire autrement. Heureusement qu'on n'applique pas ce raisonnement partout, sinon dans deux ans on n'aura plus de barre d'URL — ce qui fera la joie des faussaires.

Non non non. En 2013 le nombre de sites codés avec deux pieds gauches, qui sont inutilisables sans JavaScript, a augmenté en effet, mais attention à ne pas déplacer le problème : sauf cas particuliers, le problème ne vient pas du blocage de JS mais de l'incompétence du concepteur du site.

Sauf que ce n'est reconnu nulle part. OpenSearch, on aime ou pas mais c'est le seul standard, et il fonctionne bien comme ça. Il permet de stocker : nom du moteur de recherche, description, icône... Après, pourquoi pas publier un outil pour fabriquer des descriptions OpenSearch à partir de chaînes comme ça ?

Non, mais la barre de recherche ne sert pas qu'à demander à Google, hein. Perso, j'utilise aussi : DuckDuckGo, Wikipédia en français, Wikipedia en anglais, Wiktionnaire en français, le wiki de la boîte où je travaille et OpenStreetMap.

perso, j'aime bien voir l'url avant de cliquer

Elle s'affiche dans une zone éphémère en bas de la page.

C'est bien, mais pas top ça :

• aucune découverte OpenSearch, il faut se les palucher ;
• pas possible de relancer facilement une recherche sur un autre moteur.

Ah, génial, je viens d'essayer et ça fonctionne à merveille ! Bon, eh bien je sais quel est le prochain paquet Debian que je ferai. Enfin, quand j'aurai rattrapé mon retard dans pas mal de choses tout de même...

C'est à régler dans le profil de l'administrateur.

Pour les articles, il faut tout de même un peu de structure externe, avant d'en faire des pages Web, puisqu'il faut pouvoir y identifier : le titre, la description et les mots-clefs — pour les mettre dans l'en-tête HTML —, le chapô — pour l'afficher sur les pages composites — et le corps.

Donc du HTML, pourquoi pas, et c'est d'ailleurs ce qui est utilisé là où c'est pertinent, à savoir pour le chapô et le corps, mais dans une structure en JSON ou autre — système de fichier par exemple : un répertoire pour l'article et un fichier par composant ! —, c'est indispensable.

Je pense pour ma part que l'utilisation de XML n'est pas très appropriée pour les données d'un blog. En effet, qu'a-t-on ? Des articles, des mots-clefs, des catégories et des commentaires. Le plus efficace à mon avis :

• un fichier par article, avec par exemple une structure à la RFC-822 dans le plus pur style de Debian pour stocker titre, chapo et corps ;
• pour les catégories et mots-clefs : un répertoire à chaque fois, avec les articles liés dedans, et dans chaque article un champ indiquant ses catégories et mots-clefs ;
• pour les commentaires : un fichier par article, éventuellement le même que celui de l'article lui-même, avec les commentaires ajoutés à la fin.

Mais les auteurs de PluXml ont fait un choix un peu différent. Ça ne me dérange pas outre mesure, surtout compte tenu du fait qu'ils sont presque les seuls à avoir résisté à la basededonnite aiguë qui sévit dans le mont du ouaibe.

Pour les exemples, il faut utiliser les noms de domaines dédiés à cet usage : example.com, example.net, example.org, example.edu, et le nom de domaine de niveau supérieur example.

Et si je ne tape qu'un mot ? Et si je veux relancer ma recherche dans un autre moteur de recherche ? Tout, ça change.

Pareil pour moi, je n'ai trouvé aucun autre navigateur Web que Firefox avec un outil pour lancer des recherches qui :

1. prenne en charge la découverte OpenSearch ;
2. à la suite d'une recherche, conserver les termes de la recherche sans les remplacer par l'URL de la page de recherche ;
3. permettre de passer rapidement d'un moteur de recherche à un autre.

Ah, et à propos de traduction, on truc qui serait génial, ce serait d'utiliser la langue appropriée pour chaque visiteur.

L'interface d'admin est-elle également traduite, au moins en anglais ? C'est la seule chose que j'attends avant de pouvoir enpaqueter ça pour Debian...

Un des avantages est de démarrer "en direct" sans passer par un gestionnaire d'amorçage (paramètres EFI Stub dans le kernel), la contrepartie étant de passer les paramètres initialement dévolus à GRUB (ou LILO) en dur dans le sus-dit kernel.

Ça c'est amusant parce qu'à une lointaine époque, on pouvait faire exactement pareil en BIOS, démarrer directement le noyau. Cette fonctionnalité a été retirée, mais elle revient pour UEFI... Ceci dit, personnellement ça ne m'intéresse pas du tout, pas assez souple, si quelque chose déconne avec un noyau on est fichu.

Techniquement, oui : le BIOS se moque des partitions, tout ce qu'il lui faut c'est une zone d'amorçage au bon endroit, ce qu'on peut avoir avec GPT. En pratique, il faut que ton chargeur de démarrage prenne en charge GPT, lui, or c'est le cas pour GRUB.

À l'inverse, un UEFI peut démarrer avec un disque dur partitionné en MBR.

est ce qu'il existe un équivalent de UEFI sans cette cochonnerie en FAT?

Je ne crois pas non. Certaines cartes mères peuvent prendre en charge d'autres systèmes de fichiers en plus, par exemple HFS+ pour les cartes mères Apple, mais la prise en charge de FAT est obligatoire.

En revanche, vu ce qu'on stocke dessus, nul besoin de prendre en charge les noms longs, et sans cela, je ne crois pas qu'il y ait de brevets problématiques pour FAT, en tout cas pour les FAT12 et FAT16 qui ont plus de vingt ans.

(Excuse-moi de te dire ça, mon pauvre José, mais tu confonds un peu tout. Tu fais un amalgame entre la coquetterie et la classe.)

Ce n'est pas tout à fait cela : tu confonds deux choses, BIOS/UEFI et partitionnement MBR/GPT.

UEFI est un type de firmware de carte mère et de convention d'amorçage, conçu pour remplacer le système BIOS.

GPT, la GUID Partition Table, est un type de table de partition conçu pour remplacer le partitionnement MBR. Par rapport à MBR, elle apporte une prise en charge des périphériques plus 2 Tio et de plus de 4 partitions sans recourir à l'affreux système des partitions « logiques ».

Un BIOS démarre à partir d'un secteur de 512 octets placé à un endroit précis du début disque dur, ce qui peut se faire en GPT comme en MBR.

Un UEFI démarre à partir d'un exécutable placé sur une partition d'un type précis, formatée en FAT, ce qui peut se faire en GPT comme en MBR.

Je n'avais pas compris cette phrase, ou plutôt pas compris ce qu'elle impliquait :

En effet certains observateurs attentifs se sont rendus compte que les temps des athlètes nageant dans les lignes d'eau 1, 2, et 3 étaient toujours meilleurs dans un sens que ceux nageant aux lignes 6, 7, et 8 dans l'autre.

En fait, les temps des nageurs dans les lignes 1, 2 et 3 sont meilleurs dans un sens, et ceux des nageurs dans les lignes 6, 7 et 8 sont meilleurs dans l'autre sens.

Un seul mot pour répondre à ces interrogations : anonymat.

Personnellement, je reste sur mon canapé à regarder le spectacle de l'extérieur avec un seau de pop-corn à portée, en pensant très fort : « on vous l'avait bien dit ».

Donc utiliser l'anglais, c'est sale ?

Très. Pouah messire, c'est la langue de l'anglois abominatif.

Toi tu n'as jamais essayé de faire des sauvegardes sur clef USB. Moi si : au bout de deux mois, a plus clef USB. Enfin, il y a toujours, mais inutilisable, les données dessus n'étant même plus lisibles.