Cyrille Pontvieux a écrit 499 commentaires

Probablement pas.

En vérité t'en sais rien. Et presque personne ne sait. Mais comme tu disais un peu plus haut, c'est un problème de confiance. As-tu confiance en ces entreprises ? En général ? Sur ce sujet précis ?
La réaction de la plupart des gens c'est « Bah c'est un truc connu, ils doivent pas faire des trucs illégaux ni douteux ». Mouais, ça reste une supposition. On n'en sait rien, et on suppose que tout va bien tant qu'on n'a pas la preuve du contraire.

Moi je suis ptre un peu parano mais je donne jamais mes identifiants de courriel ou de messagerie instantané à un site, qu'il soit connu ou non. Mais bon, si ça se trouve, c'est une précaution inutile…ou pas. On sait simplement pas.

Merci pour ces infos :)
Je n'avais pas été à cette conférence. C'est intéressant de voir que ça va dans le bon sens.

Je me souviens qu'il a expliqué qu'un nombre de choses non négligeables sont difficilement, sinon pas du tout, accessibles au clavier. L'autre problème était, pour un handicap visuel important, que les données retournées par les différentes parties de l'interface de Gnome 3 sont difficiles à identifier ou ne sont pas identifiées du tout. Du coup impossible de naviguer dans l'interface.
Je ne suis pas, mais alors pas du tout, un spécialiste de Gnome 3, donc je ne saurais être plus précis, désolé. Pour la mini-conférence elle n'était pas filmée. Dommage.

Je donnais l'exemple de l'aveugle puisque c'était le cas de l'orateur. Par contre il a parlé aussi des autres handicaps. Ce n'était pas seulement axé sur le problème de la vue. Quand on a un handicap on est forcément plus conscient de ce qui peut poser problème avec d'autres handicap que le sien. Ce n'était donc spécialement orienté déficience visuelle.

Après, tant mieux si Gnome 3 s'améliore et arrive à intégrer toutes les problématiques pour gérer les différents handicaps. Le constat était juste qu'à présent c'est pas bon. Faut pas non plus déterrer la hache de guerre. Tant mieux si ça fait réagir des développeurs et que des solutions sont trouvées pour les versions ultérieures non ?

Oui du point de vue de l'accessibilité lol, j'avais pas pensé qu'on pouvait le comprendre autrement. C'était pas un appel à troll.
De quelle manière ? Je n'en sais rien. Je répète simplement ce que m'a dit la personne qui en savait bien plus sur le sujet que moi. Après, ils sont pas beaucoup chez Xfce. Avoir les meilleures intentions du monde ne suffit pas à avoir le temps de tout faire :)

Ouais enfin, après avoir été à une mini-conférence sur l'accessibilité au JDLL la semaine dernière, j'ai appris que que Gnome 3 était totalement inutilisable par une personne handicapée. Parmi les deux intervenants, un était aveugle et nous expliquait que seul Gnome 2 lui permettait d'utiliser son PC, que les bureaux comme Xfce et LXDE sont en phase de devenir utilisable, que KDE (et surtout Qt) vont dans le bon sens mais que ça va prendre encore un peu de temps, et donc que Gnome 3 était le pire de tous en terme d'accessibilité et d'utilisabilité.

Pour la faute, oui, mais il manque un bout à la phrase ou alors elle n'est pas correctement construite.
Si on enlève la subordonnée relative, il reste :
« John Carmack développeur de renom chez IdSoftware. » Du coup, il n'y a pas de verbe dans cette phrase, c'est un peu bizarre. En ajoutant le verbe "être" au minimum, on en fait une phrase correcte.

Mais j'avais bien compris de quoi il s'agissait…et non ce n'est pas stable.
Les outils en espace utilisateurs qui s'interfacent avec le noyau doivent se mettre à jour de temps en temps. Essaye de mettre une kernel récent sur une vieille distro, tu vas voir que la libc sera foireuse par exemple.
J'ai retrouvé la vidéo dont je parlais plus haut : https://www.youtube.com/watch?v=L2SED6sewRw (si qq1 a une autre source que youtube…)

