D'un point de vu utilisateur je trouve vraiment très très désagréable qu'un mainteneur décide que telle ou telle fonctionnalité, n'est plus ergonomique ou que sais-je, et qu'il ne faut plus que vous l'utilisiez.
Si c'est pas le boulot d'un mainteneur, c'est le boulot de qui ?
Tu as l'air de considérer "Nazi du typage" comme un défaut. Permets moi de te contredire. Dans la plupart des cas, un typage fort apporte beaucoup plus d'avantages que d'inconvénients.
Le premier avantage d'un bon système de type est la sûreté. Un système de type sûr rejette les programmes absurdes et sémantiquement invalides dont l'évaluation échouairait. Donc, même si on ne peut pas garrantir que le programme termine bien et qu'il fasse ce qu'on veut qu'il fasse (c'est le problème de l'arrêt, indécidable de toute manière), on peut au moins essayer de garratir que le code va s'éxécuter. Ce n'est clairement pas le cas de C, ni de python. En C, les programmes invalides qui segfault compilent souvent trés bien. Je ne dis pas qu'Ocaml ne segfault jamais, mais il faut aller s'amuser avec des fonctions un peu avancés et pousser le systéme de type dans ses retranchements pour y arriver.
Un autre avantage du typage statique fort, c'est qu'il permet de compiler un code plus efficace. En effet, si on ne connait pas le type des expressions pour une opération polymorphe, on est obligé de savoir traiter tout les cas, même si ce n'est pas forcément nécessaire. Exemple, l'expression + polymorphe qui sait prendre en compte plusieurs types. En Ocaml, les opérateurs ne sont pas polymorphes, ce qui évite d'avoir implictement des comportements auquel le développeur n'a pas pensé, comme ajouter un float et un int.
Le typage augmente aussi la lisibilité du code. Dans un bon code ocaml, en lisant le nom d'une fonction et sa signature, on a souvent une bonne idée de ce qu'elle fait.
Maintenant, les inconvénients. Souvent, les gens qui aiment le typage dynamique prennent comme argument qu'il est ennuyeux de déclarer le type des variables/fonctions en permanence. Ocaml n'a pas vraiment se problème, encore une fois grace à son système de type. Le compilateur utilise un algorithme d'inférence des types, qui permet, à partir d'une expression, d'en déduire sont type de manière déterministe. Dans la majorité des cas, (à moins d'utiliser des choses comme les foncteurs, ou les paramètres optionnels), on n'ajoute pas d'annotation de type. C'est le compilateur qui se charge de le faire pour nous, et qui, en prime, vérifie que le code est cohérent. Comme précisé dans la dépêche, Ocaml n'est pas plus verbeux que python.
Pour finir, je pense qu'il faut considérer le typage comme une énorme aide au développeur plutôt que comme une contrainte.
Posté par Enjolras .
En réponse à la dépêche OCaml 4.00.0 est sorti.
Évalué à -4.
Dernière modification le 11 août 2012 à 14:52.
Comme stratégie marketing, on a vu mieux quand même, essayer de pas faire peur aux gens et leur faire croire qu'ils vont se ramener à quelque chose de connu, alors qu'en fait, c'est pas le cas. Je pense qu'on peut se réjouir des efforts faits pour promouvoir Ocaml, comme Ocamlpro, mais de là à tomber dans la démagogie pure, je ne suis pas certain que ça soit une idée lumineuse.
Pour ceux qui ne connaissent pas, OCaml est un langage à mi-chemin entre C et Python, avec des performances proches de C avec la concision de Python.
Tu veux dire, à mis chemin entre un langage avec un systéme de type pourri et un langage avec un systéme de type pourri et incapable de faire correctement du fonctionnel ?
Je dois dire que le dépôt git allemand m'avait tellement enthousiasmé que je suis prêt à tenter l'aventure avec la loi française, avec peut être une interface web en prime. Mais je n'ai pas toutes les compétence nécessaire à un tel projet, notament en technologie web, je n'en ai aucune. Si des gens sont intéressés… L'union fait la force.
C'est un peu le troll sous entendu de mon journal oui. Tu me fais craindre de l'avoir trop sous-entendu :'(.
Cela dit, NULL, NaN, et undef ne sont pas des problèmes en soi. Ils découlent des choix généraux du langage.
NULL est une valeur dans quasiment tout langage qui se respecte.
NaN vient du fait que les nombres sont par défaut des doubles IEEE754, donc NaN est une valeur parfaitement normale, et ne pose pas tant de problème que ça, pas plus que le calcul flottant lui même. Les entiers n'existent pas en JavaScript, même s'ils existent dans les JIT parce que c'est souvent plus rapide.
Enfin, je ne pense pas que ce genre de chose soit un problème vraiment grave comparé au non déterminisme du typage. Indépendament de ça, je n'ai jamais écrit plus de 20 lignes de JavaScript moi même.
C'est vrai, j'avoue, j'ai pas relu, mea culpa. D'ailleurs, je voulais ajouter aussi quelques lien, mais j'ai écrit ça en one-shot, et après deux heures de travail, j'étais tellement content que j'ai pas pu m'empêcher de cliquer sur envoyer. :/
Pourquoi faut ils que ça parte toujours en troll, avec des rageux qui sont là pour défendre leur bureaux préférés ? J'ai comme l'impression que tu n'as pas lu ce que j'ai écrit.
Je me suis forcé à tester plusieurs fois KDE pendant 3semaines, et autant j'aime beaucoup le bureau, sa flexibilité, et les technologies qu'il y a derrière, autant j'ai vraiment du mal avec les applications.
J'ai beaucoup aimé la direction simplificatrice qu'a pris GNOME, mais maintenant ils vont trop loin.
Ce que je n'aime pas dans les applications KDE (et a fortiori dans les applications E d'ailleurs), c'est leur surcharge. Il y a des tones d'actions visibles par défaut qui ne sont utilisées que rarement. Pour moi, de base, il ne devrait y avoir que les actions que tu fais 80% du temps, le reste étant caché dans des endroits moins visible, mais simple à trouver. De plus, les menus/toolbar contextuels sont une bonne chose, et c'est une bonne idée que commence à avoir GNOME là, sauf que ça serait bien s'ils y en avait plus qui qui font plus de choses.
Ce que je n'aime pas non plus, c'est qu'il y a trés trés souvent 2/3 façon d'accomplir la même tâche, et aucune n'est mise en avant. Exemple, dans dolphin, on peut faire le copier coller d'au moins 3 manières, et toutes en 4 clics. 4 clics c'est beaucoup. De plus, l'interface ne te guide pas, c'est toi qui doit la guider. Et ça pour moi, c'est un gros défaut. D'aucun diront que je je suis un nazi de l'interface. Peut être. Mais à quoi sert une machine si elle ne nous aide pas ?
Pour résumer, je pense que l'approche d'UX qu'a choisis GNOME est fondamentalement bonne, mais qu'ils ont cru que pour la réaliser, il fallait tout supprimer, ce qui est à mon sens complétement faux. (enfin, la suppression de features a aussi lieu parce qu'ils essaient de faire énormément en peu de temps avec pas grand monde, et donc, ils font le minimum). J'aimerais que KDE prenne une approche similaire en conservant sa flexibilité.
Je ne suis pas très calé non plus, tout ce que je sais c'est que c'est ce que j'ai l'habitude de voir, maintenant, les typographes expérimentés peuvent penser que c'est un mauvais comportement. Je ne sais pas s'il y a vraiment un usage de référence de toute manière.
je ne suis pas un typographe extrémiste, je trouvais que c'était une typographie plus naturelle et plus lisible pour les longs journaux, mais ça peut être aussi chargé dans le cas de nombreux paragraphes.
Ce n'est peut être pas la peine de se prendre la tête la dessus pendant des heures, je ne sais pas vraiment ce qu'il convient de faire, donc tu n'as qu'à faire ce que tu veux :).
LaTeX avec babel paramétré en français ne respecterait-il pas la typographie française ?
La bibliothèque de la pléiade de Gallimard non plus ? J'aimerais bien savoir d'où vient cette règle de mettre des Alinéa alignés et non des alinéa rentrants après un saut de ligne…
Je connais bien FreeBSD ne t'en déplaise, enfin, surtout Dragonfly, mais je répondais surtout sur Arch, parce qu'en effet la majorité des arguments ne tiennent pas. Surtout pas le cgroups, parce qu'ils n'existent pas.
Enfin, il y a les jails, mais c'est pas tout à fait pareil, c'est plus l'équivalent de LXC.
Pas de problème, d'autes ont déjà répondu et j'avais déjà donné rc.subr avant que tu n'en parles.
j'ai déjà répondu aussi.
N'existent pas dans FreeBSD.
Grande nouvelle, il n'y en a juste moins que dans system V.
Le shell de FreeBSD est sh, pas bash.
Perdu aussi, du moins si tu considères que sh est bourne shell. /bin/sh est juste un shell compatible posix shell. Même s'il y a beaucoup moins d'extensions que bash, il y en a.
C'est pourtant ce dont tu parlais.
Bon, puisque tu veux à tout pris un exemple, je ne pense pas qu'il soit spécifié quand est réalisée l’expansion dans des expressions complexes comme if.
Là tu manques trop de clarté pour que je puisse essayer de te répondre. Si tu as des problèmes d'échappement, c'est juste que tu ne sais pas bien programmer en shell! (P.ex. tu utilises echo alors qu'il faudrait utiliser printf.)
Redéfinition des fonctions/variables sans que ça râle, possibilité de changer les options du shell, j'en passe, ça demande plus de précautions pour coder
Sinon la grammaire du bourne shell doit être équivalente, la grammaire de bash au moins 3 fois plus longue.
Je suis d'accord que la doc sous FreeBSD est pas mal, mais sous linux, c'est loin d'être le cas, et comme tu peux le remarquer, je ne parlais pas de freeBSD en particulier.
J'ai l'impression que & existe depuis la nuit des temps.
j'ai l'impression que tu n'as pas compris le problème, parce que & ne permet pas de faire simplement des choses de manière asynchrones. D'ailleurs, tu peux lire les scripts, tu verras qu'il n'est pas utilisé souvent.
Les cgroups cela se gère aussi facilement qu'un
manque de pôt, c'est peut être facile, mais ce n'est pas fait. D'ailleurs, ce n'est pas aussi simple que ce que tu veux le faire croire. Si par exemple tu décides de lancer ttout les daemons réseaux dans un cgroup particulier tu aimerais bien que l'init le gére pour toi.
De quels niveaux parles-tu ?
J'en connais pas beaucoup… Les niveaux traditionnels sont "single user, stop, multi-user,etc" mais ça suffit pas. Souvent tu aimerais bien avoir des niveaux comme "connecté à internet, connecté localement, synchronisation, maintenance, whatever you want to do"
J'aimerais bien avoir un init qui permet de gérer ça simplement sans avoir à bricoler mes scripts par dessus.
Généralement, je fais ça en ajoutant/supprimant des liens symboliques à l'aide d'un outil très simple ou via un fichier de config. très simple.
Encore une fois, c'est vrai pour FreeBSD dont l'init est très bien fait, parce qu'il fonctionne uniquement avec des scripts rc, mais pas pour tout les init BSD like. Tiens au passage, je me permet de faire remarquer que c'est exactement le fonctionnement de systemd.
Bien documenté, j'aimerais bien voir la doc… Bien commenté certes, mais c'est la moindre des choses. POurquoi c'est un hack ? Incapable de s'éxécuter de manière efficace sur un processeur moderne avec SMP. Incapable de gérer les processus de manière moderne sous linux (crgoups, et compagnie). MAnque de souplesse au niveau de la gestion des niveaux d'éxécution. Impossible de modifier le processus de boot (enlever/ajouter des opérations) sans modifier un script shell monolithique.
Sans aller jusqu'a un langage fonctionnel, il y a des langages simples avec une grammaire qui tient en 20 lignes : cf lua
Software bloat is a process whereby successive versions of a computer program include an increasing proportion of unnecessary features that are not used by end users
man bash
je doute qu'on ai réellement besoin d'utiliser ${!prefix@} dans un init.
Quel est ton exemple de programme shell dont la sémantique n'est pas définie?
sans aller vers une sémantique non définie, le shell demande des précautions infinies d'échapements et de gestion de l'environnement pour s'éxécuter dans un environnement confiné en lisant des paramètres en shell quelque part…
Cf. man rc.subr(8)
je ne parle pas de ce code là. Je parle des scripts de lancement de daemons dans rc.d (c'est pire sous archlinux que sous FreeBSD là)
Je n'ai pas parlé de systemd. Je parle de ce que certains semblent considérer comme le graal, les init BSD-like.
Quelle est la différence entre un installateur et un init ? Dans les deux cas il y a une interaction utilisateur, ça t'arrive jamais de lancer un daemon ou de vérifier le status d'un autre ? Ou même de vouloir gére tes crgoups ? Le fait qu'init tourne constament est justement un argument de robustesse, donc, ce qui s'applique pour un installateur, qui est exécuté une seule fois, devrait s'appliquer a fortiori à un init.
Que ça soit Archlinux ou FreeBSD, je trouve que le systéme de boot est un pur amas de hacks. Déjà, les scripts sont écrits dans un langage non typé, dont la grammaire fairait tomber en syncope un grammairien français (c'est dire !), et dont la sémantique est tout sauf simplement définie. Un truc qui fuit de partout en amassant des données n'importe ou là ou il ne devrait pas (environnement, tout ça). Bref, un truc écrit dans un langage bloat, pas safe, avec de la duplication de code (oui les scripts rc sont tous les mêmes), qui apporte quoi au final ?
Et on appelle ça KISS ?
Pour finir, une petite quote de l'installateur d'openBSD :
OpenBSD installation script.
In a perfect world, this would be a nice C program, with a reasonable
user interface.
Non, ça c'est juste que Evolution, c'est (c'était) developpé par des éxtrémistes conservateurs qui ne veulent surtout rien changer. Mais ça a l'air d'avoir changé.
Webkit est fourni sous la forme d'une api multiplateforme d'assez bas niveau, qui gère uniquement le rendu/le dom/JavaScript. Par dessus, il y a différents bindings, pour divers toolkits graphiques :
une api cocoa
webkitGTK, notamment utilisé par epiphany, le navigateur de GNOME, mais aussi par le visionneur de doc GNOME et apparemment bientôt par Évolution
Qtwebkit, utilisé par rekonq notamment
La sauce google utilisé dans chrome.
Dans la version dite "1" de l'API webkit de base, il n'y a qu'un seul processus qui gère le rendu. Par dessus, on peut implémenter le processus qui gère l'UI, c'est ce que simplifient les différentes API pour les divers toolkit. Google a décider avec chrome de séparer cette UI dans un autre processus, mais ce n'est pas géré par webkit, c'est leur propre sauce, ce n'est pas trivial à implémenter avec n'importe quelle API webkit.
Cela dit, il y a une nouvelle version de l'API de base, webkit2, sortie en 2010. Cette version inclue directement dans l'API webkit de base un modèle similaire à chrome, séparent le contenu de l'UI dans des processus séparés, et pouvant placer divers contenus dans divers processus.
WebkitGTK a un support en court de stabilisation de webkit2 et gnome a annoncé vouloir sortir une version beta d'épiphany avec webkit2 pour GNOME 3.6. J'imagine que ça va arriver aussi sous KDE/rekonq.
Donc, pour résumer, même si tu ne parlais que des plugins et non de tout les contenus, non, ce n'est pas trivial à faire à moins de porter le navigateur vers la nouvelle API. Sinon il faut bricoler soit même.
Ça fait longtemps que c'est en discussion, mais ça ne s'est toujours pas concrétisé. Si tu veux vraiment que ça arrive, vas mettre ton grain de sel sur le bug.
[^] # Ne pas sous estimer les libristes
Posté par Enjolras . En réponse au journal Conseils aux libristes, 1ere partie: eviter de sous-estimer la competition sur le plan technique. Évalué à 1.
et leur capacité à ne juger beaucoup de choses que sur la forme.
[^] # Re: Humeur d'utilisateur.
Posté par Enjolras . En réponse à la dépêche Xfce, Gnome, Ubuntu, Linux et Debian sont dans le Nautilus.... Évalué à 3.
Si c'est pas le boulot d'un mainteneur, c'est le boulot de qui ?
[^] # Re: A mi chemin ?
Posté par Enjolras . En réponse à la dépêche OCaml 4.00.0 est sorti. Évalué à 7.
Tu as l'air de considérer "Nazi du typage" comme un défaut. Permets moi de te contredire. Dans la plupart des cas, un typage fort apporte beaucoup plus d'avantages que d'inconvénients.
Le premier avantage d'un bon système de type est la sûreté. Un système de type sûr rejette les programmes absurdes et sémantiquement invalides dont l'évaluation échouairait. Donc, même si on ne peut pas garrantir que le programme termine bien et qu'il fasse ce qu'on veut qu'il fasse (c'est le problème de l'arrêt, indécidable de toute manière), on peut au moins essayer de garratir que le code va s'éxécuter. Ce n'est clairement pas le cas de C, ni de python. En C, les programmes invalides qui segfault compilent souvent trés bien. Je ne dis pas qu'Ocaml ne segfault jamais, mais il faut aller s'amuser avec des fonctions un peu avancés et pousser le systéme de type dans ses retranchements pour y arriver.
Un autre avantage du typage statique fort, c'est qu'il permet de compiler un code plus efficace. En effet, si on ne connait pas le type des expressions pour une opération polymorphe, on est obligé de savoir traiter tout les cas, même si ce n'est pas forcément nécessaire. Exemple, l'expression + polymorphe qui sait prendre en compte plusieurs types. En Ocaml, les opérateurs ne sont pas polymorphes, ce qui évite d'avoir implictement des comportements auquel le développeur n'a pas pensé, comme ajouter un float et un int.
Le typage augmente aussi la lisibilité du code. Dans un bon code ocaml, en lisant le nom d'une fonction et sa signature, on a souvent une bonne idée de ce qu'elle fait.
Maintenant, les inconvénients. Souvent, les gens qui aiment le typage dynamique prennent comme argument qu'il est ennuyeux de déclarer le type des variables/fonctions en permanence. Ocaml n'a pas vraiment se problème, encore une fois grace à son système de type. Le compilateur utilise un algorithme d'inférence des types, qui permet, à partir d'une expression, d'en déduire sont type de manière déterministe. Dans la majorité des cas, (à moins d'utiliser des choses comme les foncteurs, ou les paramètres optionnels), on n'ajoute pas d'annotation de type. C'est le compilateur qui se charge de le faire pour nous, et qui, en prime, vérifie que le code est cohérent. Comme précisé dans la dépêche, Ocaml n'est pas plus verbeux que python.
Pour finir, je pense qu'il faut considérer le typage comme une énorme aide au développeur plutôt que comme une contrainte.
[^] # Re: C'est triste ton avis sur Ocaml
Posté par Enjolras . En réponse à la dépêche OCaml 4.00.0 est sorti. Évalué à -4. Dernière modification le 11 août 2012 à 14:52.
Comme stratégie marketing, on a vu mieux quand même, essayer de pas faire peur aux gens et leur faire croire qu'ils vont se ramener à quelque chose de connu, alors qu'en fait, c'est pas le cas. Je pense qu'on peut se réjouir des efforts faits pour promouvoir Ocaml, comme Ocamlpro, mais de là à tomber dans la démagogie pure, je ne suis pas certain que ça soit une idée lumineuse.
# C'est triste ton avis sur Ocaml
Posté par Enjolras . En réponse à la dépêche OCaml 4.00.0 est sorti. Évalué à -9.
Tu veux dire, à mis chemin entre un langage avec un systéme de type pourri et un langage avec un systéme de type pourri et incapable de faire correctement du fonctionnel ?
[^] # Re: Et si le problème venait de Javascript lui-même ?
Posté par Enjolras . En réponse au journal JavaScript, performances, et Firefox. Évalué à 1.
Et haskell ! Par contre je ne suis pas d'accord pour inclure C#.
[^] # Re: Et si le problème venait de Javascript lui-même ?
Posté par Enjolras . En réponse au journal JavaScript, performances, et Firefox. Évalué à 5.
Au passage, la réponse de Brendan Eich à la question :
# Projet
Posté par Enjolras . En réponse au journal En France on n'a pas de pétrole. Évalué à 6.
Je dois dire que le dépôt git allemand m'avait tellement enthousiasmé que je suis prêt à tenter l'aventure avec la loi française, avec peut être une interface web en prime. Mais je n'ai pas toutes les compétence nécessaire à un tel projet, notament en technologie web, je n'en ai aucune. Si des gens sont intéressés… L'union fait la force.
[^] # Re: Et si le problème venait de Javascript lui-même ?
Posté par Enjolras . En réponse au journal JavaScript, performances, et Firefox. Évalué à 6.
C'est un peu le troll sous entendu de mon journal oui. Tu me fais craindre de l'avoir trop sous-entendu :'(.
Cela dit, NULL, NaN, et undef ne sont pas des problèmes en soi. Ils découlent des choix généraux du langage.
NULL est une valeur dans quasiment tout langage qui se respecte.
NaN vient du fait que les nombres sont par défaut des doubles IEEE754, donc NaN est une valeur parfaitement normale, et ne pose pas tant de problème que ça, pas plus que le calcul flottant lui même. Les entiers n'existent pas en JavaScript, même s'ils existent dans les JIT parce que c'est souvent plus rapide.
Enfin, je ne pense pas que ce genre de chose soit un problème vraiment grave comparé au non déterminisme du typage. Indépendament de ça, je n'ai jamais écrit plus de 20 lignes de JavaScript moi même.
[^] # Re: Petites corrections
Posté par Enjolras . En réponse au journal JavaScript, performances, et Firefox. Évalué à 6.
C'est vrai, j'avoue, j'ai pas relu, mea culpa. D'ailleurs, je voulais ajouter aussi quelques lien, mais j'ai écrit ça en one-shot, et après deux heures de travail, j'étais tellement content que j'ai pas pu m'empêcher de cliquer sur envoyer. :/
[^] # Re: Ce que je n'aime pas chez KDE
Posté par Enjolras . En réponse à la dépêche KDE 4.9 est sorti. Évalué à -2.
Pourquoi faut ils que ça parte toujours en troll, avec des rageux qui sont là pour défendre leur bureaux préférés ? J'ai comme l'impression que tu n'as pas lu ce que j'ai écrit.
[^] # Re: Ce que je n'aime pas chez KDE
Posté par Enjolras . En réponse à la dépêche KDE 4.9 est sorti. Évalué à -1.
Simplifier, ça veut pas dire "tout cacher dérrière un bouton"… Mais oui, ils font quand même quelques progrés.
# Ce que je n'aime pas chez KDE
Posté par Enjolras . En réponse à la dépêche KDE 4.9 est sorti. Évalué à 1.
Ce sont les applications.
Je me suis forcé à tester plusieurs fois KDE pendant 3semaines, et autant j'aime beaucoup le bureau, sa flexibilité, et les technologies qu'il y a derrière, autant j'ai vraiment du mal avec les applications.
J'ai beaucoup aimé la direction simplificatrice qu'a pris GNOME, mais maintenant ils vont trop loin.
Ce que je n'aime pas dans les applications KDE (et a fortiori dans les applications E d'ailleurs), c'est leur surcharge. Il y a des tones d'actions visibles par défaut qui ne sont utilisées que rarement. Pour moi, de base, il ne devrait y avoir que les actions que tu fais 80% du temps, le reste étant caché dans des endroits moins visible, mais simple à trouver. De plus, les menus/toolbar contextuels sont une bonne chose, et c'est une bonne idée que commence à avoir GNOME là, sauf que ça serait bien s'ils y en avait plus qui qui font plus de choses.
Ce que je n'aime pas non plus, c'est qu'il y a trés trés souvent 2/3 façon d'accomplir la même tâche, et aucune n'est mise en avant. Exemple, dans dolphin, on peut faire le copier coller d'au moins 3 manières, et toutes en 4 clics. 4 clics c'est beaucoup. De plus, l'interface ne te guide pas, c'est toi qui doit la guider. Et ça pour moi, c'est un gros défaut. D'aucun diront que je je suis un nazi de l'interface. Peut être. Mais à quoi sert une machine si elle ne nous aide pas ?
Pour résumer, je pense que l'approche d'UX qu'a choisis GNOME est fondamentalement bonne, mais qu'ils ont cru que pour la réaliser, il fallait tout supprimer, ce qui est à mon sens complétement faux. (enfin, la suppression de features a aussi lieu parce qu'ils essaient de faire énormément en peu de temps avec pas grand monde, et donc, ils font le minimum). J'aimerais que KDE prenne une approche similaire en conservant sa flexibilité.
[^] # Re: Typographie
Posté par Enjolras . En réponse à l’entrée du suivi Alinea en début de paragraphe. Évalué à 1 (+0/-0).
Je ne suis pas très calé non plus, tout ce que je sais c'est que c'est ce que j'ai l'habitude de voir, maintenant, les typographes expérimentés peuvent penser que c'est un mauvais comportement. Je ne sais pas s'il y a vraiment un usage de référence de toute manière.
je ne suis pas un typographe extrémiste, je trouvais que c'était une typographie plus naturelle et plus lisible pour les longs journaux, mais ça peut être aussi chargé dans le cas de nombreux paragraphes.
Ce n'est peut être pas la peine de se prendre la tête la dessus pendant des heures, je ne sais pas vraiment ce qu'il convient de faire, donc tu n'as qu'à faire ce que tu veux :).
[^] # Re: Typographie
Posté par Enjolras . En réponse à l’entrée du suivi Alinea en début de paragraphe. Évalué à 2 (+0/-0).
Grande nouvelle…
LaTeX avec babel paramétré en français ne respecterait-il pas la typographie française ?
La bibliothèque de la pléiade de Gallimard non plus ? J'aimerais bien savoir d'où vient cette règle de mettre des Alinéa alignés et non des alinéa rentrants après un saut de ligne…
[^] # Re: Excusez moi mais…
Posté par Enjolras . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 2.
Tiens c'est nouveau, Ubuntu, Debian, RedHatn et les autres utilisent plu sdes init SystemV…
[^] # Re: Excusez moi mais…
Posté par Enjolras . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 2.
Je connais bien FreeBSD ne t'en déplaise, enfin, surtout Dragonfly, mais je répondais surtout sur Arch, parce qu'en effet la majorité des arguments ne tiennent pas. Surtout pas le cgroups, parce qu'ils n'existent pas.
Enfin, il y a les jails, mais c'est pas tout à fait pareil, c'est plus l'équivalent de LXC.
j'ai déjà répondu aussi.
Grande nouvelle, il n'y en a juste moins que dans system V.
Perdu aussi, du moins si tu considères que sh est bourne shell. /bin/sh est juste un shell compatible posix shell. Même s'il y a beaucoup moins d'extensions que bash, il y en a.
Bon, puisque tu veux à tout pris un exemple, je ne pense pas qu'il soit spécifié quand est réalisée l’expansion dans des expressions complexes comme if.
Redéfinition des fonctions/variables sans que ça râle, possibilité de changer les options du shell, j'en passe, ça demande plus de précautions pour coder
Sinon la grammaire du bourne shell doit être équivalente, la grammaire de bash au moins 3 fois plus longue.
[^] # Re: Excusez moi mais…
Posté par Enjolras . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 2.
Je suis d'accord que la doc sous FreeBSD est pas mal, mais sous linux, c'est loin d'être le cas, et comme tu peux le remarquer, je ne parlais pas de freeBSD en particulier.
j'ai l'impression que tu n'as pas compris le problème, parce que & ne permet pas de faire simplement des choses de manière asynchrones. D'ailleurs, tu peux lire les scripts, tu verras qu'il n'est pas utilisé souvent.
manque de pôt, c'est peut être facile, mais ce n'est pas fait. D'ailleurs, ce n'est pas aussi simple que ce que tu veux le faire croire. Si par exemple tu décides de lancer ttout les daemons réseaux dans un cgroup particulier tu aimerais bien que l'init le gére pour toi.
J'en connais pas beaucoup… Les niveaux traditionnels sont "single user, stop, multi-user,etc" mais ça suffit pas. Souvent tu aimerais bien avoir des niveaux comme "connecté à internet, connecté localement, synchronisation, maintenance, whatever you want to do"
J'aimerais bien avoir un init qui permet de gérer ça simplement sans avoir à bricoler mes scripts par dessus.
Encore une fois, c'est vrai pour FreeBSD dont l'init est très bien fait, parce qu'il fonctionne uniquement avec des scripts rc, mais pas pour tout les init BSD like. Tiens au passage, je me permet de faire remarquer que c'est exactement le fonctionnement de systemd.
[^] # Re: Excusez moi mais…
Posté par Enjolras . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 0.
Bien documenté, j'aimerais bien voir la doc… Bien commenté certes, mais c'est la moindre des choses. POurquoi c'est un hack ? Incapable de s'éxécuter de manière efficace sur un processeur moderne avec SMP. Incapable de gérer les processus de manière moderne sous linux (crgoups, et compagnie). MAnque de souplesse au niveau de la gestion des niveaux d'éxécution. Impossible de modifier le processus de boot (enlever/ajouter des opérations) sans modifier un script shell monolithique.
Sans aller jusqu'a un langage fonctionnel, il y a des langages simples avec une grammaire qui tient en 20 lignes : cf lua
je doute qu'on ai réellement besoin d'utiliser ${!prefix@} dans un init.
sans aller vers une sémantique non définie, le shell demande des précautions infinies d'échapements et de gestion de l'environnement pour s'éxécuter dans un environnement confiné en lisant des paramètres en shell quelque part…
je ne parle pas de ce code là. Je parle des scripts de lancement de daemons dans rc.d (c'est pire sous archlinux que sous FreeBSD là)
[^] # Re: Excusez moi mais…
Posté par Enjolras . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à -5.
Je n'ai pas parlé de systemd. Je parle de ce que certains semblent considérer comme le graal, les init BSD-like.
Quelle est la différence entre un installateur et un init ? Dans les deux cas il y a une interaction utilisateur, ça t'arrive jamais de lancer un daemon ou de vérifier le status d'un autre ? Ou même de vouloir gére tes crgoups ? Le fait qu'init tourne constament est justement un argument de robustesse, donc, ce qui s'applique pour un installateur, qui est exécuté une seule fois, devrait s'appliquer a fortiori à un init.
Je n'ai ni confiance en C, ni en POSIX shell.
# Excusez moi mais…
Posté par Enjolras . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 10.
Vous trouvez ça KISS ?
Que ça soit Archlinux ou FreeBSD, je trouve que le systéme de boot est un pur amas de hacks. Déjà, les scripts sont écrits dans un langage non typé, dont la grammaire fairait tomber en syncope un grammairien français (c'est dire !), et dont la sémantique est tout sauf simplement définie. Un truc qui fuit de partout en amassant des données n'importe ou là ou il ne devrait pas (environnement, tout ça). Bref, un truc écrit dans un langage bloat, pas safe, avec de la duplication de code (oui les scripts rc sont tous les mêmes), qui apporte quoi au final ?
Et on appelle ça KISS ?
Pour finir, une petite quote de l'installateur d'openBSD :
[^] # Re: Rekonq
Posté par Enjolras . En réponse à la dépêche Rekonq 1.0. Évalué à 1.
Non, ça c'est juste que Evolution, c'est (c'était) developpé par des éxtrémistes conservateurs qui ne veulent surtout rien changer. Mais ça a l'air d'avoir changé.
# Saviez vous que 40% des acheteurs de GPS étaient des femmes ?
Posté par Enjolras . En réponse au journal Voltaire est mon ami. Évalué à 1.
Bah oui, on vous l'avez dit que les femmes ne savaient pas s'orienter !
[^] # Re: Rekonq
Posté par Enjolras . En réponse à la dépêche Rekonq 1.0. Évalué à 10.
Webkit est fourni sous la forme d'une api multiplateforme d'assez bas niveau, qui gère uniquement le rendu/le dom/JavaScript. Par dessus, il y a différents bindings, pour divers toolkits graphiques :
Dans la version dite "1" de l'API webkit de base, il n'y a qu'un seul processus qui gère le rendu. Par dessus, on peut implémenter le processus qui gère l'UI, c'est ce que simplifient les différentes API pour les divers toolkit. Google a décider avec chrome de séparer cette UI dans un autre processus, mais ce n'est pas géré par webkit, c'est leur propre sauce, ce n'est pas trivial à implémenter avec n'importe quelle API webkit.
Cela dit, il y a une nouvelle version de l'API de base, webkit2, sortie en 2010. Cette version inclue directement dans l'API webkit de base un modèle similaire à chrome, séparent le contenu de l'UI dans des processus séparés, et pouvant placer divers contenus dans divers processus.
WebkitGTK a un support en court de stabilisation de webkit2 et gnome a annoncé vouloir sortir une version beta d'épiphany avec webkit2 pour GNOME 3.6. J'imagine que ça va arriver aussi sous KDE/rekonq.
Donc, pour résumer, même si tu ne parlais que des plugins et non de tout les contenus, non, ce n'est pas trivial à faire à moins de porter le navigateur vers la nouvelle API. Sinon il faut bricoler soit même.
[^] # Re: Distrib pour developpeur
Posté par Enjolras . En réponse au journal Mon point de vue sur Archlinux. Évalué à 2.
Ça fait longtemps que c'est en discussion, mais ça ne s'est toujours pas concrétisé. Si tu veux vraiment que ça arrive, vas mettre ton grain de sel sur le bug.