Hummm, j'essayais plutôt de parler d'un [i]regroupement[/i] de scripts de ce genre, et même de faire en sorte d'en construire un "plus gros" à partir d'autres "plus petit" à la souris.
Si je sais que je dois faire cette opération, télécharger ou écrire un script pour le faire, c'est cool, mais si ce que j'ai besoin de faire n'est (presque) jamais la même chose ?
Ooooo-kay, manifestement, j'ai été aussi clair que le fond de la console, dans ce journal ;).
Certes, la ligne de commande a (au moins) l'avantage que je viens d'exposer par rapport au GUI-based. Ce que je dis, c'est que ce n'est pas une nécessité, et qu'on doit pouvoir faire quelque chose pour s'en passer une bonne fois pour toutes (pour ceux qui veulent, s'entend.)
En gros, sélectionner un dossier, faire un "clic droit->traitement auto..." qui m'affiche une nolie fenêtre contenant :
- un résumé de ce que j'ai sélectionné (fichier seul, ensemble de fichiers, dossiers, mélange dossiers/fichiers...)
- une présentation du traitement automatisé que je suis en train de demander (au début rien, ou alors, une représentation de boucle "pour tout élément du dossier, faire...")
- un système de sélection d'opérations que je peux demander (genre menu K)
- et probablement d'autres trucs qui simplifie la compréhension de la chose.
Ou n'importe quoi qui serve le même but ;). Je suis sûr que c'est faisable. Ça demande juste de l'imagination, à mon avis.
Moui, enfin, j'attends encore les GNU threads ;). Quoique, on peut peut-être considérer la NPTL comme ça ?
Plus sérieusement, j'avais oublié ces histoires de format de réponse. Effectivement, ça c'est un défaut. Pas si grave, puisque justement on commence à vouloir une GUI dès que possible, mais quand même. D'un autre côté, je peux pas affirmer avec beaucoup d'applomb que les dernières révisions de POSIX ne modifient pas les sorties attendues des commandes courantes. Qu'en est-il ?
(Et les "nostalgiques," c'est vraissemblablement des gens qui se sont chéfié pendant des jours pour faire un shell script...)
Moi aussi, et j'aime beaucoup ce que tu dis. Une fois n'est pas coutume, j'ai envie de répondre.
>Vous trouvez vraiment que cet OS, que beaucoup veulent voir se répandre à la place de la concurrence, est vraiment à même d'être utiliser par vos parents ? Je ne parle pas des grands-parents qui n'ont jamais osé approcher un appareil électrique, mais bien de ces parents qui sont encore dans le monde du travail et qui doivent composer tant bien que mal avec l'informatique.
Oui et non. Les gens dont tu parles sont certes bien incapable d'installer, maintenir ou mettre à jour un système GNU/Linux quel qu'il soit, mais il en va exactement de même avec un système windows ou MacOS. D'accord, faire ce genre de chose est plus facile avec windows ou MacOS, mais pour les personnes dont tu parles, c'est du pareil au même.
> En effet, nous sommes toujours coincé avec une norme vieillote et poussiéreuse : POSIX. Cette norme était parfaitement adaptée à la ligne de commande sur les serveurs mode texte. Tout y est pensé et orienté shell (même les appels systèmes fork et exec le reflètent). D'accord, c'était le ce dont ce genre de machines avaient besoin. Or, nous avons évolué depuis ! Il y a eu l'USB, le réseau, les modes graphiques, les cartes 3D, ...
Je ne comprends pas. Il ne s'agit là que de conformances système d'assez bas niveau. Rien n'empêche des couches d'abstraction pour faire plus. Que les développeurs doivent évoluer, je veux bien, mais le système, rien ne le justifie à ce que tu dis. Spécialement pour les périphériques : c'est quoi, le rapport ?
> D'accord, Linux a suivi cette évolution tant bien que mal en utilisant des solutions ad-hoc, mais est-ce vraiment une bonne solution de ne trouver que "juste" une solution ? Ne sommes-nous pas tout simplement coincés dans cette façon de voir les choses, juste parce que nous les avons acceptées et y sommes habitués ?
C'est possible. D'un autre côté, tant qu'on en trouve pas un défaut à POSIX, c'est que POSIX n'a pas de défaut. En fait, je peux en trouver, mais ça passe bien au-dessus des cas simples que tu présentes.
POSIX ne spécifie pas tout, mais n'empêche pas de spécifier en plus. Un paquet de trucs ne dépendent pas de POSIX dans un système qui l'implémente. Par exemple, MacOS n'en était pas loin la dernière fois que j'ai regardé. Maintenant, il l'est peut-être complètement ?
> Que penser d'un mouvement comme GNU qui encourage officiellement la liberté (à l'excès) et en pratique nous enferme dans la boîte POSIX en la déclarant condition sine qua non pour appartenir officiellement au projet GNU ?
Nieh ? GNU's Not Unix. Tu es absolument sûr de ce que tu affirmes ? C'est juste que des gens qui ont spécifié et implémenté autre chose que du POSIX, il y en a pas des masses. D'ailleurs, ce serait juste "histoire d'avoir le choix," car il n'y a aucune raison de changer de conformance.
> Certes, la ligne de commande a eu son temps, [...] mais n'est-il pas temps d'avancer au lieu de s'empoussièrer ?
Bien d'accord. Te gêne pas, prends ton plus bel IDE et code ! Moi aussi, je suis un amoureux des clicodrômes, et je travaille à me passer définitivement de cette horreur en 80x25. C'est pas simple, il y a énormément à faire, mais ça se fait. Le plus dur étant de trouver exactement ce qu'il y a à faire.
>Quelques zones sont encore très poussièreuses dans le monde du logiciel libre. En vrac :
- les pages man et info comme standard alors que des solutions alternativent, reconnues, efficaces et utilisables existent : XML, XSL, Docbook, etc.
Il ne s'agit que d'un standard de fait. Il n'y a aucune spécification à changer, seulement une attitude des documenteurs. Et encore, un outils en ligne de commande, c'est normal de lire comment il marche en ligne de commande : il y a bien une raison pour laquelle tu n'utilises pas un outils graphique (idéalement, j'entends.)
> - l'arborescence de répertoires unique alors qu'elle est la cause de la complexité du processus de bootstrapping du noyau linux (regardez un peu la simplicité de ce processus pour AmigaOS ou même Windows)
Manifestement, je ne comprends pas ce que tu appelles bootstrapping.
De plus, sous windows, il y a une arborescence unique : la racine étant le bureau. Rien n'empêche de faire un truc du même genre sous linux, mais je vois pas à quoi ça servirait. Et toi ?
Eventuellement, tu exposes peut-être un problème sur le fait que l'arborescence d'un périphérique de stockage contienne celle d'un autre ?
>- le "tout fichier" qui est une forme d'intégrisme intellectuel pour les programmeurs. Il a fallu mettre en place des emplâtres pour arriver à accéder aux périphériques USB, réseau, framebuffer, ...
Rien à voir. Qui dit information et système de repérage de cette information dit équivalence avec base de données, et avec système de fichier. Que ça soit mal fichu ensuite, qu'on ait pas de surcouche pratique pour s'en servir, ou qu'elle soit méconnue, c'est une autre question.
>- la gestion des pilotes de périphériques dynamique uniquement sur le papier mais pas en pratique. Elle est loin d'être aussi simple à utiliser que sous d'autres OS concurrents.
Certes. Mais POSIX n'y est pour rien, les pipes n'y sont pour rien, le tout fichier n'y est pour rien. C'est ce qu'on a toujours fait pour l'implémenter qui pèche, et on est en train de s'en sortir. Par exemple, il ne manque que peu de chose à udev pour permettre d'en écrire une surcouche avec une belle GUI qui va aider à tout bien repérer branchement et débranchement de périphérique.
Et encore, des gars plus calés que moi essaient en ce moment même de m'expliquer que c'est déjà possible, et comment.
>- le nombre de tâche d'utilisation quotidienne qui doivent être réalisée "à l'ancienne", à l'aide d'un shell et d'un grimoire indiquant dans quels sombres recoins secrets se trouve la formule magique permettant de réaliser telle ou telle chose.
Pas pour un utilisateur lambda. Je n'ai aucunement besoin de cette chose pour me connecter à internet, naviguer, faire du travail de bureautique, de la base de données, du dessin... Je sors mon kterm quand je dois développer, mettre à jour ou installer. Si ce n'est pas ton cas, c'est ta distrib', ou toi, qui pèche.
>Et il y en a encore bien d'autres comme la guerre des formats de packages, des toolkits graphiques, des langages, des distributions, ...
Pas pareil. On cultive la diversité, qu'on le veuille ou non. Ca pose des difficultés, mais des difficultés voulues. Si tu veux pas de diversité, ça fait déjà une sérieuse raison de moins de t'intéresser aux logiciels libres. A quoi bon pouvoir modifier quelque chose alors que tout le monde ne prend pas cette modification, créant ainsi de la diversité ?
>Attention, je ne parle de pas de tout jeter au feu et de tout recommencer à zéro en colportant le mythe insidieux du totally rewritten des logiciels et des normes, autant que ne je pousse pas la poursuite à tout prix de la vague des technologies in au détriment de celles qui ont fait leurs preuves. Je parle juste de sagesse, de regard critique, le tout agrémenté d'un zeste d'humilité.
Tout à fait d'accord, mais j'ai pas l'impression que tu aies vraiment creusé là où ça pèche.
>En bref : Réfléchissons et avançons !
Ce qui est marrant, c'est que je suis d'accord quand tu dis que tout ne va pas pour le mieux dans le meilleur des mondes, je suis d'accord quand tu dis qu'il faut faire évoluer certaines visions des choses, simplement aucun de tes exemples ne me convient.
Moi ce que je crois, c'est qu'on manque d'experts en IHM, et de gens voulant les implémenter.
Je crois aussi qu'il faudrait avoir moins peur de prévoir des fonctions spécifiques à côté des fonctions génériques. Par exemple, ce n'est pas parce qu'un fichier POSIX n'a pas d'attribut "invisible" que les navigateurs de fichier tournant sur un système POSIX ne doivent pas fournir une interface vers cet attribut, lorsqu'il est géré par le système de fichier (non, je ne parle pas que de vgros.)
Je crois encore que les programmes exécutables réimplémentent trop souvent la roue en interne au lieu d'utiliser la libroue.so qui fonctionne si bien, ou de transformer leur réimplémentation en libbouee.so indépendant pour que ça serve à d'autres.
Je crois enfin que la liaison dynamique au chargement du programme devrait laisser un peu de place au dlopen, histoire qu'il ne soit pas nécessaire d'installer la libultrascreenshot pour regarder une vidéo... En attendant que ça s'arrange, j'utilise Gentoo et je joue avec $USE.
Mais j'ai des doutes concernant la mauvaise conception du système de base. Il ne se suffit pas, mais il n'a que peu de problèmes, pas spécialement bloquants.
Je m'étais toujours imaginé que le jour où j'en aurais besoin, je ferais faire la résolution de nom directement par la (ou une des) machine(s) serveur qui aurait un nom.
Mais c'est pas forcément trivial, maintenant que j'y pense.
Ca y est, je viens de comprendre (enfin je crois, mais au moins je suis plus surpris.) J'étais complètement à côté de la plaque.
J'aimerais bien qu'on éclaire ma lanterne sur l'utilité de la chose avec l'IPv4, mais je suppose que pour les enregistrements IPv6, ça doit être la méthode la plus fiable. (appel au détrompage)
C'est là que tout le monde va voir que je suis un ptit newbie, mais j'ai bien compris de quoi il est question, là ?
L'hébergement DNS, ça consiste pas à faire en sorte qu'à un nom soit associé son adresse IP ? (et autres, oui, je sais)
Genre si je me prenais une IP fixe chez free, xname.org me permettrais d'associer mayeul.marguet.fr à cette IP rien qu'en leur faisant mon plus beau sourire ?
Si ce genre de choses est possible, c'est que je n'ai manifestement rien compris au fonctionnement 'administratif' de la résolution de nom sur internet.
(Je vais me sentir bien ridicule pendant quelques semaines, mais au moins je ne serai plus ignorant...)
Mis à part "coup de gueule anti-connard" je ne vois aucune raison de moinsser.
Simplement, tu reproches quoi à qui, là ? :)
- Aux gens qui font du FUD d'en faire ?
- A ceux qui attaquent les sociétés qui font du FUD de pas les ignorer tout simplement ?
- Aux gens de penser qu'au fric ?
- Aux gens de pas vouloir se fatiguer ?
- Aux gens de pas être parfait ?8br />
- Au déplaisir d'exister ?
- A la vie d'exister ?
[^] # Re: Peut-on traiter 500 fichiers en 8 clics ?
Posté par Miair Patreau . En réponse au journal Peut-on traiter 500 fichiers en 8 clics ?. Évalué à 1.
Si je sais que je dois faire cette opération, télécharger ou écrire un script pour le faire, c'est cool, mais si ce que j'ai besoin de faire n'est (presque) jamais la même chose ?
[^] # Re: Peut-on traiter 500 fichiers en 8 clics ?
Posté par Miair Patreau . En réponse au journal Peut-on traiter 500 fichiers en 8 clics ?. Évalué à 1.
Certes, la ligne de commande a (au moins) l'avantage que je viens d'exposer par rapport au GUI-based. Ce que je dis, c'est que ce n'est pas une nécessité, et qu'on doit pouvoir faire quelque chose pour s'en passer une bonne fois pour toutes (pour ceux qui veulent, s'entend.)
En gros, sélectionner un dossier, faire un "clic droit->traitement auto..." qui m'affiche une nolie fenêtre contenant :
- un résumé de ce que j'ai sélectionné (fichier seul, ensemble de fichiers, dossiers, mélange dossiers/fichiers...)
- une présentation du traitement automatisé que je suis en train de demander (au début rien, ou alors, une représentation de boucle "pour tout élément du dossier, faire...")
- un système de sélection d'opérations que je peux demander (genre menu K)
- et probablement d'autres trucs qui simplifie la compréhension de la chose.
Ou n'importe quoi qui serve le même but ;). Je suis sûr que c'est faisable. Ça demande juste de l'imagination, à mon avis.
[^] # Re: Demo 4Ko!
Posté par Miair Patreau . En réponse au journal Demo 4Ko!. Évalué à 1.
[^] # Re: Le logiciel qui me manque sous Linux (ou le(s) logiciel(s) existant ne me plait pas)
Posté par Miair Patreau . En réponse au sondage Le logiciel qui me manque sous Linux (ou le(s) logiciel(s) existant ne me plait pas). Évalué à 1.
Plus sérieusement, j'avais oublié ces histoires de format de réponse. Effectivement, ça c'est un défaut. Pas si grave, puisque justement on commence à vouloir une GUI dès que possible, mais quand même. D'un autre côté, je peux pas affirmer avec beaucoup d'applomb que les dernières révisions de POSIX ne modifient pas les sorties attendues des commandes courantes. Qu'en est-il ?
(Et les "nostalgiques," c'est vraissemblablement des gens qui se sont chéfié pendant des jours pour faire un shell script...)
[^] # Re: Le logiciel qui me manque sous Linux (ou le(s) logiciel(s) existant ne me plait pas)
Posté par Miair Patreau . En réponse au sondage Le logiciel qui me manque sous Linux (ou le(s) logiciel(s) existant ne me plait pas). Évalué à 4.
Moi aussi, et j'aime beaucoup ce que tu dis. Une fois n'est pas coutume, j'ai envie de répondre.
>Vous trouvez vraiment que cet OS, que beaucoup veulent voir se répandre à la place de la concurrence, est vraiment à même d'être utiliser par vos parents ? Je ne parle pas des grands-parents qui n'ont jamais osé approcher un appareil électrique, mais bien de ces parents qui sont encore dans le monde du travail et qui doivent composer tant bien que mal avec l'informatique.
Oui et non. Les gens dont tu parles sont certes bien incapable d'installer, maintenir ou mettre à jour un système GNU/Linux quel qu'il soit, mais il en va exactement de même avec un système windows ou MacOS. D'accord, faire ce genre de chose est plus facile avec windows ou MacOS, mais pour les personnes dont tu parles, c'est du pareil au même.
> En effet, nous sommes toujours coincé avec une norme vieillote et poussiéreuse : POSIX. Cette norme était parfaitement adaptée à la ligne de commande sur les serveurs mode texte. Tout y est pensé et orienté shell (même les appels systèmes fork et exec le reflètent). D'accord, c'était le ce dont ce genre de machines avaient besoin. Or, nous avons évolué depuis ! Il y a eu l'USB, le réseau, les modes graphiques, les cartes 3D, ...
Je ne comprends pas. Il ne s'agit là que de conformances système d'assez bas niveau. Rien n'empêche des couches d'abstraction pour faire plus. Que les développeurs doivent évoluer, je veux bien, mais le système, rien ne le justifie à ce que tu dis. Spécialement pour les périphériques : c'est quoi, le rapport ?
> D'accord, Linux a suivi cette évolution tant bien que mal en utilisant des solutions ad-hoc, mais est-ce vraiment une bonne solution de ne trouver que "juste" une solution ? Ne sommes-nous pas tout simplement coincés dans cette façon de voir les choses, juste parce que nous les avons acceptées et y sommes habitués ?
C'est possible. D'un autre côté, tant qu'on en trouve pas un défaut à POSIX, c'est que POSIX n'a pas de défaut. En fait, je peux en trouver, mais ça passe bien au-dessus des cas simples que tu présentes.
POSIX ne spécifie pas tout, mais n'empêche pas de spécifier en plus. Un paquet de trucs ne dépendent pas de POSIX dans un système qui l'implémente. Par exemple, MacOS n'en était pas loin la dernière fois que j'ai regardé. Maintenant, il l'est peut-être complètement ?
> Que penser d'un mouvement comme GNU qui encourage officiellement la liberté (à l'excès) et en pratique nous enferme dans la boîte POSIX en la déclarant condition sine qua non pour appartenir officiellement au projet GNU ?
Nieh ? GNU's Not Unix. Tu es absolument sûr de ce que tu affirmes ? C'est juste que des gens qui ont spécifié et implémenté autre chose que du POSIX, il y en a pas des masses. D'ailleurs, ce serait juste "histoire d'avoir le choix," car il n'y a aucune raison de changer de conformance.
> Certes, la ligne de commande a eu son temps, [...] mais n'est-il pas temps d'avancer au lieu de s'empoussièrer ?
Bien d'accord. Te gêne pas, prends ton plus bel IDE et code ! Moi aussi, je suis un amoureux des clicodrômes, et je travaille à me passer définitivement de cette horreur en 80x25. C'est pas simple, il y a énormément à faire, mais ça se fait. Le plus dur étant de trouver exactement ce qu'il y a à faire.
>Quelques zones sont encore très poussièreuses dans le monde du logiciel libre. En vrac :
- les pages man et info comme standard alors que des solutions alternativent, reconnues, efficaces et utilisables existent : XML, XSL, Docbook, etc.
Il ne s'agit que d'un standard de fait. Il n'y a aucune spécification à changer, seulement une attitude des documenteurs. Et encore, un outils en ligne de commande, c'est normal de lire comment il marche en ligne de commande : il y a bien une raison pour laquelle tu n'utilises pas un outils graphique (idéalement, j'entends.)
> - l'arborescence de répertoires unique alors qu'elle est la cause de la complexité du processus de bootstrapping du noyau linux (regardez un peu la simplicité de ce processus pour AmigaOS ou même Windows)
Manifestement, je ne comprends pas ce que tu appelles bootstrapping.
De plus, sous windows, il y a une arborescence unique : la racine étant le bureau. Rien n'empêche de faire un truc du même genre sous linux, mais je vois pas à quoi ça servirait. Et toi ?
Eventuellement, tu exposes peut-être un problème sur le fait que l'arborescence d'un périphérique de stockage contienne celle d'un autre ?
>- le "tout fichier" qui est une forme d'intégrisme intellectuel pour les programmeurs. Il a fallu mettre en place des emplâtres pour arriver à accéder aux périphériques USB, réseau, framebuffer, ...
Rien à voir. Qui dit information et système de repérage de cette information dit équivalence avec base de données, et avec système de fichier. Que ça soit mal fichu ensuite, qu'on ait pas de surcouche pratique pour s'en servir, ou qu'elle soit méconnue, c'est une autre question.
>- la gestion des pilotes de périphériques dynamique uniquement sur le papier mais pas en pratique. Elle est loin d'être aussi simple à utiliser que sous d'autres OS concurrents.
Certes. Mais POSIX n'y est pour rien, les pipes n'y sont pour rien, le tout fichier n'y est pour rien. C'est ce qu'on a toujours fait pour l'implémenter qui pèche, et on est en train de s'en sortir. Par exemple, il ne manque que peu de chose à udev pour permettre d'en écrire une surcouche avec une belle GUI qui va aider à tout bien repérer branchement et débranchement de périphérique.
Et encore, des gars plus calés que moi essaient en ce moment même de m'expliquer que c'est déjà possible, et comment.
>- le nombre de tâche d'utilisation quotidienne qui doivent être réalisée "à l'ancienne", à l'aide d'un shell et d'un grimoire indiquant dans quels sombres recoins secrets se trouve la formule magique permettant de réaliser telle ou telle chose.
Pas pour un utilisateur lambda. Je n'ai aucunement besoin de cette chose pour me connecter à internet, naviguer, faire du travail de bureautique, de la base de données, du dessin... Je sors mon kterm quand je dois développer, mettre à jour ou installer. Si ce n'est pas ton cas, c'est ta distrib', ou toi, qui pèche.
>Et il y en a encore bien d'autres comme la guerre des formats de packages, des toolkits graphiques, des langages, des distributions, ...
Pas pareil. On cultive la diversité, qu'on le veuille ou non. Ca pose des difficultés, mais des difficultés voulues. Si tu veux pas de diversité, ça fait déjà une sérieuse raison de moins de t'intéresser aux logiciels libres. A quoi bon pouvoir modifier quelque chose alors que tout le monde ne prend pas cette modification, créant ainsi de la diversité ?
>Attention, je ne parle de pas de tout jeter au feu et de tout recommencer à zéro en colportant le mythe insidieux du totally rewritten des logiciels et des normes, autant que ne je pousse pas la poursuite à tout prix de la vague des technologies in au détriment de celles qui ont fait leurs preuves. Je parle juste de sagesse, de regard critique, le tout agrémenté d'un zeste d'humilité.
Tout à fait d'accord, mais j'ai pas l'impression que tu aies vraiment creusé là où ça pèche.
>En bref : Réfléchissons et avançons !
Ce qui est marrant, c'est que je suis d'accord quand tu dis que tout ne va pas pour le mieux dans le meilleur des mondes, je suis d'accord quand tu dis qu'il faut faire évoluer certaines visions des choses, simplement aucun de tes exemples ne me convient.
Moi ce que je crois, c'est qu'on manque d'experts en IHM, et de gens voulant les implémenter.
Je crois aussi qu'il faudrait avoir moins peur de prévoir des fonctions spécifiques à côté des fonctions génériques. Par exemple, ce n'est pas parce qu'un fichier POSIX n'a pas d'attribut "invisible" que les navigateurs de fichier tournant sur un système POSIX ne doivent pas fournir une interface vers cet attribut, lorsqu'il est géré par le système de fichier (non, je ne parle pas que de vgros.)
Je crois encore que les programmes exécutables réimplémentent trop souvent la roue en interne au lieu d'utiliser la libroue.so qui fonctionne si bien, ou de transformer leur réimplémentation en libbouee.so indépendant pour que ça serve à d'autres.
Je crois enfin que la liaison dynamique au chargement du programme devrait laisser un peu de place au dlopen, histoire qu'il ne soit pas nécessaire d'installer la libultrascreenshot pour regarder une vidéo... En attendant que ça s'arrange, j'utilise Gentoo et je joue avec $USE.
Mais j'ai des doutes concernant la mauvaise conception du système de base. Il ne se suffit pas, mais il n'a que peu de problèmes, pas spécialement bloquants.
[^] # Re: Le Sagem Fast 800 bientot supporté par *BSD !
Posté par Miair Patreau . En réponse à la dépêche Le Sagem Fast 800 bientôt supporté par *BSD !. Évalué à 1.
[^] # Re: Hébergement DNS IPv6 gratuit
Posté par Miair Patreau . En réponse à la dépêche Hébergement DNS IPv6 gratuit. Évalué à -1.
[^] # Re: Hébergement DNS IPv6 gratuit
Posté par Miair Patreau . En réponse à la dépêche Hébergement DNS IPv6 gratuit. Évalué à 1.
Merci pour l'explication.
Je m'étais toujours imaginé que le jour où j'en aurais besoin, je ferais faire la résolution de nom directement par la (ou une des) machine(s) serveur qui aurait un nom.
Mais c'est pas forcément trivial, maintenant que j'y pense.
[^] # Re: Hébergement DNS IPv6 gratuit
Posté par Miair Patreau . En réponse à la dépêche Hébergement DNS IPv6 gratuit. Évalué à -1.
Ca y est, je viens de comprendre (enfin je crois, mais au moins je suis plus surpris.) J'étais complètement à côté de la plaque.
J'aimerais bien qu'on éclaire ma lanterne sur l'utilité de la chose avec l'IPv4, mais je suppose que pour les enregistrements IPv6, ça doit être la méthode la plus fiable. (appel au détrompage)
[^] # Re: Hébergement DNS IPv6 gratuit
Posté par Miair Patreau . En réponse à la dépêche Hébergement DNS IPv6 gratuit. Évalué à 5.
L'hébergement DNS, ça consiste pas à faire en sorte qu'à un nom soit associé son adresse IP ? (et autres, oui, je sais)
Genre si je me prenais une IP fixe chez free, xname.org me permettrais d'associer mayeul.marguet.fr à cette IP rien qu'en leur faisant mon plus beau sourire ?
Si ce genre de choses est possible, c'est que je n'ai manifestement rien compris au fonctionnement 'administratif' de la résolution de nom sur internet.
(Je vais me sentir bien ridicule pendant quelques semaines, mais au moins je ne serai plus ignorant...)
[^] # Re: amende pour SCO pour propos "mensongers"
Posté par Miair Patreau . En réponse à la dépêche Amende pour SCO pour propos "mensongers". Évalué à 1.
Simplement, tu reproches quoi à qui, là ? :)
- Aux gens qui font du FUD d'en faire ?
- A ceux qui attaquent les sociétés qui font du FUD de pas les ignorer tout simplement ?
- Aux gens de penser qu'au fric ?
- Aux gens de pas vouloir se fatiguer ?
- Aux gens de pas être parfait ?8br /> - Au déplaisir d'exister ?
- A la vie d'exister ?
Bref, précise :)
[^] # Re: Microsoft condamné pour utilisation de techniques brevetées dans Internet Explorer
Posté par Miair Patreau . En réponse à la dépêche Microsoft condamné pour utilisation de techniques brevetées dans Internet Explorer. Évalué à 4.
Si le brevet va dans un cimetière quelconque, retirez le brevet de la partie.
[^] # Yes !! Je suis une exception ! :)
Posté par Miair Patreau . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à 0.
[^] # Re: Mon troll préféré :
Posté par Miair Patreau . En réponse au sondage Mon troll préféré :. Évalué à 2.
[^] # Re: Mon troll préféré :
Posté par Miair Patreau . En réponse au sondage Mon troll préféré :. Évalué à 1.
Ca fait partie de mes principes ;).
# Re: Mon troll préféré :
Posté par Miair Patreau . En réponse au sondage Mon troll préféré :. Évalué à 1.
On est pourtant tous d'accords pour dire que GNOME n'est qu'une pâle imitation d'environnement de bureau écrite en C, un peu comme WindowMaker, non ?
:-D