Gné ? Linux n'a jamais été stable ni en API ni en ABI. C'est d'ailleurs pour ça que Greg Hartman a bien expliqué que de vouloir maintenir des drivers (propriétaires ou pas) de son côté sans intégration dans les sources du noyau est peine perdu et qu'il sera toujours difficile à une entreprise de suivre les évolutions et refacto qui sont fait dans le noyau si le code en question n'est pas dedans directement.
Donc non Linux n'a ni une API ni une ABI stable, et la compatibilité ascendante ou descendante n'existe que dans ton commentaire.

Je vais me faire l'avocat du diable….mais tu trouves que les gars de Gnome font mieux ? Ils écoutent leurs utilisateurs ? J'ai pas l'impression moi…

Non pas forcément.
IPv6 a d'autres avantages, comme l'unicast. Ça permet aussi de tester que les OS, le matos, et les logiciels fonctionnent bien en Ipv6. La Freebox, que l'on va considérer comme du matos (vu qu'on n'a pas accès à l'OS et qu'on ne peut pas le modifier) peine un peu de ce côté pour le moment.
On peut vouloir faire des zones privées avec de l'Ipv6, ce n'est pas incompatible.

L'interface c'est Map, HashMap est une des implémentations possibles. Et ça c'est juste de l'objet standard et ça ne pose aucun problème.
L'exemple pour le XML par contre, c'est vrai que c'est chiant. Par contre ça a une réelle utilité, et c'est utilisé. Ça permet de fournir d'autres implémentations (qui s'enregistrent au près de la fabrique) et qui font un travail un peu différent, ou plus rapide, ou que sait-je d'autre. Par contre c'est un peu dommage qu'il n'existe pas un masquage ou wrapper pour éviter d'écrire ce genre de choses à rallonge quand on n'est pas intéressé par le type d'implémentation précise qui sera choisi.

