À mon avis, un utilisateur avancé, c'est surtout quelqu'un qui n'est pas intimidé par sa machine, qui sait identifier les différents éléments sur son écran, et qui sait aller lire l'aide s'il a des questions.
Autrement dit, c'est une toute petite minorité des utilisateurs ;)
Mais bon, plutôt qu'une distinction débutant/expert, une distinction simple/personnalisable reviendrait au même, sans inciter les vaniteux utilisateurs à se prétendre experts.
En visant le grand public, GNOME devient absolument inadapté au reste des utilisateurs.
Mince alors, je fais partie du grand public. Ça y est, je suis déprimé pour la journée.
C'est un peu fatiguant cette habitude de généraliser: je suis un power-user, Gnome ne me plait pas, donc Gnome ne plait à personne sauf aux débutants.
Toutes les options complexes seraient dissimulées aux premiers et visibles au second. [...] Mais pour l'instant, on navigue entre les deux extrêmes, entre GNOME où il n'y a plus rien et KDE
Dans une certaine mesure, c'est ce qu'essaye de faire Gnome. Les options avancées sont (parfois) là, mais cachées. Certes, ce que tu proposes serait mieux, mais Gnome a déjà du mal à faire son interface "simple", alors je doute qu'ils s'amusent à faire une deuxième interface plus commplexe avant un moment.
Ils avaient déjà essayé ce genre de choses avec Nautilus, d'ailleurs, mais ça n'avait pas eu de succès (probablement parce que Nautilus était une grosse boue à l'époque).
L'autre concept de base, toujours a mon sens, c'est : si t'es pas capable de savoir _-=*TRES EXACTEMENT*=-_ comment implementer/presenter une feature, tu l'implementes pas.
Ou alors tu l'implémentes, mais dans une branche "de développement", pas dans la release officielle. C'est le principal défaut des releases à dates fixes, d'ailleurs: si tu dois sortir une version tous les six mois, tu hésites à entamer des changements qui prendront plus de six mois.
Ou alors tu le fais quand même et tu te fais engueuler par les utilisateurs frustrés (voir par exemple le cas du nouveau menu xdesktop de Gnome, qui n'était plus éditable dans la branche 2.10).
Si Gnome en est réduit à cacher des fonctionalités basiques de cette manière, c'est quand même qu'il y a un problème, non ?
Si on part du principe que toutes les fonctionnalités doivent être visibles, c'est sûr que la politique de Gnome semble étrange. Eux partent du principe que les fonctionnalités pour utilisateurs avancés doivent être suffisamment cachées pour ne pas troubler l'utilisateur qui s'en fout.
Qualifier la possibilité de taper le chemin d'un fichier de "fonction pour utilisateurs avancés" peut sembler bizarre, mais quand je vois les autres membres de ma famille utiliser un ordinateur, je me dit que ce n'est peut être pas si idiot que ça.
(Disclaimer: j'avoue que je suis plutôt à l'aise avec les réglages par défaut de Gnome, à part pour metacity. Et que le gestionnaire de fichiers qui me déplaisait commence à me plaire maintenant qu'ils corrigent les bugs)
Admettons que tu veux rajouter un wallpaper sur le thème linux, sans casser ton classement. Si tu veux faire des sous-répertoires, tu dois faire:
~/wallpapers/linux/
~/linux/wallpapers/
Si tu ne fais que le premier, alors ton dossier linux ne contient pas tous tes fichiers concernant linux.
Il m'est arrivé par moments de voir tout un thread masqué par les votes, et de ne pas aller voir ce qu'il y avait dedans, parce que c'est un phénomène tellement rare que ça reflétait certainement un manque d'intérêt énorme.
D'un autre côté, quand un message au milieu d'une discution est masqué, je regarde presque automatiquement son contenu. Il y a vraiment un problème de logique dans le fait d'avoir des messages "inutiles" et des réponses "pertinentes".
Mais bon, puisqu'il est toujours possible de voir les messages masqués, finalement c'est plutôt léger comme modération, non ? Et si des gens préfèrent naviguer à +5, pourquoi pas.
L'idéal pour moi serait de pouvoir "black-lister" certaines personnes
Ça suppose que ce sont des personnes qui sont "pertinentes" ou "inutiles", et plus des messages. Je ne suis pas trop d'accord, il m'arrive (j'espère) d'écrire des trucs pertinents, mais il m'arrive aussi d'écrire des trucs inutiles. De la même manière, il y a très peu de gens que je voudrait blacklister, et pourtant des fois je n'ai pas envie de lire leurs délires persos.
Bref, tout celà pour dire que je me demande bien si le système de vote de linuxfr.org n'est pas un moyen de garder certains de ses lecteurs accros à l'xp dépendants au site.
Ça fait longtemps que les XP ne sont plus visibles, je vois mal comment on peut encore faire la course à l'XP. Un jour je me suis réveillé avec le droit à 5 votes de plus, donc je suppose que les XP existent encore, mais d'un autre côté je n'arrive pas à utiliser plus d'une dizaine de votes par jour, dans les meilleurs jours (ne serait-ce que parce qu'une partie de mes votes n'est pas comptabilisée, sans que je sache pourquoi).
Au final, à part pour les gens qui ont peu d'XP et risquent d'etre interdits de parole, la course aux XP se manifeste comment ?
[avec Gentoo] vous pouvez meme vous créer facilement des paquets
Juste pour info, les packages Debian sont faciles aussi à faire soi même, avec l'aide des outils livrés en standard. Le plus souvent, il suffit de lancer un script, éditer la description du paquet et de copyright, et les règles de construction. Si le logiciel à packager utilise autotools ou des makefiles propres, il n'y a pratiquement rien à faire d'autre qu'entrer la description du paquet.
Bref, c'est comme la compilation de noyau: au début ça fait peur, et en fait c'est tout bête.
C'est vrai, mais malheureusement les machines sur lesquelles on voudrait économiser des cycles et de la mémoire sont généralement des machines sur lesquelles on n'a pas envie de lancer une grosse compilation, sous peine d'y passer des jours.
Sur les grosses machines qui n'ont pas peur de compiler KDE en entier, ce n'est pas l'économie de quelques Mo de code qui va changer grand chose niveau performances. En dehors du fait d'être persuadé d'avoir un système optimal, ce qui se défend :)
Il n'a jamais, et il ne le sera probablement jamais, été prouvé que la recompilation pouvait optimiser des programmes.
Ce n'est pas la recompilation qui optimise les programmes, c'est le fait de recompiler en spécifiant d'utiliser des optimisations pour son architecture. Et c'est un fait, ça optimise les programmes. Ce qui est douteux, c'est que le gain soit sensible dans la vie de tous les jours.
Par contre, quelque chose me dit qu'avec l'arrivée des processeurs de type Cell ou autre, ça va devenir vraiment intéressant pour le compilateur de savoir quelle est l'architecture utilisée.
Non, un bord résistant, c'est un bord qui "résiste" avant de se faire dépasser par une fenêtre. Par exemple si tu déplaces ta fenêtre vers la gauche, la bordure gauche de ton écran résiste un peu, et donc la fenêtre ne sort pas de l'écran. En forcant, on dépasse le seuil de résistance et la fenêtre sort.
C'est valable pour les bords de l'écran mais aussi pour les bordures de fenêtres.
Dans un autre style, il y a aussi les bords magnétiques, qui attirent les fenêtres qui se déplacent près d'eux. C'est pratique aussi, mais moins naturel que les bords résistants.
Est ce qu'il faut mieux donner du poisson à des pays pauvres, où leur apprendre à pêcher ?
Les deux ?
Du point de vue "aider un pays à se développer", il vaut mieux leur apprendre à pêcher. D'un point de vue "aider les gens à moins mourir", il vaut mieux les nourrir tout de suite. Maintenant, il doit bien y avoir un moyen de les nourrir tout de suite tout en leur apprenant à pêcher... si on ommet les problèmes politiques.
en terme de développement c'est une catastrophe d'envoyer des denrées gratuitement vers un pays.
C'est une catastrophe seulement si ça ne fait pas partie d'un Grand Plan, si c'est juste pour se donner bonne conscience. Mais c'est valable aussi pour les aides au développement: ça ne rime à rien d'aider des pays du sud à mieux produire si en même temps on prend des mesures économiques pour favoriser nos producteurs à nous sur le marché mondial.
En fait il y a deux choses importantes:
- À l'échelle mondiale, on pourrait nourrir tout le monde sans trop de difficultés.
- Ce qui nous en empêche, ce sont des raisons politiques. Principalement la division du monde en nations (qui n'est pas prêt de changer), et le fait que les gens préfèrent favoriser les habitants de leur propre nation que ceux des autres.
Finalement, on attend de la science une solution qui permette de faire en sorte que tous les pays produisent le nécessaire, parce qu'on estime que c'est plus facile (ou plus souhaitable) que résoudre le problème de manière politique. À mon avis un jour où l'autre il faudra aussi résoudre le problème politique, mais c'est vrai que ça semble insurmontable.
regardent la gueule du mais sauvage et du mais cultivé et on en reparle, et pose toi la question si le mais cultivé est viable sans interventions humaines.
Quand je parle de "naturel", je ne veux pas dire "sans intervention humaine" mais plutôt "qui suit le processus naturel de l'évolution". Avec la "bonne vieille agriculture", l'homme crée des conditions favorables aux espèces qu'il cultive, mais il est limité dans ses possibilités d'influencer leur évolution.
Ça fait longtemps que l'homme applique une pression sélective sur les espèces qu'il cultive, mais la différence fondamentale entre l'agriculture naturelle et les OGM, c'est que dans le cas des OGM on peut faire des "bonds" évolutifs qui n'auraient pas pu s'effectuer avec une évolution naturelle.
Quand on dit ça à un scientifique, il est tout content à l'idée des nouvelles possibilités. Mais dans l'esprit du grand public, Mère Nature a encore bonne presse, malgré les maladies qu'elle crée régulièrement. Et donc n'importe quoi qui peut être qualifié de "non naturel" fait peur...
On pourrait dans certains cas produire des plantes capables de synthétiser de l'insuline ou du sang.
Ca te choques pas ?
Pour l'insuline par exemple, entre la faire synthétiser par un cochon et la faire synthétiser par une plante, je préfère la version qui utilise un organisme qui n'a pas de système nerveux.
Et puis si un scientifique inventait une machine mécanique qui synthétise de l'insuline, ça ne choquerait personne, alors pourquoi est-ce que le fait que cette machine soit organique choque ?
de toutes façon une fois que le mecs a acheté ses graines il plante il fait sa recolte et il en garde une partie non?
Non justement, la grande trouvaille des boîtes qui font des OGM, ce sont les semences dont on ne peut pas réutiliser le fruit. On est donc obligé de se réapprovisionner systématiquement. Et bien sûr, il y a des brevets par dessus pour éviter que les pays en développement ne développent leurs propres versions des OGM.
À mon avis, la raison pour laquelle les producteurs mettent des gros "SANS OGM" rouges sur leurs boîtes de conserve, c'est que le grand public a peur d'en manger.
A la fois je me demande bien ce que tout le monde crains avec les OGM
Ils craignent la loi de Murphy: si quelque chose peut mal tourner, alors ça tournera mal (et de la pire manière qui soit).
Lorsqu'on mange du maïs normal on ne se transforme pas en mais alors pourquoi avec les OGM?
La différence entre du maïs normal et du maïs OGM, c'est que le maïs normal a évolué tout seul, alors que le maïs OGM on lui a inséré des gènes qui proviennent d'autres espèces, éventuellement animales. Il est possible de produire manuellement des espèces qui n'auraient pas évolué naturellement de cette manière parce que les mutations permettant de passer de "maïs normal" à "super maïs" étaient non viables ou "moins adaptées".
Et ce qui fait peur aux gens, c'est qu'on ne peut pas garantir que ce genre d'organismes ne peuvent pas être dangereux. On ne peut pas non plus garantir non plus qu'une espèce naturelle n'est pas dangereuse, mais comme elle a l'étiquette "naturel" ça ne gène pas les gens :)
les OGM ça pourrait permettre d'arreter de pourrir les sols
Oui mais les espèces OGM qui se reproduisent par reproduction sexuée se répandent, et donc si jamais une d'entre elle était dangereuse, elle ferait bien plus que simplement pourrir le sol: elle contaminerait les cultures voisines.
D'où l'appel au principe de précaution.
ce sera surment bien pratique dans certain pays pour leur permettre d'eviter les famines avec des plants plus resistants
C'est un autre problème, mais les entreprises qui produisent des OGM sont ravies de fournir aux paus en développement des plants résistants... et stériles.
ca devrait être rendu obligatoire par la loi. Au même titre qu'on impose des avertissements explicites sur le tabac, ni plus ni moins.
L'amalgame est osé: dans le cas du tabac on sait que c'est dangereux, dans le cas des OGM on n'en sait rien, c'est pour ça que les anti-OGM font référence au « principe de précaution » et pas au principe de « mange des OGM et tu es mort ».
Donc en fait, tu penses que le premier langage de programmation, celui dans lequel toutes les méthodes renvoient des chaînes, est plus générique que le deuxième ?
Donc, avec ton exemple, pour que grep marche il faut une méthode read_char. Si tu veux un cut ? il faut un select_fields(), etc ... en gros une méthode par programme à piper ?
C'est un argument circulaire: tu pars tu principe que pour faire quelque chose avec l'objet, il faut que tout le traitement soit contenu dans l'objet, et tu conclus qu'il faut une méthode par programme à piper.
Si tu veux faire un cut, tu n'as pas besoin d'une méthode qui te renvoie des champs. Tu as juste besoin d'une méthode read_char, comme pour grep. Par contre si tu as à ta disposition une méthode qui te donne une liste de champs, c'est encore mieux.
D'un autre côté, si tu prends toujours comme exemple des commandes qui manipulent du texte, tu n'auras jamais intéret à obtenir en entrée autre chose que du texte. Ça ne devient intéressant que dans le cas de données structurées associées à leur comportement.
chaque objet est spécifique.
Ce n'est pas vrai, tout dépend de la hiérarchie de classes utilisées. Si tu dis "je reçois en entrée n'importe quel objet qui implémente les méthodes ajouter et multiplier", tu peux faire un programme qui fait des opérations sur plein de types d'objets. Mais là on n'est pas dans une discution sur l'intéret de pouvoir piper des objets, on est dans une discution sur les mérites de la programmation objet en général.
Et même si chaque objet était spécifique, admettons que dans un script shell j'aie besoin de prendre une date et d'ajouter trois jours à cette date. Dans le bon vieux modèle Unix, je pourrais piper le résultat de "date" dans mon script, le parser, et ensuite écrire un algo qui ajoute trois jours, et qui change de mois/année quand c'est nécessaire. Dans un modèle objet, ça donnerait ça:
d = lire_une_date_en_entrée();
d2 = d+3;
À condition que la méthode Date::+ soit fournie par l'objet. C'est du code spécifique à l'objet Date, mais ça va tout à fait dans l'esprit de réutilisation de code, puisque c'est disponible pour tous les programmes qui veulent manipuler des dates.
Imagine un langage de programmation objet dans lequel on ne peut avoir que des méthodes qui renvoient des chaînes de caractère. Tu peux avoir un objet du genre Fonction, qui fournit une méthode Fonction::dérivée, mais cette méthode ne renvoit pas une fonction mais une chaîne, que tu dois parser pour avoir une fonction. Pour calculer une dérivée seconde, on fait:
f = Fonction.parse("3x²+4x+6")
f'' = Fonction.parse( (Fonction.parse(f.dérivée).dérivée )
Tout le monde sera d'accord pour dire que ce n'est pas très efficace: la méthode dérivée est obligée de convertir sa valeur de retour en chaîne de caractères, et après on est obligé de parser à nouveau pour avoir une fonction. Il serait bien plus simple de manipuler les objets sans passer par des chaines:
f = Fonction.parse("3x²+4x+6")
f'' = f.dérivée.dérivée
Dans cette analogie, le premier langage c'est les commandes Unix et la communication par flux. Comme tu ne peux pas échanger des objets, tu dois te taper les conversions de données à chaque fois.
Maintenant, pour en venir à ton objection:
Si tu passes un objet, imagine faire un grep, si tu n'a acces qu'à des méthodes, c'est comme si grep était inclus dans l'objet d'entrée ! Donc il n'y plus d'interet à piper.
Je te répondrais que ce n'est pas vrai dans l'analogie des langages de programmation, et que ce n'est pas vrai non plus dans le cas de programmes qui communiquent avec des objets. Pourquoi ? Parce que si on peut emboîter des objets dans un langage objet, on peut aussi emboiter des programmes qui manipulent des objets.
Typiquement, un programme Grep n'est applicable qu'à des objets contenant des chaînes de texte. Donc, le programme Grep serait défini comme recevant en entrée des objets implémentant la méthode read_char, et c'est tout ce qui est nécessaire, pas besoin de coder un grep dans l'objet lui même. Dans ce cas, l'objet reçu en entrée est en pratique un flux, comme dans le bon vieux Unix, parce que par définition Grep fonctionne sur des flux.
Maintenant si on prend un programme qui manipule autre chose que des flux, par exemple des dates, on a intéret à pouvoir lire en entrée directement un objet Date avec ses méthodes day, week, year, etc.
Pour prendre un exemple idiot, qui ne s'est jamais énervé sur son script shell qui ne donnait pas de bons résultats, simplement parce qu'on a donné en entrée un nombre décimal comme "3.14", alors que dans la locale fr, awk considère que le séparateur est une virgule, et qu'il fallait entrer "3,14" ?
Donc celui qui reçoit l'objet doit connaitre son interface. Donc, tu limite vachement les possibilités de pipe. Avec XML, il y a juste à connaitre le xml.
N'importe quoi... dans les deux cas, si tu ne sais pas ce que tu reçois, tu ne peux pas le traiter, et le XML n'est pas une solution magique. Il s'agit d'un format standardisé, mais tu as toujours besoin de savoir comment manipuler ce qui est contenu dedans.
Opposer les échanges d'objets et les échanges de XML, c'est très étrange. On peut très bien échanger des objets en utilisant le format XML, par exemple. Bref, choisir le format (XML) c'est bien, mais il faut encore choisir le protocole (objets sérialisés, données brutes, ...)
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal Gnome fait par des nazis de l'interface ?. Évalué à 6.
Autrement dit, c'est une toute petite minorité des utilisateurs ;)
Mais bon, plutôt qu'une distinction débutant/expert, une distinction simple/personnalisable reviendrait au même, sans inciter les vaniteux utilisateurs à se prétendre experts.
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal Gnome fait par des nazis de l'interface ?. Évalué à 4.
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal Gnome fait par des nazis de l'interface ?. Évalué à 5.
Mince alors, je fais partie du grand public. Ça y est, je suis déprimé pour la journée.
C'est un peu fatiguant cette habitude de généraliser: je suis un power-user, Gnome ne me plait pas, donc Gnome ne plait à personne sauf aux débutants.
Dans une certaine mesure, c'est ce qu'essaye de faire Gnome. Les options avancées sont (parfois) là, mais cachées. Certes, ce que tu proposes serait mieux, mais Gnome a déjà du mal à faire son interface "simple", alors je doute qu'ils s'amusent à faire une deuxième interface plus commplexe avant un moment.
Ils avaient déjà essayé ce genre de choses avec Nautilus, d'ailleurs, mais ça n'avait pas eu de succès (probablement parce que Nautilus était une grosse boue à l'époque).
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal Gnome fait par des nazis de l'interface ?. Évalué à 3.
Et après s'être dit ça, on peut se demander à quoi ça servirait que les deux leaders du desktop libre choisissent d'aller dans la même direction...
[^] # Re: my 2 cents, by Kent Brockman
Posté par Yusei (Mastodon) . En réponse au journal Gnome fait par des nazis de l'interface ?. Évalué à 4.
Ou alors tu l'implémentes, mais dans une branche "de développement", pas dans la release officielle. C'est le principal défaut des releases à dates fixes, d'ailleurs: si tu dois sortir une version tous les six mois, tu hésites à entamer des changements qui prendront plus de six mois.
Ou alors tu le fais quand même et tu te fais engueuler par les utilisateurs frustrés (voir par exemple le cas du nouveau menu xdesktop de Gnome, qui n'était plus éditable dans la branche 2.10).
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal Gnome fait par des nazis de l'interface ?. Évalué à 9.
Si on part du principe que toutes les fonctionnalités doivent être visibles, c'est sûr que la politique de Gnome semble étrange. Eux partent du principe que les fonctionnalités pour utilisateurs avancés doivent être suffisamment cachées pour ne pas troubler l'utilisateur qui s'en fout.
Qualifier la possibilité de taper le chemin d'un fichier de "fonction pour utilisateurs avancés" peut sembler bizarre, mais quand je vois les autres membres de ma famille utiliser un ordinateur, je me dit que ce n'est peut être pas si idiot que ça.
(Disclaimer: j'avoue que je suis plutôt à l'aise avec les réglages par défaut de Gnome, à part pour metacity. Et que le gestionnaire de fichiers qui me déplaisait commence à me plaire maintenant qu'ils corrigent les bugs)
[^] # Re: et avec ça...
Posté par Yusei (Mastodon) . En réponse au journal Intégration Beagle dans nautilus. Évalué à 4.
~/wallpapers
~/linux
Admettons que tu veux rajouter un wallpaper sur le thème linux, sans casser ton classement. Si tu veux faire des sous-répertoires, tu dois faire:
~/wallpapers/linux/
~/linux/wallpapers/
Si tu ne fais que le premier, alors ton dossier linux ne contient pas tous tes fichiers concernant linux.
# Pas si mal ?
Posté par Yusei (Mastodon) . En réponse au journal Les "plus" & les "moins". Évalué à 7.
D'un autre côté, quand un message au milieu d'une discution est masqué, je regarde presque automatiquement son contenu. Il y a vraiment un problème de logique dans le fait d'avoir des messages "inutiles" et des réponses "pertinentes".
Mais bon, puisqu'il est toujours possible de voir les messages masqués, finalement c'est plutôt léger comme modération, non ? Et si des gens préfèrent naviguer à +5, pourquoi pas.
Ça suppose que ce sont des personnes qui sont "pertinentes" ou "inutiles", et plus des messages. Je ne suis pas trop d'accord, il m'arrive (j'espère) d'écrire des trucs pertinents, mais il m'arrive aussi d'écrire des trucs inutiles. De la même manière, il y a très peu de gens que je voudrait blacklister, et pourtant des fois je n'ai pas envie de lire leurs délires persos.
Ça fait longtemps que les XP ne sont plus visibles, je vois mal comment on peut encore faire la course à l'XP. Un jour je me suis réveillé avec le droit à 5 votes de plus, donc je suppose que les XP existent encore, mais d'un autre côté je n'arrive pas à utiliser plus d'une dizaine de votes par jour, dans les meilleurs jours (ne serait-ce que parce qu'une partie de mes votes n'est pas comptabilisée, sans que je sache pourquoi).
Au final, à part pour les gens qui ont peu d'XP et risquent d'etre interdits de parole, la course aux XP se manifeste comment ?
[^] # Re: bof
Posté par Yusei (Mastodon) . En réponse au journal apt-build : gadget ou pas ? votre avis à vous ?!. Évalué à 7.
Juste pour info, les packages Debian sont faciles aussi à faire soi même, avec l'aide des outils livrés en standard. Le plus souvent, il suffit de lancer un script, éditer la description du paquet et de copyright, et les règles de construction. Si le logiciel à packager utilise autotools ou des makefiles propres, il n'y a pratiquement rien à faire d'autre qu'entrer la description du paquet.
Bref, c'est comme la compilation de noyau: au début ça fait peur, et en fait c'est tout bête.
[^] # Re: bof
Posté par Yusei (Mastodon) . En réponse au journal apt-build : gadget ou pas ? votre avis à vous ?!. Évalué à 7.
Sur les grosses machines qui n'ont pas peur de compiler KDE en entier, ce n'est pas l'économie de quelques Mo de code qui va changer grand chose niveau performances. En dehors du fait d'être persuadé d'avoir un système optimal, ce qui se défend :)
[^] # Re: bof
Posté par Yusei (Mastodon) . En réponse au journal apt-build : gadget ou pas ? votre avis à vous ?!. Évalué à 8.
Ce n'est pas la recompilation qui optimise les programmes, c'est le fait de recompiler en spécifiant d'utiliser des optimisations pour son architecture. Et c'est un fait, ça optimise les programmes. Ce qui est douteux, c'est que le gain soit sensible dans la vie de tous les jours.
Par contre, quelque chose me dit qu'avec l'arrivée des processeurs de type Cell ou autre, ça va devenir vraiment intéressant pour le compilateur de savoir quelle est l'architecture utilisée.
[^] # Re: et ...
Posté par Yusei (Mastodon) . En réponse au journal Grand moment pour Gnome. Évalué à 3.
C'est valable pour les bords de l'écran mais aussi pour les bordures de fenêtres.
Dans un autre style, il y a aussi les bords magnétiques, qui attirent les fenêtres qui se déplacent près d'eux. C'est pratique aussi, mais moins naturel que les bords résistants.
[^] # Re: Famine
Posté par Yusei (Mastodon) . En réponse au journal Pas d'OGM dans les assiettes. Évalué à 5.
Les deux ?
Du point de vue "aider un pays à se développer", il vaut mieux leur apprendre à pêcher. D'un point de vue "aider les gens à moins mourir", il vaut mieux les nourrir tout de suite. Maintenant, il doit bien y avoir un moyen de les nourrir tout de suite tout en leur apprenant à pêcher... si on ommet les problèmes politiques.
C'est une catastrophe seulement si ça ne fait pas partie d'un Grand Plan, si c'est juste pour se donner bonne conscience. Mais c'est valable aussi pour les aides au développement: ça ne rime à rien d'aider des pays du sud à mieux produire si en même temps on prend des mesures économiques pour favoriser nos producteurs à nous sur le marché mondial.
En fait il y a deux choses importantes:
- À l'échelle mondiale, on pourrait nourrir tout le monde sans trop de difficultés.
- Ce qui nous en empêche, ce sont des raisons politiques. Principalement la division du monde en nations (qui n'est pas prêt de changer), et le fait que les gens préfèrent favoriser les habitants de leur propre nation que ceux des autres.
Finalement, on attend de la science une solution qui permette de faire en sorte que tous les pays produisent le nécessaire, parce qu'on estime que c'est plus facile (ou plus souhaitable) que résoudre le problème de manière politique. À mon avis un jour où l'autre il faudra aussi résoudre le problème politique, mais c'est vrai que ça semble insurmontable.
[^] # Re: Aï Aï Aï
Posté par Yusei (Mastodon) . En réponse au journal Pas d'OGM dans les assiettes. Évalué à 2.
Quand je parle de "naturel", je ne veux pas dire "sans intervention humaine" mais plutôt "qui suit le processus naturel de l'évolution". Avec la "bonne vieille agriculture", l'homme crée des conditions favorables aux espèces qu'il cultive, mais il est limité dans ses possibilités d'influencer leur évolution.
Ça fait longtemps que l'homme applique une pression sélective sur les espèces qu'il cultive, mais la différence fondamentale entre l'agriculture naturelle et les OGM, c'est que dans le cas des OGM on peut faire des "bonds" évolutifs qui n'auraient pas pu s'effectuer avec une évolution naturelle.
Quand on dit ça à un scientifique, il est tout content à l'idée des nouvelles possibilités. Mais dans l'esprit du grand public, Mère Nature a encore bonne presse, malgré les maladies qu'elle crée régulièrement. Et donc n'importe quoi qui peut être qualifié de "non naturel" fait peur...
[^] # Re: Ah oué ...
Posté par Yusei (Mastodon) . En réponse au journal Pas d'OGM dans les assiettes. Évalué à 8.
Pour l'insuline par exemple, entre la faire synthétiser par un cochon et la faire synthétiser par une plante, je préfère la version qui utilise un organisme qui n'a pas de système nerveux.
Et puis si un scientifique inventait une machine mécanique qui synthétise de l'insuline, ça ne choquerait personne, alors pourquoi est-ce que le fait que cette machine soit organique choque ?
[^] # Re: Ah oué ...
Posté par Yusei (Mastodon) . En réponse au journal Pas d'OGM dans les assiettes. Évalué à 2.
Les protéines sont un produit de l'ADN.
[^] # Re: Ah oué ...
Posté par Yusei (Mastodon) . En réponse au journal Pas d'OGM dans les assiettes. Évalué à 5.
Non justement, la grande trouvaille des boîtes qui font des OGM, ce sont les semences dont on ne peut pas réutiliser le fruit. On est donc obligé de se réapprovisionner systématiquement. Et bien sûr, il y a des brevets par dessus pour éviter que les pays en développement ne développent leurs propres versions des OGM.
[^] # Re: Ah oué ...
Posté par Yusei (Mastodon) . En réponse au journal Pas d'OGM dans les assiettes. Évalué à 2.
[^] # Re: Ah oué ...
Posté par Yusei (Mastodon) . En réponse au journal Pas d'OGM dans les assiettes. Évalué à 4.
Ils craignent la loi de Murphy: si quelque chose peut mal tourner, alors ça tournera mal (et de la pire manière qui soit).
La différence entre du maïs normal et du maïs OGM, c'est que le maïs normal a évolué tout seul, alors que le maïs OGM on lui a inséré des gènes qui proviennent d'autres espèces, éventuellement animales. Il est possible de produire manuellement des espèces qui n'auraient pas évolué naturellement de cette manière parce que les mutations permettant de passer de "maïs normal" à "super maïs" étaient non viables ou "moins adaptées".
Et ce qui fait peur aux gens, c'est qu'on ne peut pas garantir que ce genre d'organismes ne peuvent pas être dangereux. On ne peut pas non plus garantir non plus qu'une espèce naturelle n'est pas dangereuse, mais comme elle a l'étiquette "naturel" ça ne gène pas les gens :)
Oui mais les espèces OGM qui se reproduisent par reproduction sexuée se répandent, et donc si jamais une d'entre elle était dangereuse, elle ferait bien plus que simplement pourrir le sol: elle contaminerait les cultures voisines.
D'où l'appel au principe de précaution.
C'est un autre problème, mais les entreprises qui produisent des OGM sont ravies de fournir aux paus en développement des plants résistants... et stériles.
[^] # Re: Ah oué ...
Posté par Yusei (Mastodon) . En réponse au journal Pas d'OGM dans les assiettes. Évalué à 4.
L'amalgame est osé: dans le cas du tabac on sait que c'est dangereux, dans le cas des OGM on n'en sait rien, c'est pour ça que les anti-OGM font référence au « principe de précaution » et pas au principe de « mange des OGM et tu es mort ».
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal La liberté de vous l'enlever. Évalué à 6.
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal Langages pour desktop. Évalué à 2.
Donc en fait, tu penses que le premier langage de programmation, celui dans lequel toutes les méthodes renvoient des chaînes, est plus générique que le deuxième ?
C'est un argument circulaire: tu pars tu principe que pour faire quelque chose avec l'objet, il faut que tout le traitement soit contenu dans l'objet, et tu conclus qu'il faut une méthode par programme à piper.
Si tu veux faire un cut, tu n'as pas besoin d'une méthode qui te renvoie des champs. Tu as juste besoin d'une méthode read_char, comme pour grep. Par contre si tu as à ta disposition une méthode qui te donne une liste de champs, c'est encore mieux.
D'un autre côté, si tu prends toujours comme exemple des commandes qui manipulent du texte, tu n'auras jamais intéret à obtenir en entrée autre chose que du texte. Ça ne devient intéressant que dans le cas de données structurées associées à leur comportement.
Ce n'est pas vrai, tout dépend de la hiérarchie de classes utilisées. Si tu dis "je reçois en entrée n'importe quel objet qui implémente les méthodes ajouter et multiplier", tu peux faire un programme qui fait des opérations sur plein de types d'objets. Mais là on n'est pas dans une discution sur l'intéret de pouvoir piper des objets, on est dans une discution sur les mérites de la programmation objet en général.
Et même si chaque objet était spécifique, admettons que dans un script shell j'aie besoin de prendre une date et d'ajouter trois jours à cette date. Dans le bon vieux modèle Unix, je pourrais piper le résultat de "date" dans mon script, le parser, et ensuite écrire un algo qui ajoute trois jours, et qui change de mois/année quand c'est nécessaire. Dans un modèle objet, ça donnerait ça:
d = lire_une_date_en_entrée();
d2 = d+3;
À condition que la méthode Date::+ soit fournie par l'objet. C'est du code spécifique à l'objet Date, mais ça va tout à fait dans l'esprit de réutilisation de code, puisque c'est disponible pour tous les programmes qui veulent manipuler des dates.
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal Langages pour desktop. Évalué à 5.
f = Fonction.parse("3x²+4x+6")
f'' = Fonction.parse( (Fonction.parse(f.dérivée).dérivée )
Tout le monde sera d'accord pour dire que ce n'est pas très efficace: la méthode dérivée est obligée de convertir sa valeur de retour en chaîne de caractères, et après on est obligé de parser à nouveau pour avoir une fonction. Il serait bien plus simple de manipuler les objets sans passer par des chaines:
f = Fonction.parse("3x²+4x+6")
f'' = f.dérivée.dérivée
Dans cette analogie, le premier langage c'est les commandes Unix et la communication par flux. Comme tu ne peux pas échanger des objets, tu dois te taper les conversions de données à chaque fois.
Maintenant, pour en venir à ton objection:
Je te répondrais que ce n'est pas vrai dans l'analogie des langages de programmation, et que ce n'est pas vrai non plus dans le cas de programmes qui communiquent avec des objets. Pourquoi ? Parce que si on peut emboîter des objets dans un langage objet, on peut aussi emboiter des programmes qui manipulent des objets.
Typiquement, un programme Grep n'est applicable qu'à des objets contenant des chaînes de texte. Donc, le programme Grep serait défini comme recevant en entrée des objets implémentant la méthode read_char, et c'est tout ce qui est nécessaire, pas besoin de coder un grep dans l'objet lui même. Dans ce cas, l'objet reçu en entrée est en pratique un flux, comme dans le bon vieux Unix, parce que par définition Grep fonctionne sur des flux.
Maintenant si on prend un programme qui manipule autre chose que des flux, par exemple des dates, on a intéret à pouvoir lire en entrée directement un objet Date avec ses méthodes day, week, year, etc.
Pour prendre un exemple idiot, qui ne s'est jamais énervé sur son script shell qui ne donnait pas de bons résultats, simplement parce qu'on a donné en entrée un nombre décimal comme "3.14", alors que dans la locale fr, awk considère que le séparateur est une virgule, et qu'il fallait entrer "3,14" ?
# Ça a l'air bien
Posté par Yusei (Mastodon) . En réponse au journal Les systèmes bases de données orientées objets. Évalué à 9.
[^] # Re: ...
Posté par Yusei (Mastodon) . En réponse au journal Langages pour desktop. Évalué à 4.
N'importe quoi... dans les deux cas, si tu ne sais pas ce que tu reçois, tu ne peux pas le traiter, et le XML n'est pas une solution magique. Il s'agit d'un format standardisé, mais tu as toujours besoin de savoir comment manipuler ce qui est contenu dedans.
Opposer les échanges d'objets et les échanges de XML, c'est très étrange. On peut très bien échanger des objets en utilisant le format XML, par exemple. Bref, choisir le format (XML) c'est bien, mais il faut encore choisir le protocole (objets sérialisés, données brutes, ...)