C'est censé être nouveau ? J'ai ça dans Iceweasel 30, et il s'agit de la fenêtre de préférences du navigateur, seulement intégrée dans un onglet au lieu d'être détachée.
À noter que tout cela s'applique à un service particulier, le Web, et que cette complexité n'est rendu nécessaire que par un défaut de conception du protocole HTTP et son incapacité à évoluer.
Ainsi, avec d'autres services qui bénéficient protocoles plus moderne à ce regard, tels que SMTP ou XMPP, la disponibilité peut être améliorée de façon infiniment plus simple, en installant simplement un second serveur, en faisant ce qu'il faut pour qu'il collabore avec le premier, et en publiant un simple enregistrement DNS (MX ou SRV) qui indique ce serveur secondaire. Pas besoin de répartiteur de charge, et surtout pas de SPoF lié à ce répartiteur, ce qui permet de faire de la vraie redondance instantanée sur toute la chaîne, ce qui est à peu près infaisable pour le Web.
Je pensais a installer les dépendances pour mon programme (automatiser la tâche),
car si l'utilisateur cible clique ou exécute (dpkg -i) mon paquetage *.deb il peut soit:
-) avoir installer les dépendances tout seule dans ce cas pas de soucis mon script teste si les paquets sont installé avant l'appel a apt-get.
-) Exécuter bêtement le paquet afin d'installer le programme et dans ce cas le test et l'installation sont utile (sous condition d'une connexion internet et disponibilité de apt-get).
Et que faire si ce n'est pas le cas car le programme ne peut pas fonctionner sans ses paquets.
Fait ça au postinst est une horreur, ce n'est pas du tout le rôle d'un script de post-installation. Il y a dans les infos du paquet un champ de dépendances, qui est là pour ça.
Je doit créer un dossier cacher dans le $HOME de l'utilisateur pour les ressources de mon programme et ça a été un vrai calvaire de créer un paquetage valide car:
Car c'est une pratique horrible également de faire ça par le paquet : un paquet ne doit pas toucher aux répertoires personnels, mais seulement aux répertoires système. L'ajout de répertoires ou de fichiers dans le répertoire personnel de l'utilisateur, c'est au logiciel de le faire, au premier lancement.
Heureusement que l'on peut exécuter un script…
Argh. Jamais un paquet comme ça ne serait admis dans Debian.
Je trouve simplement que lintian est trop stricte et il est vrai que les paquetage se doivent d'être de qualité contrôler
Lintian est strict pour faire respecter des conventions de qualité, que tu cherches à contourner. Il n'est pas étonnant que tu aies du mal. Tu es dans le cas typique du proverbe « les bons développeurs sont de mauvais empaqueteurs » : développeur, tu aimes coder, mais pas empaqueter, tout simplement.
Notez qu'il y existe d'excellentes raisons de coder pour Bash, parce que tous les bashismes n'ont pas d'équivalent directs. Parfois, un bashisme ne peut être remplacé que par une série d'appels externes, qui sont plus coûteux que d'appeler Bash pour faire tout ça. Mais ce n'est pas souvent le cas, et la plupart des bashismes n'ont aucune raison d'être. Sans compter les scripts qui ne comportent déjà aucun bashisme !
Ok pas de souci, c'était plus pour te faire réagir : traiter de fainéant les personnes qui n'ont pas d'intérêt pour un sujet, c'est les braquer la plupart du temps au lieu de faire naître cet intérêt chez elles.
En fait ce ne sont pas les personnes qui sont fainéantes, c'est leur choix qui relève de la solution de facilité, ce qui est compréhensible pour un domaine qui n'a pas leur intérêt principal.
À une époque, les gens écrivaient des scripts shells sans se poser de question, et comme Bash était le shell d'exécution des scripts par défaut, ils ne se rendaient pas compte qu'ils utilisaient plein de bashismes et que leurs scripts ne fonctionnaient pas sur d'autres shells.
Puis, Ubuntu, et ensuite Debian, ont décidé d'installer Dash, un shell plus restreint et plus léger, à la place de Bash comme interpréteur des scripts par défaut. Du coup, des tas de scripts se sont trouvés ne plus fonctionner. Il y avait alors deux façons de régler ce genre de problème :
la bonne, qui consistait à traquer les bashismes, et, s'il n'y avait pas de raison majeure de les maintenir, de les remplacer par des formes standard ;
la mauvaise, consistant à ne pas se poser de question et à forcer l’interprétation par Bash.
Ça, c'était pour les scripts existants. Le problème, c'est que cette seconde solution de facilité est rentrée dans les mœurs au point que des gens ont pris l'habitude de coder leurs scripts pour Bash sans réfléchir, même en n'utilisant aucun bashisme !
Pour les nouveaux scripts, la bonne attitude consiste à coder pour sh, en évitant les bashismes évidents : si on n'a pas bien l'habitude, ça échouera à l'exécution, et avec un coup de checkbashisms on pourra voir ce qu'il faut corriger. On s'y fait rapidement, et au bout de très peu de temps on sait coder pour sh sans faire de bashismes.
Non, j'ai visiblement un peu sur-interprété ce que j'avais lu, dans le manuel de Bash d'ailleurs. Ils qualifient la forme avec des accents graves d'ancienne. Ce qui est exact, dans le sens où elle est plus ancienne que celle avec des parenthèses, qui a probablement été introduite pour faciliter l'imbrication de substitutions de commandes.
Bref, aujourd'hui on peut utiliser les deux, mais mieux vaut à mon avis utiliser la syntaxe moderne, qui n'a à ma connaissance par d'inconvénient et qui a un avantage très net pour des substitutions imbriquées, ce qui peut être utile à l'occasion.
C'est toi qui a commencé à qualifier ton script de fainéant… Bon, désolé pour la condescendance, en tout cas voici une référence à ce sujet : https://wiki.ubuntu.com/DashAsBinSh
En gros, les bashismes les plus fréquents dans les scripts, remplaçables par des fonctions standards, sont :
[[ … ]] pour les tests : utiliser [ … ] à la place ;
function FUNCNAME pour définir des fonctions : utiliser FUNCNAME() à la place ;
source LIBRARY : utiliser . LIBRARY à la place.
Et quelques bashismes qui ne sont pas remplaçables de façon simple :
certaines formes de développement de variables, par exemple ${VAR/pattern/replacement}, qu'on peut souvent remplacer par plusieurs remplacements de fin et de début ;
certains tests, notamment [[ CHAINE == MOTIF ]], qu'on peut remplacer par un appel à grep, mais c'est justement là un cas où il est probablement plus efficace de garder Bash ;
$RANDOM, qu'on peut remplacer par des trucs pas franchement triviaux, mais c'est également un cas où il peut être pertinent de garder Bash.
Au passage, notez que pour les tests avec la commande test, alias [ … ], les combinaisons intégrées sont marquées caduques par POSIX, et qu'il faut utiliser les combinaisons externes && et || à la place. Soit, au lieu de :
Pourquoi déverrouiller ? S'ils vérifient qu'il s'allume, il est inutile de le débloquer, il suffit de montrer qu'il démarre, puis de l'éteindre sans l'avoir déverrouillé.
J'ai fait pour mon besoin un script bash de fainéant
C'est le cas de le dire : je suis heureux de t'apprendre que tu n'as utilisé aucune fonctionnalité spécifique à Bash, et que ton script est tout à fait utilisable avec n'importe quel shell standard. Tu peux mettre #! /bin/sh en tête.
Ah, et juste une remarque, pour les substitutions de commandes la syntaxe avec des accents graves est caduque, mieux vaut utiliser $(…) qui facilite l'écriture de doubles substitutions quand on en a besoin.
ou des tests avec des doubles crochets pour matcher une chaîne avec un pattern (la liste est longue)
Ça, c'est une bonne raison. Quand on en a besoin, ce qui n'est pas toujours le cas.
Je n'ai jamais dit qu'il était inutile de coder pour Bash, mais seulement que, lorsqu'on n'a pas besoin de ses fonctionnalités spécifiques, forcer l'utilisation de Bash plutôt que de cibler n'importe quel shell standard était surtout une marque de fainéantise.
Ça dépend, mais généralement oui. C'est notamment le cas d'Ubuntu : quand un paquet est envoyé dans Debia, il finit par arriver dans la version suivante d'Ubuntu.
Un script shell. Il est totalement inutile de forcer l'utilisation de Bash pour des choses aussi simples, et utiliser Bash par défaut parce qu'on n'est pas sûr de faire du code portable, c'est une solution de fainéant.
Il est possible que des distributions non issues de Debian utilisent ce format de paquet, mais ça doit être un peu rare tout de même. Pour les dérivées donc :
À noter que si j'aime bien l'idée de liens symboliques qui permettent une utilisation transparente même hors de Photoshow, la même fonctionnalité serait obtenue par un fichier par mot-clef, listant les photos marquées avec ce mot-clef.
Pour être plus précis, une photo marquée par exemple « bourré » pourrait être liée dans un répertoire tags/bourré, et, à son emplacement original, être accompagnée d'un fichier .tags contenant la liste des mots-clefs avec lesquels elle a été marquée, ici « bourré » donc :
Une idée de fonctionnalité : le possibilité de définir des étiquettes (tags) pour les photos. Ça peut être mis en œuvre par des liens symboliques je pense.
C'est une vieille technique ça, un collègue m'avait parlé d'une boutique dans un genre de bazar en Asie, où le vendeur demandait au client ce qu'il voulait comme clef USB, puis allait dans son arrière boutique programmer une clef USB de faible capacité pour se faire passer pour la taille demandée…
C'est vrai, en fait dans le processus d'attribution de ces nouveaux TLD privés, il y a une étape où on vérifie qu'ils ne posent pas de problème ou de confusion par rapport à l'existant, et de tels pluriels y seraient probablement recalés.
Tout à fait d'accord sur l'intérêt principal du .fr, en revanche je ne pense pas que les motifs invoqués pour justifier le .bzh soient intrinsèquement si mauvais que ça. Peu sérieux, sans le moindre doute : le .bzh n'est absolument pas nécessaire.
À mon avis, sa motivation principale est liée à une affirmation d'identité bretonne, qui n'est donc pas sérieuse techniquement parlant pour un nom de domaine de niveau supérieur — mais aucun de ces nouveaux TLD ne l'est — mais qui n'est pas intrinsèquement mauvaise : la fierté régionale qui n'implique en aucun cas une défiance nationale.
Bref, à mon avis, c'est l'attribution de nouveaux TLD privés qui est regrettable et peu justifiée, mais la volonté d'en créer un pour la Bretagne n'est pas spécialement inquiétante.
Le problème n'est pas que les vignerons sont lents, ils peuvent être très très rapides. Sauf que si qlq'un a été plus rapide qu'eux (et il y en aura sûrement), cela implique pour eux d'au mieux payer la taxe du troll qui s'est installé sur le pont qu'ils ont construit.
Non, les noms de domaine de niveau supérieur ne sont pas vendus aux enchères par l'ICANN.
En gros, c'est une grosse loterie, similaire à ces jeux télévisés "le premier appel est le gagnant": dès que les portes s'ouvriront, tout le monde se ruera et le gagnant sera l'un d'eux pris au hasard.
Non, les noms de domaine de niveau supérieur ne sont pas vendus au premier candidat qui se manifeste.
D'après les explications de l'ICANN, lorsque plusieurs candidats demandent le même nom, il y a après évaluation technique de chaque candidat une procédure de résolution du conflit, qui se termine par élection d'un seul candidat. Là, cette procédure n'a vsisiblement pas été nécessaire parce qu'il n'y avait qu'un seul candidat.
[^] # Re: Options
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Firefox sur son 31. Évalué à 4.
C'est censé être nouveau ? J'ai ça dans Iceweasel 30, et il s'agit de la fenêtre de préférences du navigateur, seulement intégrée dans un onglet au lieu d'être détachée.
# Contournement de déficiences du Web
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 10.
À noter que tout cela s'applique à un service particulier, le Web, et que cette complexité n'est rendu nécessaire que par un défaut de conception du protocole HTTP et son incapacité à évoluer.
Ainsi, avec d'autres services qui bénéficient protocoles plus moderne à ce regard, tels que SMTP ou XMPP, la disponibilité peut être améliorée de façon infiniment plus simple, en installant simplement un second serveur, en faisant ce qu'il faut pour qu'il collabore avec le premier, et en publiant un simple enregistrement DNS (MX ou SRV) qui indique ce serveur secondaire. Pas besoin de répartiteur de charge, et surtout pas de SPoF lié à ce répartiteur, ce qui permet de faire de la vraie redondance instantanée sur toute la chaîne, ce qui est à peu près infaisable pour le Web.
[^] # Re: merci pour vos réponses.
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Distributions utilisant le système de paquetage *.deb.. Évalué à 3.
Note que ce n'est pas une insulte, hein. C'est comme dire que je suis un mauvais musicien, c'est un fait et ça ne me dérange pas.
[^] # Re: merci pour vos réponses.
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Distributions utilisant le système de paquetage *.deb.. Évalué à 4.
Fait ça au postinst est une horreur, ce n'est pas du tout le rôle d'un script de post-installation. Il y a dans les infos du paquet un champ de dépendances, qui est là pour ça.
Car c'est une pratique horrible également de faire ça par le paquet : un paquet ne doit pas toucher aux répertoires personnels, mais seulement aux répertoires système. L'ajout de répertoires ou de fichiers dans le répertoire personnel de l'utilisateur, c'est au logiciel de le faire, au premier lancement.
Argh. Jamais un paquet comme ça ne serait admis dans Debian.
Lintian est strict pour faire respecter des conventions de qualité, que tu cherches à contourner. Il n'est pas étonnant que tu aies du mal. Tu es dans le cas typique du proverbe « les bons développeurs sont de mauvais empaqueteurs » : développeur, tu aimes coder, mais pas empaqueter, tout simplement.
[^] # Re: Super
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 2.
Notez qu'il y existe d'excellentes raisons de coder pour Bash, parce que tous les bashismes n'ont pas d'équivalent directs. Parfois, un bashisme ne peut être remplacé que par une série d'appels externes, qui sont plus coûteux que d'appeler Bash pour faire tout ça. Mais ce n'est pas souvent le cas, et la plupart des bashismes n'ont aucune raison d'être. Sans compter les scripts qui ne comportent déjà aucun bashisme !
[^] # Re: Super
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 2.
En fait ce ne sont pas les personnes qui sont fainéantes, c'est leur choix qui relève de la solution de facilité, ce qui est compréhensible pour un domaine qui n'a pas leur intérêt principal.
À une époque, les gens écrivaient des scripts shells sans se poser de question, et comme Bash était le shell d'exécution des scripts par défaut, ils ne se rendaient pas compte qu'ils utilisaient plein de bashismes et que leurs scripts ne fonctionnaient pas sur d'autres shells.
Puis, Ubuntu, et ensuite Debian, ont décidé d'installer Dash, un shell plus restreint et plus léger, à la place de Bash comme interpréteur des scripts par défaut. Du coup, des tas de scripts se sont trouvés ne plus fonctionner. Il y avait alors deux façons de régler ce genre de problème :
Ça, c'était pour les scripts existants. Le problème, c'est que cette seconde solution de facilité est rentrée dans les mœurs au point que des gens ont pris l'habitude de coder leurs scripts pour Bash sans réfléchir, même en n'utilisant aucun bashisme !
Pour les nouveaux scripts, la bonne attitude consiste à coder pour sh, en évitant les bashismes évidents : si on n'a pas bien l'habitude, ça échouera à l'exécution, et avec un coup de
checkbashismson pourra voir ce qu'il faut corriger. On s'y fait rapidement, et au bout de très peu de temps on sait coder pour sh sans faire de bashismes.[^] # Re: Super
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 3.
Si si, je plaide coupable, c'était condescendant et j'en suis désolé. Je sais ce que je pense quand j'écris, tout de même !
[^] # Re: Super
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 3. Dernière modification le 09 juillet 2014 à 15:57.
Non, j'ai visiblement un peu sur-interprété ce que j'avais lu, dans le manuel de Bash d'ailleurs. Ils qualifient la forme avec des accents graves d'ancienne. Ce qui est exact, dans le sens où elle est plus ancienne que celle avec des parenthèses, qui a probablement été introduite pour faciliter l'imbrication de substitutions de commandes.
Bref, aujourd'hui on peut utiliser les deux, mais mieux vaut à mon avis utiliser la syntaxe moderne, qui n'a à ma connaissance par d'inconvénient et qui a un avantage très net pour des substitutions imbriquées, ce qui peut être utile à l'occasion.
[^] # Re: Super
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 4.
C'est toi qui a commencé à qualifier ton script de fainéant… Bon, désolé pour la condescendance, en tout cas voici une référence à ce sujet : https://wiki.ubuntu.com/DashAsBinSh
En gros, les bashismes les plus fréquents dans les scripts, remplaçables par des fonctions standards, sont :
[[ … ]]pour les tests : utiliser[ … ]à la place ;function FUNCNAMEpour définir des fonctions : utiliserFUNCNAME()à la place ;source LIBRARY: utiliser. LIBRARYà la place.Et quelques bashismes qui ne sont pas remplaçables de façon simple :
${VAR/pattern/replacement}, qu'on peut souvent remplacer par plusieurs remplacements de fin et de début ;[[ CHAINE == MOTIF ]], qu'on peut remplacer par un appel à grep, mais c'est justement là un cas où il est probablement plus efficace de garder Bash ;$RANDOM, qu'on peut remplacer par des trucs pas franchement triviaux, mais c'est également un cas où il peut être pertinent de garder Bash.Au passage, notez que pour les tests avec la commande
test, alias[ … ], les combinaisons intégrées sont marquées caduques par POSIX, et qu'il faut utiliser les combinaisons externes&&et||à la place. Soit, au lieu de :utiliser :
# Déverrouiller
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Portables, tablettes, smartphones déchargés interdits dans les avions. Évalué à 6.
Pourquoi déverrouiller ? S'ils vérifient qu'il s'allume, il est inutile de le débloquer, il suffit de montrer qu'il démarre, puis de l'éteindre sans l'avoir déverrouillé.
[^] # Re: Super
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 0.
C'est le cas de le dire : je suis heureux de t'apprendre que tu n'as utilisé aucune fonctionnalité spécifique à Bash, et que ton script est tout à fait utilisable avec n'importe quel shell standard. Tu peux mettre
#! /bin/shen tête.Ah, et juste une remarque, pour les substitutions de commandes la syntaxe avec des accents graves est caduque, mieux vaut utiliser
$(…)qui facilite l'écriture de doubles substitutions quand on en a besoin.[^] # Re: Super
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 4.
Merci du bel exemple de méconnaissance du shell standard et d'utilisation inutile de Bash :
C'est pris en charge par les shells standard.
Ça aussi c'est standard (chercher “nested”).
Ça, c'est une bonne raison. Quand on en a besoin, ce qui n'est pas toujours le cas.
Je n'ai jamais dit qu'il était inutile de coder pour Bash, mais seulement que, lorsqu'on n'a pas besoin de ses fonctionnalités spécifiques, forcer l'utilisation de Bash plutôt que de cibler n'importe quel shell standard était surtout une marque de fainéantise.
[^] # Re: Dérivées de Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Distributions utilisant le système de paquetage *.deb.. Évalué à 3.
Ça dépend, mais généralement oui. C'est notamment le cas d'Ubuntu : quand un paquet est envoyé dans Debia, il finit par arriver dans la version suivante d'Ubuntu.
[^] # Re: Pas mal :)
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 5.
Ou pas : Ctrl + molette ça zoome à partir de la taille normale, donc ça fait des images floues.
[^] # Re: Super
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à -7.
Un script shell. Il est totalement inutile de forcer l'utilisation de Bash pour des choses aussi simples, et utiliser Bash par défaut parce qu'on n'est pas sûr de faire du code portable, c'est une solution de fainéant.
# Dérivées de Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Distributions utilisant le système de paquetage *.deb.. Évalué à 4.
Il est possible que des distributions non issues de Debian utilisent ce format de paquet, mais ça doit être un peu rare tout de même. Pour les dérivées donc :
https://wiki.debian.org/Derivatives/Census
https://wiki.debian.org/Derivatives
https://www.debian.org/misc/children-distros
[^] # Re: Étiquettes
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 4.
À noter que si j'aime bien l'idée de liens symboliques qui permettent une utilisation transparente même hors de Photoshow, la même fonctionnalité serait obtenue par un fichier par mot-clef, listant les photos marquées avec ce mot-clef.
[^] # Re: Étiquettes
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 3.
Pour être plus précis, une photo marquée par exemple « bourré » pourrait être liée dans un répertoire tags/bourré, et, à son emplacement original, être accompagnée d'un fichier .tags contenant la liste des mots-clefs avec lesquels elle a été marquée, ici « bourré » donc :
# Étiquettes
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Sortie de PhotoShow 3.0. Évalué à 2.
Une idée de fonctionnalité : le possibilité de définir des étiquettes (tags) pour les photos. Ça peut être mis en œuvre par des liens symboliques je pense.
# Utilité
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Remplir automatiquement et aleatoirement une clef usb avec des repertoire de mp3. Évalué à 3.
J'ai du mal à voir le cas d'usage de ce truc. À quoi cela te sert-il ?
# Vieille technique
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Arnaque cartes micro SD vicieuses. Évalué à 7.
C'est une vieille technique ça, un collègue m'avait parlé d'une boutique dans un genre de bazar en Asie, où le vendeur demandait au client ce qu'il voulait comme clef USB, puis allait dans son arrière boutique programmer une clef USB de faible capacité pour se faire passer pour la taille demandée…
[^] # Re: .vin et .wine
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Point BZH. Évalué à 3.
C'est vrai, en fait dans le processus d'attribution de ces nouveaux TLD privés, il y a une étape où on vérifie qu'ils ne posent pas de problème ou de confusion par rapport à l'existant, et de tels pluriels y seraient probablement recalés.
[^] # Re: intérêt?
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Point BZH. Évalué à 5. Dernière modification le 27 juin 2014 à 16:12.
Tout à fait d'accord sur l'intérêt principal du
.fr, en revanche je ne pense pas que les motifs invoqués pour justifier le.bzhsoient intrinsèquement si mauvais que ça. Peu sérieux, sans le moindre doute : le.bzhn'est absolument pas nécessaire.À mon avis, sa motivation principale est liée à une affirmation d'identité bretonne, qui n'est donc pas sérieuse techniquement parlant pour un nom de domaine de niveau supérieur — mais aucun de ces nouveaux TLD ne l'est — mais qui n'est pas intrinsèquement mauvaise : la fierté régionale qui n'implique en aucun cas une défiance nationale.
Bref, à mon avis, c'est l'attribution de nouveaux TLD privés qui est regrettable et peu justifiée, mais la volonté d'en créer un pour la Bretagne n'est pas spécialement inquiétante.
[^] # Re: .vin et .wine
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Point BZH. Évalué à 4.
Et vendre des noms de domaine de niveau inférieur aux VTC !
[^] # Re: .vin et .wine
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Point BZH. Évalué à 3.
Non, les noms de domaine de niveau supérieur ne sont pas vendus aux enchères par l'ICANN.
Non, les noms de domaine de niveau supérieur ne sont pas vendus au premier candidat qui se manifeste.
D'après les explications de l'ICANN, lorsque plusieurs candidats demandent le même nom, il y a après évaluation technique de chaque candidat une procédure de résolution du conflit, qui se termine par élection d'un seul candidat. Là, cette procédure n'a vsisiblement pas été nécessaire parce qu'il n'y avait qu'un seul candidat.