A mon avis, l'utilisateur final ne verras pas de grande différence entre wayland et Xorg. Voire même, il n'en verra pas du tout.
A ce que j'ai cru comprendre au fur et à mesure des releases de wayland, c'est qu'il sera plus maintenable, et plus léger car non dépendant du grand nombre de "sous-protocoles" nécessaires pour pouvoir oser se prétendre serveur Xorg. Il devrait également permettre une meilleure sécurité par le fait qu'il ne s'occupe que d'affichage, et pas de l'entrée contrairement à Xorg.
Mais au final, seuls les développeurs verront la différence: moins de coût de maintenance, plus de facilité pour créer des serveurs graphiques alternatifs, et potentiellement un système moins gourmand… sauf que si on allège de 20Kio en RAM la gestion de l'affichage, avec des bouzins comme Gnome ou KDE, personne ne verra la différence, au vu de la lourdeur de ces derniers.
Sauf si tu es le genre d'utilisateur à utiliser fréquemment les TTYs ou à lancer plusieurs serveurs graphiques, puisqu'il semble au vu de la dépêche, que ces switch seront plus efficaces? Personnellement, ça ne m'arrive pas tous les jours mais c'est une fonctionnalité utile, et la voir plus réactive me ferait grand plaisir :)
Après tout, tu es libre de le faire, tout comme de contribuer au code. Et nous, on est libres de te demander ce que tu fais pour améliorer ce dont tu te plains: quel est ton dernier patch sur Xorg ou sur wayland/weston, stp?
J'ai confiance en Debian pour ce genre de choses. Comme tu l'as souligné, quid de kFreeBSD? Après tout, cette version de la distro est bien moins obscure que le port Hurd, donc on peut supposer qu'elle à une certaine importance aux yeux des mainteneurs Debian.
En effet. Et peut-être qu'un jour on aura tout le système configurable à partir de l'installateur… le kernel, l'init, le serveur d'affichage, le bureau… ça serai génial ça.
A l'heure actuelle il n'y a que le bureau… pour certains autres outils le seul choix est de ne pas installer.
Je suis assez ignare sur ce sujet, mais il me semble avoir lu par ci et par là qu'avant, c'était un fichier qui contenait une description statique des périphériques.
Du coup, dans le cas, par exemple, d'un téléphone où de toute machine sur laquelle on ne peut pas ajouter de nouveaux périphériques plug-and-play, udev me semble totalement inutile ( si rien ne change, gérer dynamiquement les choses est juste débile ).
Pour les non plug-and-play "actifs" ( j'entends par actif qui ne fasse pas qu'émettre ou recevoir un signal analogique, c'est à dire plus compliqué qu'un bête écouteur ou chargeur de batterie ), je ne sais pas du tout si udev fonctionne ( ça fait bien longtemps que je n'ai pas vu de périphériques non plug-and-play "actifs" ).
Le seul souci étant, au final, d'avoir la bonne table au bon moment, ce qui peut être pénible pour des PCs ( portable ou non ) sur lesquels on branche pour certains régulièrement des périphériques USB par exemple, qui me semble actifs.
Mais, comme j'ai dit, je suis totalement novice en la matière et j'ai probablement effectué de gros raccourcis disgracieux. Si c'est le cas, je suis preneur de toute remarque constructive ( autre que rtfm, parce que, basiquement, ce type de fm nécessite pour être bien compris une certaine connaissance de toute l'archi linux, chose qui n'est pas à ma portée actuelle. ).
Dbus c’est cool, mais on devient très dépendant d’une foultitude de services et parfois ça foire. Aujourd’hui Dbus est aussi critique que le noyau, si on a un bug dbus plus rien ne fonctionne, ni le son, ni le réseau, ni l’identification, et si une api dbus se vautre à cause d’un problème sous-jacent ça peut être tout aussi gênant.
DBus est peut-être critique pour toi, mais pas pour tout le monde.
Il offre certainement un grand confort, notament de permettre de configurer son réseau via une zolie IHM sans devoir devenir root, mais, ça ne signifie pas que ce ne soit pas faisable.
Et, même si je conçois très bien que mon cas personnel n'est pas représentatif d'une quelconque majorité, je peux te dire que jusqu'a présent, mes machines sur lesquelles dbus est installé, mais pas démarré ( dépendance dure de quelques logiciels et flemme de faire un paquet bidon… ) il ne me manque aucune fonctionnalité.
Pour le réseau, par exemple, j'édite tout bêtement /etc/network/interfaces à la main ( et pour les desktop, ça veut dire le faire 1 fois par installation, puisqu'au final la plupart des gens à un dhcp sur le LAN… ) . Pour le gestionnaire de session… j'avoue, je n'en utilise pas, je me log avec login, et un script lance startx si je suis en tty1.
Largement suffisant pour mes besoins, en somme.
Pulseaudio? Je crois que j'ai 1 ou 2 paquets avec pulse dans le nom d'installés ( mpd, de mémoire ), mais ce qui est certain, c'est que je n'ai aucun daemon PA qui tourne.
Donc, non, dbus est loin d'être aussi critique que le kernel. Pas même aussi incontournable que Xorg. D'ailleurs, à l'heure actuelle, il n'y a bien que linux et Xorg, que je considère comme des outils vitaux. Tous les autres ont des alternatives plus que viables. Et Xorg sera remplacé par wayland, un de ces 4. A voir pour linux également, il faudrait que je teste debian kfreebsd.
Joli étant totalement subjectif, moche l'est aussi.
De plus, après quelques bières, la frontière entre les 2 est quand même vachement moins nette, donc, une bonne serveuse, même moche, finit par être jolie, cqfd.
Un bon réseau social, c'est un bar dans lequel il y a de bonnes bières servies par de bonnes serveuses.
Donc, un bon réseau social libre, c'est la même chose, sauf qu'il donne le code source de la bière. Ca vaut aussi pour celui de la serveuse, à ceci près que j'ai toujours des réserves de patchs sur moi, mais comme je ne veux pas contribuer à toutes les serveuses, il ne faut pas une licence GNU, je préfère pour cet usage particulier la WTFPL.
j'ai essayé de comprendre Automake mais en vain jusque là…
C'est généralement ce que je rétorque quand on me demande pourquoi je n'aime pas les autotools. J'ai dis cmake, mais ne te laisse pas faire, il y en a pleins d'autres. CMake est juste celui que j'ai testé en 1er après les autotools, parce que plus de gens font plus de bruit à son sujet.
Je ne sais pas ce que tu as testé, mais ce n'est pas surf. surf n'a pas d'interface, il utilise dmenu,
En effet, je n'étais pas sur que c'était dmenu ou pas.
Ton test je ne le comprends pas parce qu'il n'y a que firefox dans ces pires moment qui met plus 5s à démarrer et à afficher perdu.com.
Je ne connais pas la raison des résultats, je ne connais que les résultats. Debian stable à 95%, amd64.
Tu l'a installé comment ? Tu as récupéré les sources où ? Tu as appliqué quel patch ? Tu dis que c'est embêtant de devoir tapper l'url local complète, tu peut très bien le configurer pour ne pas avoir à le faire.*
#aptitude install surf
(enfin, non, en fait j'utilise l'interface ncurses d'aptitude, mais ça reviens strictement au même). 0 changement de configuration.
Parler de la vitesse de téléchargement sui serait discriment pour télécharger perdu.com (une seule requête de 204o sans compter les entêtes http), c'est juste rigolo.
Ca me paraît aussi très étrange, vu que je connais la taille de cette page, moi aussi. Mais par téléchargement, j'entendais également les étapes du genre résolution de nom DNS et tout le reste. Qui sont une partie du téléchargement, tel que je l'entendais. Ce n'était peut-être pas super explicite, je te l'accorde. Mais encore une fois, comme je l'ai dis, je n'ai pas passé valgrind dessus, je ne sais pas quelle étape rends tout cela si long.
La seule chose que je constate, c'est la lenteur impressionnante de cette opération (l'affichage est immédiat, donc ce n'est pas le moteur de rendu) avec chaque navigateur minimaliste basé sur webkit que j'ai testé (dillo n'as pas ce souci, mais n'est pas basé sur webkit). Cela n'inclue pas juste les 3-4 en question.
Ca ne peut être la faute de webkit, puisque chromium lui possède la vitesse habituelle. Que cela te froisse, je m'en fiche autant que le fait que les développeurs de ces outils se fichent que ceux-ci ne me conviennent pas.
Que surf ne te convienne pas ça je l'ai bien compris (mais ne t'inquiète pas les développeurs s'en foutent), mais essaie de comprendre les logiciels dont tu parle avant de leur cracher dessus (j'immaginais que tu te renseignais un peu avant d'installer tout et n'importe quoi sur ta machine).
Bah… je ne prends pas 2H par logiciel que j'aie envie de tester, je l'admets bien volontiers. Sinon, il me faudrait 2 ans avant d'avoir un système exploitable…
En général, je lis les descriptions (ainsi que les debtags & dépendances, c'est souvent instructif) que me fournit mon gestionnaire de paquet (je n'utilise pas LFS justement parce que je n'ai pas envie de faire tout le boulot moi-même), et si il y a un souci que je constate sur un outil que j'estime utilisable et le meilleur de ceux que je teste (généralement j'en teste plusieurs en même temps, pour me faire une première opinion avant de me plonger dans les configurations et autres doc), je vais jeter un oeil sur la page officielle du site.
Celle dédiée a surf est très clean, mais aussi très exempte d'informations. Y compris au sujet du patch que tu cites (ou alors il n'a pas un nom évocateur, je ne sais pas).
Donc, oui je me renseigne un peu avant. Mais non, je n'y passe pas 2H et je ne le ferais pas, sauf si c'est vraiment nécessaire. Dans le cas des navigateurs web, c'est loin, très loin, de l'être.
(épargne nous les bench farfelus qui comptabilisent la vitesse de tes cliques par contre).
Toi seul appelle cela un bench. Pour ma part, je n'aurais jamais l'outrecuidance de qualifier de benchmark des tests aussi peu poussés et soumis à l'erreur humaine. Sans parler du fait que la quantité de situations testée est ridiculement réduite. Mais permets malgré tout de s'apercevoir qu'il y a un souci.
En plus, je n'ai effectué aucun clic dans cette opération.
linuxfr t'oblige à prévisualiser, tu ne te relis pas ?
Je relis. Avant de pré-visualiser. Quand j'ai un doute sur ce que j'ai utilisé, c'est à dire quand j'utilise des choses comme le format pour le code source, je pré-visualise réellement. Si je ne fais que taper et copier/coller du texte, non.
Il semble d'ailleurs qu'une de mes erreurs soit liée au # qui transforme toute la ligne en titre, alors que l'aide mémoire indique qu'un titre doit être encadré par ce caractère. Comme j'ai l'habitude d'indiquer si j'exécute une commande en tant que root ou user, je mets les $ et # correspondant habituellement à cette distinction.
gérer proprement plusieurs jeux dans un seul fichier (je parle de centaines) sans que ça devienne illisible ? (je pensais à faire un fichier contenant les jeux de tout un système, système étant en partie une collection de jeux)
définir facilement et proprement des sous-formats ? (par exemple un MegaDriveGameData contenant des spécificités à la Mega Drive et étendant GameData)
Tu n'as qu'a copier/coller 100 fois ton texte dans le même fichier, et me dire que tu trouves ça lisible… en toute bonne foi, bien sûr.
Enfin, au niveau des formats que j'ai cités: JSON en est capable, celui de debian aussi ( même que c'est ce qui est fait dans "/var/lib/apt/lists/*". Je ne le savais pas, mais ta question m'a poussé à regardé comment c'était foutu…), et je ne doute pas que YAML le puisse aussi, je connais moins ce format (je me le garde juste en mémoire pour le jour ou j'en aurai peut-être besoin. Ceci dit, wikipedia montre très bien ce qu'on peut en faire).
définir facilement et proprement des sous-formats ? (par exemple un MegaDriveGameData contenant des spécificités à la Mega Drive et étendant GameData)
Ce que tu dis me fais penser à l'héritage, en POO. C'est le truc que l'on apprend a arrêter d'utiliser à tout bout de champ (comme ce que je prône pour XML en fin de compte) au bout d'un moment, parce que ça pose plus de souci que ça n'en résout.
Debian résout ce problème de façon très simple: les debtags.
Un extrait d'un fichier de /var/lib/apt/lists fera un bon exemple, je pense:
peut être parce que lorsque tu fabriques la DTD quivabien(c)
Je veux bien le pourcentage d'utilisateurs du XML qui font le DTD quivabien, stp?
1%? 2%? 5%? Je ne monterai pas au-delà.
D'ailleurs si ce format était aussi merdique, on se demande comment il à pu envahir tout le web avec le html.
En même temps, je n'ai jamais dit qu'il est inutile.
Ce qui me fait le haïr, c'est à force de le voir partout, pour tout et n'importe quoi, fichiers de configuration y compris. Et qu'on me ressasse que c'est la perfection à longueur de temps à, comme souvent avec moi, eu l'effet inverse, qui fait que dorénavant, je commence toujours par chercher une solution autre qu'XML, et si aucune ne conviens, ce qui n'est pas commun, alors je retombe sur XML.
Au moins, moi, je suis conscient d'être un hater, je sais pourquoi, et je l'assume, contrairement aux fanboys de ce truc.
Je ne comprends pas grand chose à ton test. Des stats que tu montre il est le plus rapide des 3 pour aller voir ce qui se passe sur perdu.com
Oui, quand je n'avais fait que ce test, je pensais aussi que c'était lui le mieux.
mais sur tout ton test est presque plus proche d'un benchmark de webkit qu'autre chose
Non, puisqu'ils dépendent tous de la même version de webkit. Et puis, midori est bien plus rapide que n'importe lequel d'entre eux.
Je crois que la différence réside dans le fait que le téléchargement des données soit plus long. En fait, j'avoue ne pas savoir le pourquoi du comment: je n'ai pas profilé les binaires, mais en même temps, je ne meurs pas d'envie de comprendre pourquoi l'un est plus lent que l'autre. Ce qui m'intéresse, c'est que l'un est le plus rapide. Point barre.
Si j'ai déjà besoin de plus de 10 secondes pour afficher un truc aussi con que perdu.com (au passage désolé pour le formatage, j'ai toujours du mal a penser que linuxfr interprète ce qui est renvoyé par ma console. Je corrigerai bien, mais malheureusement c'est trop tard :/ ), il y a un sacré souci.
C'est effectivement proche d'un benchmark, à ceci près que je ne suis pas un robot et ait un temps de latence ;) mais pas de webkit: des couches logicielles qui l'exploitent, plutôt.
Tu parle de ce que tu a l'habitude de faire, mais je doute que tu surf en lançant un navigateur pour acchicher une url pour le fermer derrière (je ne dis pas que ça n'arrive pas juste que ça ne correspond pas à ce que l'on appel du surf (pas de suivi de lien, d'historique, de gestion des favoris, de téléchargement, etc).
En effet, ce petit test simple ne représente pas l'entièreté de mon usage internet. Cependant, si des outils ne sont même pas capables d'afficher perdu.com en moins de 5s, ils sont difficilement considérables comme exploitables sur le net. Il reste donc l'affichage de documentation locale, que je fais effectivement généralement en saisissant l'url complète sur la ligne de commande.
Pour les liens local c'est un problème connu, il y a un patch pour ça (c'est des navigateurs de barbus faut se plonger dans le code/la configuration), sinon ça marche quand tu lui donne une url (file://).
Après un nouvel essai avec le préfixe, j'ai:
$ time surf file:///usr/share/doc/libsdl1.2-dev/docs.html
(surf:8325): libsoup-WARNING **: No feature manager for feature of type 'SoupCookie'
real 0m0.466s
user 0m0.208s
sys 0m0.080s
C'est donc 2 fois plus rapide que luakit, mais bon… devoir taper file:// à chaque fois, c'est gênant.
Pour le suivi des liens, en local, je ne vois aucune différence. A l'usage pour une recherche google, avec des installations par défaut dans une Debian, qui fournit en général des configurations par défaut utilisables, on se tape largement plus de 15s après le clic que le bouton de recherche. J'aurai volontiers accusé JS, mais seul luakit semble l'activer par défaut. Et il est nettement plus rapide a chercher un truc.
Tu m'étonnes que c'est des trucs de barbu: le temps qu'ils affichent la moindre page, tu as une barbe de 3 jours qui a le temps pousser.
Ah, un nouveau détail fun: avec surf, encore et toujours, aller sur www.duckduckgo.com affiche le code de la page. Pas la page, non, juste le code. Youpi. Sur ce site, uzbl n'affiche que la moitié des choses, et encore une fois luakit gagne haut la main en affichant correctement les choses. Il prend son temps, mais il marche.
Je ne parlerai pas du fait que surf ne respecte pas la gestion des fenêtres: il affiche la barre d'URL sur toute la largeur de l'écran, et non de sa fenêtre personnelle. Très mauvais point ça. Idem pour ses raccourcis (mais ça, ça dois être configurable) en CTRL+truc. Genre CTRL+g pour ouvrir une URL, c'est quand même tout sauf intuitif. uzbl et luakit ici sont plus malins, un simple "o" suffit. "o" comme ouvrir/open, ce qui est utilisé partout depuis que je connais l'informatique ( même sous dos, on avait alt+f pour le menu fichier, puis o pour ouvrir… ). J'imagine que le "g" sers pour go, mais bon…
Je veux bien être barbu, mais il y a des limites, sinon j'utiliserai directement wget et un script perl fait main en guise de navigateur.
Surf est, définitivement, le pire (quel âge à le patch? Si c'est plus d'un mois, il me semble difficilement admissible qu'il ne sois pas encore mergé…). Et je n'ai plus l'intention de me faire chier à trouver des excuses aux mauvais logiciels, catégorie à laquelle ils appartiennent tous les 3. J'ai perdu assez de temps. Être libre et ne faire qu'une seule chose mais bien, ne vaut rien si c'est trop long.
Non, si je veux prêcher pour un navigateur utilisable et léger, je reste pour le moment sur midori ou opera. Dillo, à la rigueur, bien qu'il ne supporte que le html pur et dur (pas d'images, ni de script, ni de style donc, on dirait. Mais au moins c'est rapide. Je crois que je vais l'adopter d'ailleurs, pour les doc techniques…).
On est convaincu par des arguments objectifs, qui font appel au raisonnement et à la logique. On est persuadé quand l'argument exploite notre affectif.
C'est le seul prof de français qui m'aie intéressé qui m'a appris cette distinction, en 2nd générale il y a une bonne décennie (le même qui m'a appris la théorie de l'argumentation: commencer par les arguments les plus faibles, ne jamais dire sa position précise dès le début mais à la conclusion, qu'un bon argument est formé d'une théorie appuyée d'un exemple, etc. Je me rappelle, mais je ne sais pas forcément appliquer tout ça :) )
Je la trouve très intéressante, notamment que je suis confronté aux médias actuels. Je me force à plus écouter mon côté objectif qu'affectif (et j'avoue ne pas avoir beaucoup d'efforts à faire), car je vois bien à quel point la persuasion est utilisée pour manipuler les gens.
D'où l'importance de la nuance.
Ce qu'en dit wikipedia (consulté après écriture du reste):
Les anciens qui ont défini l'éloquence, le talent de persuader, ont distingué persuader de convaincre, le premier de ces mots ajoutant à l'autre l'idée d'un sentiment actif excité dans l'âme de l'auditeur et joint à la conviction3.
Au sujet du build system, je te conseille plutôt CMake, ou n'importe quel outil autre que les GNU autotools archaïques.
Pour les front-end qui varient, c'est une excellente idée, mais c'est un peu comme pour les plug-in, ce n'est pas en en faisant qu'un que tu pourras avoir une interface ( logicielle ) définitive et fonctionnelle. Ce n'est pas que moi qui le dis, lorsque que je faisais des recherches à ce sujet, je suis tombé sur divers documents, dont un de google qui indiquait en gros que les interfaces de plug-in deviennent correctes à partir de 3 plug-in. Je gage que ce sera la même chose dans ton cas, bien qu'on puisse plutôt parler de plugout, puisque c'est le moteur (transmission-common) qui est le plugin d'une interface (transmission-gtk/cli/daemon/qt).
J'ai le même sentiment a propos des applications comme mpd, bien que le use case soit très différent.
Note préalable: je fais un sujet spécifiquement sur XML, parce que, voila, ça me gonfle de voir ce truc illisible utilisé pour tout et n'importe quoi.
Je peux savoir quelle est la raison d'utiliser XML pour l'exemple cité?
Ca n'a juste… aucun intérêt, si ne c'est de ne pas être maintenable facilement à la main. Je sais que certains sont de vrais fan de XML, mais voici à quoi ressemblerait le même contenu, pour un paquet Debian (qui est quelque chose de bien éprouvé pour ce type d'usage, donc. Et je reprend ici tout, alors que je n'aurai pas forcément utilisé les même clés. En plus, je n'ai pas mis de description courte, vu qu'elle n'existe pas dans le fichier XML…):
id: sonic-the-hedgehog
license:cc0
title:Sonic the Hedgehog
description:
In an attempt to steal the six Chaos Emeralds and harness their power,
Dr. Ivo Robotnik has trapped the animal inhabitants of South Island in
cybernetic shells and metal capsule prisons.
Control Sonic the Hedgehog to stop Robotnik's plans by freeing your
animal friends and collecting the Chaos Emeralds.
release_date: 27/06/1991
genres: platform
screenshots:http://info.sonicretro.org/images/6/6f/Sonic1_title.png
http://upload.wikimedia.org/wikipedia/en/d/d3/MD_Sonic_the_Hedgehog.png
covers:http://upload.wikimedia.org/wikipedia/en/b/ba/Sonic_the_Hedgehog_1_Genesis_box_art.jpg
developers:Sonic Team<http://www.sonicteam.com/>
modes:local<1,1>
controllers:gamepad<4>
Le public avertis de ce site éclairé aura constaté quelques adaptations libres autours de certains aspects, tels que les modes et les contrôleurs.
En réalité, pour Debian on aurait utilisé les debtags pour nombre de ces données, comme le genre. D'ailleurs… ceci devrait t'intéresser.
Je ne sais pas si ce n'est que moi, mais en tout cas ça me semble déjà bien plus lisible (*), à la fois pour l'homme, mais aussi pour un programme ( pas besoin de vérifier la cohérence des balises, notamment ).
Il aurait aussi été possible d'utiliser JSON, un peu moins pire qu'XML pour l'usage et avec pleins de lib pour l'intégrer directement dans du code, ou bien YAML (clairement plus propre que les langages à balise que sont XML et JSON…).
Tous ces choix auraient été, il me semble moins ridicules que XML. Oui, je suis un XML hater, et fier de l'être, parce que personne n'a jamais pu me dire en quoi XML est supérieur à tous les autres formats sur tous les usages.
*: au sujet de la lisibilité, je pense que ce qui l' handicape le plus, c'est le fait que j'ai retranscrit comme une brute les informations provenant d'un XML, sans réfléchir. Et puis, les URL n'aident pas. Je n'ai pas non plus aéré le texte, alors que j'aurai pu, avec notamment des retours à la ligne lorsque le contenu d'une catégorie prends plusieurs lignes.
Zut, j'ai mis les balises <troll inside> autour de la partie de phrase liée a python… sauf que j'ai pas pensé que linuxfr tenterai d'interpréter et donc ai oublié d'échapper le '<' …
bref: <boulet inside>freem</boulet inside>
Hum… en fait non, surf semble être la pire merde des 3…
Méthode de mesure: time avec fermeture du browser lorsque je vois le contenu s'afficher (sans vérifier qu'il s'affiche proprement, je précise, mais vu les exemples…). C'est expérimental parce que basé sur mes réflexes, certes, mais j'ai pas mieux sous la main.
$ time surf www.perdu.com
(surf:5074): libsoup-WARNING **: No feature manager for feature of type 'SoupCookie'
(surf:5074): libsoup-CRITICAL **: soup_message_queue_destroy: assertion `queue->head == NULL' failed
Donc ce que dit pulkomandy (1) est hors de propos?
1:
On n'a probablement pas besoin d'un modèle multi-utilisateur similaire à celui de UNIX, qui est prévu pour un grand nombre d'utilisateurs sur une même machine. Le but de Haiku étant plutôt d'avoir un seul utilisateur pour le moment, ou peut-être quelques uns. On peut regarder par exemple ce qui est fait dans Android.
Ce lien contiens un exemple déjà vachement plus pertinent et convainquant que ghoti:
Here and there, the weather on the sea allowed two of their friends to hear and see, too.
Hear and their, the whether on the see aloud too of there friends two here and sea, two.
Par contre, je ne suis pas anglophone, mais il me semble que "aloud/allowed", "too/two", "hear/here" ont des prononciations différentes, non? (question réelle. Je suis peut-être buté, mais j'aime connaître les arguments même contre mon avis, ça permets éventuellement d'avoir une excuse quand je me contredis, voire même de changer d'opinion ;) )
En tout cas c'est marrant, mais ce lien est extrêmement convainquant (et pas persuasif) quant au fait que l'anglais est plus complexe que le français… je ne l'aurai pas imaginé. Marrant aussi, car selon ce texte, le français est la langue la plus simple à prononcer contre l'anglais, le russe, l'allemand. Instructif.
Bon, parce qu'il me faut bien une petite critique négative, sinon c'est pas drôle (rire hygiénique, intellectualité frivole, etc):
Le dernier argument "7. L'anglais est parlé partout dans le monde." ne fait que montrer quel pourcentage de la population mondiale le parle, c'est à dire 10%. Pas 10% des pays mondiaux, non, 10% des humains terriens. Et il y a une note qui est très comique à la fin: "[Note: L'espéranto est parlé dans 170 pays du monde.]".
Cela voudrait-il dire que l'espéranto est parlé par plus de 10% de la population mondiale? XD
Ce dernier argument pêche par la mauvaise foi tout de même. Dans combien de pays l'anglais est-il parlé? Ceci n'est abordé nulle part.
Anéfé, je me suis laissé convaincre par ce texte.
Il part très mal. J'ai lu l'accroche, le 1er chapitre, et je trouve l'auteur pédant, insultant, et se prenant pour une élite maltraitée. Il se compare aux hérétiques qui ont prétendus que la terre était ronde lorsque le clergé la disait plate et qu'on à brûlés pour ça… Manque de mesure.
J'ai lu des textes d'anarchistes bien plus respectueux de ceux qui ne partagent pas leurs idées.
Mais je lirai le reste, plus tard, quand j'y penserai. Peut-être. Il faudra aussi que je relise mythale, un jour. Il a dedans des tonnes d'idées diverses et variées, mais je ne l'ai jamais lu en gardant à l'esprit le problème de langue commune qui y est pourtant abordé (l'interlingue citée plus haut m'a rappelé certains passages). Encore des choses sur ma todo list en somme.
En effet, ce truc n'est rien d'autre qu'une bonne idée qui à fini en immondice. En même temps, à vouloir passer par du python pour tout sauf le rendu, ça n'a rien de surprenant.
Je pense que je jetterai un plus gros oeil à surf qu'a luakit par contre. Je préfère restreindre au maximum les logiciels non compilés sur mon système, pour diverses raisons n'ayant rien à voir avec ce sujet :) (allez, au moins une: j'ai nettement plus confiance dans les compilateurs pour détecter les erreurs que dans les programmeurs attentifs doublés d'un interpréteur de commande)
La multiplicité des raccourcis claviers est la raison qui fait que j'aime l'idée des applications modales. (Ne pas lire modale en tant que multi-thread, comme utilisé dans les toolkit GUI, mais au sens d'utilisation de modes, comme dans vi.)
On n'a probablement pas besoin d'un modèle multi-utilisateur similaire à celui de UNIX, qui est prévu pour un grand nombre d'utilisateurs sur une même machine. Le but de Haiku étant plutôt d'avoir un seul utilisateur pour le moment, ou peut-être quelques uns. On peut regarder par exemple ce qui est fait dans Android.
La seule différence que je vois entre 2 et un nombre tendant vers l'infini, en terme de programmation, c'est que dans le cas ou l'on a que 2, on à un magic number et une allocation statique (ok, je simplifie, j'avoue).
Si on veut un système mono-utilisateur, windows nous a enseigné qu'on va avoir des tonnes d'emmerdes de sécurité (mais à l'époque ou windows s'est répandu c'était moins pire car internet était nettement moins répandu dans les chaumières). Microsoft ont depuis corrigé le tir, progressivement ( abandon de la base DOS, puis renforcement du rôle de l'utilisateur admin, ce qui a été très peu apprécié par les utilisateurs de vista ), et je trouve dommage qu'un OS veuille revenir en arrière.
De plus, je doute également qu'il soit aisé de corriger un design avec un tel manque dans des versions futures.
Tu cites android, mais android utilise le noyau linux. Je n'ai jamais eu le déplaisir de l'utiliser (je ne trouve aucun plaisir a utiliser un smartphone, bien au contraire) donc je peux me planter, mais je serai surpris qu'on ne puisse pas, au travers de hack, ajouter un utilisateur. Peut-être que les applications sont installées en userspace de l'utilisateur en cours en fait? Vu qu'il n'y a "qu'un utilisateur" et qu'on enlève le contrôle de l'ajout des utilisateurs à celui-ci, impossible de voir la différence?
[^] # Re: Bien...bien...bien
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 6.
A mon avis, l'utilisateur final ne verras pas de grande différence entre wayland et Xorg. Voire même, il n'en verra pas du tout.
A ce que j'ai cru comprendre au fur et à mesure des releases de wayland, c'est qu'il sera plus maintenable, et plus léger car non dépendant du grand nombre de "sous-protocoles" nécessaires pour pouvoir oser se prétendre serveur Xorg. Il devrait également permettre une meilleure sécurité par le fait qu'il ne s'occupe que d'affichage, et pas de l'entrée contrairement à Xorg.
Mais au final, seuls les développeurs verront la différence: moins de coût de maintenance, plus de facilité pour créer des serveurs graphiques alternatifs, et potentiellement un système moins gourmand… sauf que si on allège de 20Kio en RAM la gestion de l'affichage, avec des bouzins comme Gnome ou KDE, personne ne verra la différence, au vu de la lourdeur de ces derniers.
Sauf si tu es le genre d'utilisateur à utiliser fréquemment les TTYs ou à lancer plusieurs serveurs graphiques, puisqu'il semble au vu de la dépêche, que ces switch seront plus efficaces? Personnellement, ça ne m'arrive pas tous les jours mais c'est une fonctionnalité utile, et la voir plus réactive me ferait grand plaisir :)
[^] # Re: Grosse fatigue
Posté par freem . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 5.
Tu as raison de râler… enfin, de troller.
Après tout, tu es libre de le faire, tout comme de contribuer au code. Et nous, on est libres de te demander ce que tu fais pour améliorer ce dont tu te plains: quel est ton dernier patch sur Xorg ou sur wayland/weston, stp?
[^] # Re: dépendance à un système d'init
Posté par freem . En réponse au journal Debian à l'heure du choix. Évalué à 1.
J'ai confiance en Debian pour ce genre de choses. Comme tu l'as souligné, quid de kFreeBSD? Après tout, cette version de la distro est bien moins obscure que le port Hurd, donc on peut supposer qu'elle à une certaine importance aux yeux des mainteneurs Debian.
[^] # Re: Simple
Posté par freem . En réponse au journal Debian à l'heure du choix. Évalué à 3.
En effet. Et peut-être qu'un jour on aura tout le système configurable à partir de l'installateur… le kernel, l'init, le serveur d'affichage, le bureau… ça serai génial ça.
A l'heure actuelle il n'y a que le bureau… pour certains autres outils le seul choix est de ne pas installer.
[^] # Re: dépendance à un système d'init
Posté par freem . En réponse au journal Debian à l'heure du choix. Évalué à 2.
Je suis assez ignare sur ce sujet, mais il me semble avoir lu par ci et par là qu'avant, c'était un fichier qui contenait une description statique des périphériques.
Du coup, dans le cas, par exemple, d'un téléphone où de toute machine sur laquelle on ne peut pas ajouter de nouveaux périphériques plug-and-play, udev me semble totalement inutile ( si rien ne change, gérer dynamiquement les choses est juste débile ).
Pour les non plug-and-play "actifs" ( j'entends par actif qui ne fasse pas qu'émettre ou recevoir un signal analogique, c'est à dire plus compliqué qu'un bête écouteur ou chargeur de batterie ), je ne sais pas du tout si udev fonctionne ( ça fait bien longtemps que je n'ai pas vu de périphériques non plug-and-play "actifs" ).
Le seul souci étant, au final, d'avoir la bonne table au bon moment, ce qui peut être pénible pour des PCs ( portable ou non ) sur lesquels on branche pour certains régulièrement des périphériques USB par exemple, qui me semble actifs.
Mais, comme j'ai dit, je suis totalement novice en la matière et j'ai probablement effectué de gros raccourcis disgracieux. Si c'est le cas, je suis preneur de toute remarque constructive ( autre que rtfm, parce que, basiquement, ce type de fm nécessite pour être bien compris une certaine connaissance de toute l'archi linux, chose qui n'est pas à ma portée actuelle. ).
[^] # Re: dépendance à un système d'init
Posté par freem . En réponse au journal Debian à l'heure du choix. Évalué à 4.
DBus est peut-être critique pour toi, mais pas pour tout le monde.
Il offre certainement un grand confort, notament de permettre de configurer son réseau via une zolie IHM sans devoir devenir root, mais, ça ne signifie pas que ce ne soit pas faisable.
Et, même si je conçois très bien que mon cas personnel n'est pas représentatif d'une quelconque majorité, je peux te dire que jusqu'a présent, mes machines sur lesquelles dbus est installé, mais pas démarré ( dépendance dure de quelques logiciels et flemme de faire un paquet bidon… ) il ne me manque aucune fonctionnalité.
Pour le réseau, par exemple, j'édite tout bêtement /etc/network/interfaces à la main ( et pour les desktop, ça veut dire le faire 1 fois par installation, puisqu'au final la plupart des gens à un dhcp sur le LAN… ) . Pour le gestionnaire de session… j'avoue, je n'en utilise pas, je me log avec login, et un script lance startx si je suis en tty1.
Largement suffisant pour mes besoins, en somme.
Pulseaudio? Je crois que j'ai 1 ou 2 paquets avec pulse dans le nom d'installés ( mpd, de mémoire ), mais ce qui est certain, c'est que je n'ai aucun daemon PA qui tourne.
Donc, non, dbus est loin d'être aussi critique que le kernel. Pas même aussi incontournable que Xorg. D'ailleurs, à l'heure actuelle, il n'y a bien que linux et Xorg, que je considère comme des outils vitaux. Tous les autres ont des alternatives plus que viables. Et Xorg sera remplacé par wayland, un de ces 4. A voir pour linux également, il faudrait que je teste debian kfreebsd.
[^] # Re: Une jolie serveuse qui m'apporte ma pression.
Posté par freem . En réponse au sondage Qu'attendez vous le plus d'un réseau dit « social » libre ?. Évalué à 5.
Joli étant totalement subjectif, moche l'est aussi.
De plus, après quelques bières, la frontière entre les 2 est quand même vachement moins nette, donc, une bonne serveuse, même moche, finit par être jolie, cqfd.
# Une jolie serveuse qui m'apporte ma pression.
Posté par freem . En réponse au sondage Qu'attendez vous le plus d'un réseau dit « social » libre ?. Évalué à -3.
Un bon réseau social, c'est un bar dans lequel il y a de bonnes bières servies par de bonnes serveuses.
Donc, un bon réseau social libre, c'est la même chose, sauf qu'il donne le code source de la bière. Ca vaut aussi pour celui de la serveuse, à ceci près que j'ai toujours des réserves de patchs sur moi, mais comme je ne veux pas contribuer à toutes les serveuses, il ne faut pas une licence GNU, je préfère pour cet usage particulier la WTFPL.
[^] # Re: cmake & multi-frontend
Posté par freem . En réponse au journal Projet Badnik, partie 2 : GameData et appel à contribution. Évalué à 2.
C'est généralement ce que je rétorque quand on me demande pourquoi je n'aime pas les autotools. J'ai dis cmake, mais ne te laisse pas faire, il y en a pleins d'autres. CMake est juste celui que j'ai testé en 1er après les autotools, parce que plus de gens font plus de bruit à son sujet.
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à -1.
En effet, je n'étais pas sur que c'était dmenu ou pas.
Je ne connais pas la raison des résultats, je ne connais que les résultats. Debian stable à 95%, amd64.
#aptitude install surf
(enfin, non, en fait j'utilise l'interface ncurses d'aptitude, mais ça reviens strictement au même). 0 changement de configuration.
Ca me paraît aussi très étrange, vu que je connais la taille de cette page, moi aussi. Mais par téléchargement, j'entendais également les étapes du genre résolution de nom DNS et tout le reste. Qui sont une partie du téléchargement, tel que je l'entendais. Ce n'était peut-être pas super explicite, je te l'accorde. Mais encore une fois, comme je l'ai dis, je n'ai pas passé valgrind dessus, je ne sais pas quelle étape rends tout cela si long.
La seule chose que je constate, c'est la lenteur impressionnante de cette opération (l'affichage est immédiat, donc ce n'est pas le moteur de rendu) avec chaque navigateur minimaliste basé sur webkit que j'ai testé (dillo n'as pas ce souci, mais n'est pas basé sur webkit). Cela n'inclue pas juste les 3-4 en question.
Ca ne peut être la faute de webkit, puisque chromium lui possède la vitesse habituelle. Que cela te froisse, je m'en fiche autant que le fait que les développeurs de ces outils se fichent que ceux-ci ne me conviennent pas.
Bah… je ne prends pas 2H par logiciel que j'aie envie de tester, je l'admets bien volontiers. Sinon, il me faudrait 2 ans avant d'avoir un système exploitable…
En général, je lis les descriptions (ainsi que les debtags & dépendances, c'est souvent instructif) que me fournit mon gestionnaire de paquet (je n'utilise pas LFS justement parce que je n'ai pas envie de faire tout le boulot moi-même), et si il y a un souci que je constate sur un outil que j'estime utilisable et le meilleur de ceux que je teste (généralement j'en teste plusieurs en même temps, pour me faire une première opinion avant de me plonger dans les configurations et autres doc), je vais jeter un oeil sur la page officielle du site.
Celle dédiée a surf est très clean, mais aussi très exempte d'informations. Y compris au sujet du patch que tu cites (ou alors il n'a pas un nom évocateur, je ne sais pas).
Donc, oui je me renseigne un peu avant. Mais non, je n'y passe pas 2H et je ne le ferais pas, sauf si c'est vraiment nécessaire. Dans le cas des navigateurs web, c'est loin, très loin, de l'être.
Toi seul appelle cela un bench. Pour ma part, je n'aurais jamais l'outrecuidance de qualifier de benchmark des tests aussi peu poussés et soumis à l'erreur humaine. Sans parler du fait que la quantité de situations testée est ridiculement réduite. Mais permets malgré tout de s'apercevoir qu'il y a un souci.
En plus, je n'ai effectué aucun clic dans cette opération.
Je relis. Avant de pré-visualiser. Quand j'ai un doute sur ce que j'ai utilisé, c'est à dire quand j'utilise des choses comme le format pour le code source, je pré-visualise réellement. Si je ne fais que taper et copier/coller du texte, non.
Il semble d'ailleurs qu'une de mes erreurs soit liée au # qui transforme toute la ligne en titre, alors que l'aide mémoire indique qu'un titre doit être encadré par ce caractère. Comme j'ai l'habitude d'indiquer si j'exécute une commande en tant que root ou user, je mets les $ et # correspondant habituellement à cette distinction.
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par freem . En réponse au journal Projet Badnik, partie 2 : GameData et appel à contribution. Évalué à 1. Dernière modification le 11 novembre 2013 à 18:12.
Tu n'as qu'a copier/coller 100 fois ton texte dans le même fichier, et me dire que tu trouves ça lisible… en toute bonne foi, bien sûr.
Enfin, au niveau des formats que j'ai cités: JSON en est capable, celui de debian aussi ( même que c'est ce qui est fait dans "/var/lib/apt/lists/*". Je ne le savais pas, mais ta question m'a poussé à regardé comment c'était foutu…), et je ne doute pas que YAML le puisse aussi, je connais moins ce format (je me le garde juste en mémoire pour le jour ou j'en aurai peut-être besoin. Ceci dit, wikipedia montre très bien ce qu'on peut en faire).
Ce que tu dis me fais penser à l'héritage, en POO. C'est le truc que l'on apprend a arrêter d'utiliser à tout bout de champ (comme ce que je prône pour XML en fin de compte) au bout d'un moment, parce que ça pose plus de souci que ça n'en résout.
Debian résout ce problème de façon très simple: les debtags.
Un extrait d'un fichier de /var/lib/apt/lists fera un bon exemple, je pense:
Je ne sais pas pour toi, mais je trouve ça plutôt lisible. Peux-tu faire la même chose, en aussi lisible, avec un format plus riche?
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par freem . En réponse au journal Projet Badnik, partie 2 : GameData et appel à contribution. Évalué à 5.
Exactement. Et c'est pour ça qu'il ne doit pas être utilisé quand tu n'as besoin que d'un tel dictionnaire.
[^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par freem . En réponse au journal Projet Badnik, partie 2 : GameData et appel à contribution. Évalué à 1.
Je veux bien le pourcentage d'utilisateurs du XML qui font le DTD quivabien, stp?
1%? 2%? 5%? Je ne monterai pas au-delà.
En même temps, je n'ai jamais dit qu'il est inutile.
Ce qui me fait le haïr, c'est à force de le voir partout, pour tout et n'importe quoi, fichiers de configuration y compris. Et qu'on me ressasse que c'est la perfection à longueur de temps à, comme souvent avec moi, eu l'effet inverse, qui fait que dorénavant, je commence toujours par chercher une solution autre qu'XML, et si aucune ne conviens, ce qui n'est pas commun, alors je retombe sur XML.
Au moins, moi, je suis conscient d'être un hater, je sais pourquoi, et je l'assume, contrairement aux fanboys de ce truc.
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à 0.
Oui, quand je n'avais fait que ce test, je pensais aussi que c'était lui le mieux.
Non, puisqu'ils dépendent tous de la même version de webkit. Et puis, midori est bien plus rapide que n'importe lequel d'entre eux.
Je crois que la différence réside dans le fait que le téléchargement des données soit plus long. En fait, j'avoue ne pas savoir le pourquoi du comment: je n'ai pas profilé les binaires, mais en même temps, je ne meurs pas d'envie de comprendre pourquoi l'un est plus lent que l'autre. Ce qui m'intéresse, c'est que l'un est le plus rapide. Point barre.
Si j'ai déjà besoin de plus de 10 secondes pour afficher un truc aussi con que perdu.com (au passage désolé pour le formatage, j'ai toujours du mal a penser que linuxfr interprète ce qui est renvoyé par ma console. Je corrigerai bien, mais malheureusement c'est trop tard :/ ), il y a un sacré souci.
C'est effectivement proche d'un benchmark, à ceci près que je ne suis pas un robot et ait un temps de latence ;) mais pas de webkit: des couches logicielles qui l'exploitent, plutôt.
En effet, ce petit test simple ne représente pas l'entièreté de mon usage internet. Cependant, si des outils ne sont même pas capables d'afficher perdu.com en moins de 5s, ils sont difficilement considérables comme exploitables sur le net. Il reste donc l'affichage de documentation locale, que je fais effectivement généralement en saisissant l'url complète sur la ligne de commande.
Après un nouvel essai avec le préfixe, j'ai:
C'est donc 2 fois plus rapide que luakit, mais bon… devoir taper file:// à chaque fois, c'est gênant.
Pour le suivi des liens, en local, je ne vois aucune différence. A l'usage pour une recherche google, avec des installations par défaut dans une Debian, qui fournit en général des configurations par défaut utilisables, on se tape largement plus de 15s après le clic que le bouton de recherche. J'aurai volontiers accusé JS, mais seul luakit semble l'activer par défaut. Et il est nettement plus rapide a chercher un truc.
Tu m'étonnes que c'est des trucs de barbu: le temps qu'ils affichent la moindre page, tu as une barbe de 3 jours qui a le temps pousser.
Ah, un nouveau détail fun: avec surf, encore et toujours, aller sur www.duckduckgo.com affiche le code de la page. Pas la page, non, juste le code. Youpi. Sur ce site, uzbl n'affiche que la moitié des choses, et encore une fois luakit gagne haut la main en affichant correctement les choses. Il prend son temps, mais il marche.
Je ne parlerai pas du fait que surf ne respecte pas la gestion des fenêtres: il affiche la barre d'URL sur toute la largeur de l'écran, et non de sa fenêtre personnelle. Très mauvais point ça. Idem pour ses raccourcis (mais ça, ça dois être configurable) en CTRL+truc. Genre CTRL+g pour ouvrir une URL, c'est quand même tout sauf intuitif. uzbl et luakit ici sont plus malins, un simple "o" suffit. "o" comme ouvrir/open, ce qui est utilisé partout depuis que je connais l'informatique ( même sous dos, on avait alt+f pour le menu fichier, puis o pour ouvrir… ). J'imagine que le "g" sers pour go, mais bon…
Je veux bien être barbu, mais il y a des limites, sinon j'utiliserai directement wget et un script perl fait main en guise de navigateur.
Surf est, définitivement, le pire (quel âge à le patch? Si c'est plus d'un mois, il me semble difficilement admissible qu'il ne sois pas encore mergé…). Et je n'ai plus l'intention de me faire chier à trouver des excuses aux mauvais logiciels, catégorie à laquelle ils appartiennent tous les 3. J'ai perdu assez de temps. Être libre et ne faire qu'une seule chose mais bien, ne vaut rien si c'est trop long.
Non, si je veux prêcher pour un navigateur utilisable et léger, je reste pour le moment sur midori ou opera. Dillo, à la rigueur, bien qu'il ne supporte que le html pur et dur (pas d'images, ni de script, ni de style donc, on dirait. Mais au moins c'est rapide. Je crois que je vais l'adopter d'ailleurs, pour les doc techniques…).
[^] # Re: Prix de la carpette anglaise
Posté par freem . En réponse à la dépêche fOSSa 2013 : une conférence sur les écosystèmes rien que pour vous ! . Évalué à 1.
On est convaincu par des arguments objectifs, qui font appel au raisonnement et à la logique. On est persuadé quand l'argument exploite notre affectif.
C'est le seul prof de français qui m'aie intéressé qui m'a appris cette distinction, en 2nd générale il y a une bonne décennie (le même qui m'a appris la théorie de l'argumentation: commencer par les arguments les plus faibles, ne jamais dire sa position précise dès le début mais à la conclusion, qu'un bon argument est formé d'une théorie appuyée d'un exemple, etc. Je me rappelle, mais je ne sais pas forcément appliquer tout ça :) )
Je la trouve très intéressante, notamment que je suis confronté aux médias actuels. Je me force à plus écouter mon côté objectif qu'affectif (et j'avoue ne pas avoir beaucoup d'efforts à faire), car je vois bien à quel point la persuasion est utilisée pour manipuler les gens.
D'où l'importance de la nuance.
Ce qu'en dit wikipedia (consulté après écriture du reste):
# cmake & multi-frontend
Posté par freem . En réponse au journal Projet Badnik, partie 2 : GameData et appel à contribution. Évalué à 1.
Au sujet du build system, je te conseille plutôt CMake, ou n'importe quel outil autre que les GNU autotools archaïques.
Pour les front-end qui varient, c'est une excellente idée, mais c'est un peu comme pour les plug-in, ce n'est pas en en faisant qu'un que tu pourras avoir une interface ( logicielle ) définitive et fonctionnelle. Ce n'est pas que moi qui le dis, lorsque que je faisais des recherches à ce sujet, je suis tombé sur divers documents, dont un de google qui indiquait en gros que les interfaces de plug-in deviennent correctes à partir de 3 plug-in. Je gage que ce sera la même chose dans ton cas, bien qu'on puisse plutôt parler de plugout, puisque c'est le moteur (transmission-common) qui est le plugin d'une interface (transmission-gtk/cli/daemon/qt).
J'ai le même sentiment a propos des applications comme mpd, bien que le use case soit très différent.
# XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.
Posté par freem . En réponse au journal Projet Badnik, partie 2 : GameData et appel à contribution. Évalué à 6.
Note préalable: je fais un sujet spécifiquement sur XML, parce que, voila, ça me gonfle de voir ce truc illisible utilisé pour tout et n'importe quoi.
Je peux savoir quelle est la raison d'utiliser XML pour l'exemple cité?
Ca n'a juste… aucun intérêt, si ne c'est de ne pas être maintenable facilement à la main. Je sais que certains sont de vrais fan de XML, mais voici à quoi ressemblerait le même contenu, pour un paquet Debian (qui est quelque chose de bien éprouvé pour ce type d'usage, donc. Et je reprend ici tout, alors que je n'aurai pas forcément utilisé les même clés. En plus, je n'ai pas mis de description courte, vu qu'elle n'existe pas dans le fichier XML…):
Le public avertis de ce site éclairé aura constaté quelques adaptations libres autours de certains aspects, tels que les modes et les contrôleurs.
En réalité, pour Debian on aurait utilisé les debtags pour nombre de ces données, comme le genre. D'ailleurs… ceci devrait t'intéresser.
Je ne sais pas si ce n'est que moi, mais en tout cas ça me semble déjà bien plus lisible (*), à la fois pour l'homme, mais aussi pour un programme ( pas besoin de vérifier la cohérence des balises, notamment ).
Il aurait aussi été possible d'utiliser JSON, un peu moins pire qu'XML pour l'usage et avec pleins de lib pour l'intégrer directement dans du code, ou bien YAML (clairement plus propre que les langages à balise que sont XML et JSON…).
Tous ces choix auraient été, il me semble moins ridicules que XML. Oui, je suis un XML hater, et fier de l'être, parce que personne n'a jamais pu me dire en quoi XML est supérieur à tous les autres formats sur tous les usages.
*: au sujet de la lisibilité, je pense que ce qui l' handicape le plus, c'est le fait que j'ai retranscrit comme une brute les informations provenant d'un XML, sans réfléchir. Et puis, les URL n'aident pas. Je n'ai pas non plus aéré le texte, alors que j'aurai pu, avec notamment des retours à la ligne lorsque le contenu d'une catégorie prends plusieurs lignes.
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à 1.
Zut, j'ai mis les balises <troll inside> autour de la partie de phrase liée a python… sauf que j'ai pas pensé que linuxfr tenterai d'interpréter et donc ai oublié d'échapper le '<' …
bref: <boulet inside>freem</boulet inside>
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à 1.
Hum… en fait non, surf semble être la pire merde des 3…
Méthode de mesure: time avec fermeture du browser lorsque je vois le contenu s'afficher (sans vérifier qu'il s'affiche proprement, je précise, mais vu les exemples…). C'est expérimental parce que basé sur mes réflexes, certes, mais j'ai pas mieux sous la main.
$ time surf www.perdu.com
(surf:5074): libsoup-WARNING **: No feature manager for feature of type 'SoupCookie'
(surf:5074): libsoup-CRITICAL **: soup_message_queue_destroy: assertion `queue->head == NULL' failed
real 0m11.426s
user 0m0.200s
sys 0m0.084s
$ time uzbl www.perdu.com
(uzbl-core:5819): libsoup-CRITICAL **: soup_message_queue_destroy: assertion `queue->head == NULL' failed
real 0m12.462s
user 0m0.684s
sys 0m0.148s
$ time luakit www.perdu.com
(luakit:6613): libsoup-CRITICAL **: soup_message_queue_destroy: assertion `queue->head == NULL' failed
real 0m11.846s
user 0m0.532s
sys 0m0.104s
Et tant qu'a faire, j'ai fait le même type de mesure avec un fichier local:
$ time uzbl /usr/share/doc/libsdl1.2-dev/docs.html
real 0m1.640s
user 0m0.604s
sys 0m0.128s
$ time luakit /usr/share/doc/libsdl1.2-dev/docs.html
real 0m0.968s
user 0m0.528s
sys 0m0.072s
$ time surf /usr/share/doc/libsdl1.2-dev/docs.html
(surf:6717): libsoup-WARNING **: No feature manager for feature of type 'SoupCookie'
(surf:6717): libsoup-CRITICAL **: soup_message_set_first_party: assertion
first_party != NULL' failedfirst_party != NULL' failed(surf:6717): libsoup-CRITICAL **: soup_message_set_first_party: assertion
(surf:6717): libsoup-CRITICAL **: soup_message_queue_destroy: assertion `queue->head == NULL' failed
real 0m22.505s
user 0m0.232s
sys 0m0.092s
A noter ici que surf n'a même pas réussi a afficher la page:
Unable to load page
Problem occurred while loading the URL http://usr/share/doc/libsdl1.2-dev/docs.html
Cannot resolve hostname (usr)
Dommage, mais surf est en fin de compte le pire des 3, luakit menant haut la main: 59% du temps d'exécution d'uzbl, la différence est énorme.
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à 1.
Donc ce que dit pulkomandy (1) est hors de propos?
1:
[^] # Re: Prix de la carpette anglaise
Posté par freem . En réponse à la dépêche fOSSa 2013 : une conférence sur les écosystèmes rien que pour vous ! . Évalué à 1.
Ce lien contiens un exemple déjà vachement plus pertinent et convainquant que ghoti:
Here and there, the weather on the sea allowed two of their friends to hear and see, too.
Hear and their, the whether on the see aloud too of there friends two here and sea, two.
Par contre, je ne suis pas anglophone, mais il me semble que "aloud/allowed", "too/two", "hear/here" ont des prononciations différentes, non? (question réelle. Je suis peut-être buté, mais j'aime connaître les arguments même contre mon avis, ça permets éventuellement d'avoir une excuse quand je me contredis, voire même de changer d'opinion ;) )
En tout cas c'est marrant, mais ce lien est extrêmement convainquant (et pas persuasif) quant au fait que l'anglais est plus complexe que le français… je ne l'aurai pas imaginé. Marrant aussi, car selon ce texte, le français est la langue la plus simple à prononcer contre l'anglais, le russe, l'allemand. Instructif.
Bon, parce qu'il me faut bien une petite critique négative, sinon c'est pas drôle (rire hygiénique, intellectualité frivole, etc):
Le dernier argument "7. L'anglais est parlé partout dans le monde." ne fait que montrer quel pourcentage de la population mondiale le parle, c'est à dire 10%. Pas 10% des pays mondiaux, non, 10% des humains terriens. Et il y a une note qui est très comique à la fin: "[Note: L'espéranto est parlé dans 170 pays du monde.]".
Cela voudrait-il dire que l'espéranto est parlé par plus de 10% de la population mondiale? XD
Ce dernier argument pêche par la mauvaise foi tout de même. Dans combien de pays l'anglais est-il parlé? Ceci n'est abordé nulle part.
Il part très mal. J'ai lu l'accroche, le 1er chapitre, et je trouve l'auteur pédant, insultant, et se prenant pour une élite maltraitée. Il se compare aux hérétiques qui ont prétendus que la terre était ronde lorsque le clergé la disait plate et qu'on à brûlés pour ça… Manque de mesure.
J'ai lu des textes d'anarchistes bien plus respectueux de ceux qui ne partagent pas leurs idées.
Mais je lirai le reste, plus tard, quand j'y penserai. Peut-être. Il faudra aussi que je relise mythale, un jour. Il a dedans des tonnes d'idées diverses et variées, mais je ne l'ai jamais lu en gardant à l'esprit le problème de langue commune qui y est pourtant abordé (l'interlingue citée plus haut m'a rappelé certains passages). Encore des choses sur ma todo list en somme.
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à 2.
Et?
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à 2.
En effet, ce truc n'est rien d'autre qu'une bonne idée qui à fini en immondice. En même temps, à vouloir passer par du python pour tout sauf le rendu, ça n'a rien de surprenant.
Je pense que je jetterai un plus gros oeil à surf qu'a luakit par contre. Je préfère restreindre au maximum les logiciels non compilés sur mon système, pour diverses raisons n'ayant rien à voir avec ce sujet :) (allez, au moins une: j'ai nettement plus confiance dans les compilateurs pour détecter les erreurs que dans les programmeurs attentifs doublés d'un interpréteur de commande)
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à 1.
La multiplicité des raccourcis claviers est la raison qui fait que j'aime l'idée des applications modales. (Ne pas lire modale en tant que multi-thread, comme utilisé dans les toolkit GUI, mais au sens d'utilisation de modes, comme dans vi.)
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à 0.
La seule différence que je vois entre 2 et un nombre tendant vers l'infini, en terme de programmation, c'est que dans le cas ou l'on a que 2, on à un magic number et une allocation statique (ok, je simplifie, j'avoue).
Si on veut un système mono-utilisateur, windows nous a enseigné qu'on va avoir des tonnes d'emmerdes de sécurité (mais à l'époque ou windows s'est répandu c'était moins pire car internet était nettement moins répandu dans les chaumières). Microsoft ont depuis corrigé le tir, progressivement ( abandon de la base DOS, puis renforcement du rôle de l'utilisateur admin, ce qui a été très peu apprécié par les utilisateurs de vista ), et je trouve dommage qu'un OS veuille revenir en arrière.
De plus, je doute également qu'il soit aisé de corriger un design avec un tel manque dans des versions futures.
Tu cites android, mais android utilise le noyau linux. Je n'ai jamais eu le déplaisir de l'utiliser (je ne trouve aucun plaisir a utiliser un smartphone, bien au contraire) donc je peux me planter, mais je serai surpris qu'on ne puisse pas, au travers de hack, ajouter un utilisateur. Peut-être que les applications sont installées en userspace de l'utilisateur en cours en fait? Vu qu'il n'y a "qu'un utilisateur" et qu'on enlève le contrôle de l'ajout des utilisateurs à celui-ci, impossible de voir la différence?