Il existe surtout pas mal de choses qui sont manquantes dans la grammaire Java qui peuvent être chiantes au quotidien, mais ce n'est pas du tout les exemples que tu montres.
Java 7 améliore quelques petites choses sur le langage (switch sur un type string, catch multiples, meilleure gestion des ressources systèmes ouvertes (équivalent des file descriptors), syntaxe diamond pour l'intialisation de type générique), mais on est encore très loin de la souplesse de grammaire qu'offre un langage comme Python par exemple avec ses dictionnaires, tuples et surtout toutes les méthodes qui tournent autour.

Car tout de même, dans un langage procédural (fusse-t-il objet), on a majoritairement un enchaînement de blocs de contrôles (if, while, for, switch, try catch), de manipulation arithmétique, affectations…et de manipulations ensemblistes.

Et sur ce dernier point que Java est très très loin derrière les autres langages. C'est la panacée du tout‑objet, qui fait qu'il n'existe qu'un seul type primitif de liste, qui est très très limité, et que pour le reste il faille passer par des objets/classes ensemblistes (java.util.Collection) qui ont une API très pauvres. Du coup il existe un tas de bibliothèques qui permettent d'ajouter quelques fonctionnalités ensemblistes, mais on reste sur une manipulation orientée objet, ce qui n'est pas du tout adapté pour ce cas de figure. De plus, ces librairies externes ne sont pas considérées pour une future inclusion dans le JRE, ce qui reste donc pénalisant.

Je pense qu'il existe d'autres domaines que la pauvreté du domaine ensembliste qui pourrait être cité, mais c'est vraiment celui qui me dérange au quotidien.

Elle est où la gestion des paramètres du script init original, à savoir :

# change this line if you want dnsmasq to serve an MX record for
# the host it is running on.
MAILHOSTNAME=""
# change this line if you want dns to get its upstream servers from
# somewhere other that /etc/resolv.conf
RESOLV_CONF=""
# change this if you want dnsmasq to cache any "hostname" or "client-hostname" from
# a dhcpd's lease file
DHCP_LEASE="/var/lib/dhcp/dhcpd.leases"
DOMAIN_SUFFIX=`dnsdomainname`

Ainsi que :

if [ ! -z "${MAILHOSTNAME}" ]; then
OPTIONS="$OPTIONS -m $MAILHOSTNAME"
fi
if [ ! -z "${RESOLV_CONF}" ]; then
OPTIONS="$OPTIONS -r $RESOLV_CONF"
fi
if [ ! -z "${DHCP_LEASE}" ]; then
OPTIONS="$OPTIONS -l $DHCP_LEASE"
fi
if [ ! -z "${DOMAIN_SUFFIX}" ]; then
OPTIONS="$OPTIONS -s $DOMAIN_SUFFIX"
fi

?

Dans le deuxième lien que tu donnes, la deuxième vidéo, on voit bien que le type peut taper des commandes unix à distances…

Le deuxième.
Je l'ai modifié un peu aussi pour ajouter quelques options pour pouvoir faire des votes avec des poids différents selon le groupe auquel appartient la personne.
Voici le code que j'utilise (avec mes extensions) :
<doodle login single supergroup=ca votegroup=actifs| Président 2012 >
^ Nom1 ^ Nom2 ^
</doodle>
Voici un aperçu de ce que ça donne une fois le sondage fini (ici j'ai laissé l'affichage de ceux qui ont votés, on peut aussi le rendre invisible) :

Oui je l'utilise pour le wiki de mon assoc, pour prévoir les réunions et d'autres prises de décision. Ça marche très bien et c'est facile à mettre en place.

Oui bien sûr.
Voici mon .git-prompt.sh modifié : http://openpaste.org/786ac73d
Voici le .svn-prompt.sh que j'ai fais : http://openpaste.org/5Fa72769
Et voici le contenu de mon .bashrc (j'utilise bash, pas sûr que tout ceci marche bien sur zsh) : http://openpaste.org/C858753f

J'ai pas trouvé comment changer le positionnement des variables avec printf, genre comme fait gettext. Si quelqu'un connaît un moyen (portable) je suis intéressé.

C'est très (trop) lent.
Testé avec bash.
J'ai plusieurs VCS avec différentes sources et types. Avec du git c'est à peu près ok, avec svn c'est très lent, mais dans tous les cas c'est bcp plus lent que le script ".git-prompt.sh" que j'avais trouvé sur le net (par Shawn O. Pearce, ça doit être sur github, je sais plus où, en GPL v2) que j'ai adapté un poil et un ".svn-prompt.sh" que j'ai fais moi-même en suivant les principes de git-prompt. Franchement je vois pas la différence entre avant et après avec ces deux scripts là. Par contre avec liquidprompt…je sens bien le liquide épais s'écouler entre chaque prompt :)

En effet. Mais le FS est toujours accédé en lecture seule. C'est simplement que ce fichier est accéder en mode bloc en écriture, le système de fichier n'est pas modifié.
En effet, le fichier grubenv doit avoir déjà une taille défini à l'avance et doit être contiguë.

Ah oui, j'avais pas pensé au cas où /boot serait une autre partoche. Dans ce cas, en effet le search prend son sens.
Merci de l'explication.

Mais encore une fois, je ne vois pas la différence avec grub1 ou grub2 sur ton exemple.
Si tu veux résoudre le même problème avec grub2, tu vas dans la doc, qui va te donner les même genre de commandes que celles de syslinux/extlinux, et tu vas te retrouver à taper à peu près la même chose.

Grub2 permet plus de chose que syslinux, celà ne veut pas dire qu'il est complexe de l'utiliser.
Je voudrais juste préciser que je n'ai rien contre syslinux, au contraire, j'aime bien aussi ce bootloader qui est également clair et bien fonctionnel. En fait, je l'utilise sur USB pour chainloader vers du grub2, car l'installation de syslinux dans le MBR est plus simple (pour la plupart des gens et clés USB en fat32) qu'avec un grub2.

Par contre, je trouve qu'on regarde souvent l'utilisation d'un soft, intégré dans cette merde d'Ubuntu, au lieu d'évaluer le soft lui-même. À mon avis, ici c'est le même problème. grub2 est évalué via l'intégration pourrie d'Ubuntu (je vais me faire moinsser pour dire ça, mais bon…)

Je vais répondre simplement : non c'est faux.
Comme indiqué plusieurs fois plus haut, le fichier de config de grub2 c'est grub.cfg, tu l'édites avec un éditeur de texte, celui que tu veux, et basta. Et le fichier n'est en aucun cas différent entre un 32 ou 64 bits (grub2 tourne en mode émulation 32 bits sur un processeur 64 bits de toute façon, et sur un seul processeur/core, pour info).
Je le répète, mais le grub-mkconfig n'est pas nécessaire du tout pour changer un truc dans la config de grub2, donc pas besoin de chrooter ou je ne sais quoi.

Effectivement ce n'est pas spécifié dans la dépêche.
En gros, ce qu'on peut noter comme différences (qui peuvent n'avoir aucun intérêt pour toi) :
- le "stage 1.5" est devenu obligatoire pour booter, permet plus de chose (une console de secours est toujours disponible), et contient un ensemble de fonctionnalités variables (préciser à la compilation). Son nouveau nom est core.img
- le "stage 2" n'existe plus, et c'est juste des modules que l'on charge au besoin. Ces modules peuvent définir un driver de système de fichiers, un interpréteur de commande (parser) ou un ensemble de commandes.
- gettext et utf-8 qui permettent d'avoir une traduction des menus (pour les trucs qui nécessitent des vrais menus, genre un liveCD, ou un truc type SystemRescueCD).
- des possibilités de chainloading dans tous les sens, qui permettent une intégration de ou vers grub2 simplifiée.
- la gestion de nouveaux types de systèmes de fichiers, de table de partition, de BIOS/EFI, d'architecture.
- un vrai shell disponible au boot, qui permet de faire un tas de modifications si on a un problème de boot, ou pour booter quelque chose d'exotique ou inhabituel.
- langage de script shell évolué qui permet de faire des scripts plus simple et plus manitenable (utile aux distributions principalement).
- une gestion des thèmes améliorée.

Ce serait bien de lire le tout et pas de répondre à côté de la plaquer, merci.
Les lignes de syslinux et de grub2 font exactement la même chose : afficher une ligne de menu, charger le noyau, charger l'initrd, booter.

Les lignes qui ont été ajoutés par Sylvain sont inutiles au boot. Sauf évidemment le module pour gérer ses partitions GPT…ce que ne peut pas faire syslinux pour le moment (mais je ne doute pas qu'il finisse par les gérer).
Les lignes ajoutées, permettent de charger une carte de clavier bépo (inutile pour sélectionner la ligne de boot, utile uniquement s'il veut modifier un truc à la volé dans grub2, chose impossible avec syslinux), de dire à grub2 de ne pas changer de résolution au moment de charger le noyau (c'est sympa, mais pas indispensable), charge le module gzio (je ne sais pas pourquoi il charge ce module), charge le module de gestion de partitions GPT, charge le module de gestion d'ext1/2/3/4 (mais ça me semble inutile, je pense qu'il est déjà chargé).
La ligne avec le search permet de définir la variable "root" (permettant de donner la partition sur laquelle démarrer) en cherchant la partoche par UUID, inutile puisqu'on a déjà défini la variable root.
Ensuite y'a deux "echo" qui servent à rien.

Ouais sauf que non, justement.
Là il a copié-collé un truc généré et l'a adapté.
Si tu veux comparer à fonctionnalité égales (donc en supposant que ces partitions sont pas sur du GPT mais du MS-DOS), ça donne :

menuentry 'Archlinux, boot dans l’initramfs' {
  set root='(hd0,msdos1)'
  linux   /boot/vmlinuz-linux ro break=y
  initrd  /boot/initramfs-linux.img
}
menuentry 'Archlinux, système de sauvegarde sur sda6' {
  set root='(hd0,msdos2)'
  linux   /boot/vmlinuz-linux ro  
  initrd  /boot/initramfs-linux.img
}

Ce qui fait 10 lignes. Alors faudrait ptre un peu comparer des choses identiques.