Depuis le temps que je me pose cette même question...bien que je ne soit pas un pro du C++, pendant un moment, si j'en avais pris le temps, je me serais peut-être lancé...
La version de chez free et bien entendu un peu limitée, mais autorise déjà à avoir une pratique plus propre du SQL, bénéficier du moteur MVCC de PgSQL, créer ses types (mais pas de ENUM car PgSQL 8.1) & domaines, découvrir les séquences (pour les habitué du autoincrement MySQL), créer des fonctions (seulement en SQL malheureusement :S), ...
Cependant, Free utilise pour le moment la version 4.1 de ppa.
Je pense que ce qui peut bien plaire aux utilisateurs de MySQL dans PostgreSQL, c'est aussi le principe de la moindre surprise, appliqué à tous les niveaux du projet.
Ça assure, par exemple, la strict conformance des données au type défini dans la table (la base ne tronquera pas un entier trop grand ou n'interprètera pas une date inexistante pour les faires entrer dans la table).
Si tu veux un point de vue concernant le développement, la grosse différence entre PostgreSQL et MySQL pour moi, c'est qu'ils ne jouent pas sur le même terrain.
Certains dev veulent des entrepôts stupide où stocker leurs données, gérant tout le système de contraintes et d'intégrité dans leur code.
D'autre préfèrent reléguer ça à la base de données et alléger d'autant leur code coté appli, ne pas avoir à les maintenir à plusieurs endroits si plusieurs applis utilisent la base, accélerer leur code, ...
A propos des "migrations", c'est aussi certainement dû aux projets qui veulent élargir leurs base utilisateur en proposant plus d'une base en backend. Le choix est un bon principe dans le libre, et il tend à s'améliorer dans le domaine des bases.
Mais ce que j'aime vraiment par dessus tout dans PostgreSQL, c'est sa grande qualité générale et sa formidable communauté !
PostgreSQL est un fier représentant du monde du logiciel Libre dans toute sa splendeur :)
Ok je comprend mieux maintenant, effectivement, c'est bien le contenu des cadres qui ont un encodage dépendant de la base.
Mais je te rassure, je ne portais pas spécialement mon attention là dessus que pour toi hein ;)
Je pensais aussi à tout ceux qui auraient la même configuration que toi et donc potentiellement un ppa avec des caractères tout cassé...
Après, il est vrai qu'une fois acquises ses petites habitudes dans psql, on a pas forcément envi d'aller s'embêter avec d'autres outils :)
A mon tour donc de te remercier qd même pour ton test et ton retour d'expérience !
A propos de l'encodage des pages, nous essaierons de reproduire ce comportement histoire de voir comment gérer ça (si possible).
Pour le reste, le problème de putenv() ne concerne que l'export des bases depuis ppa (qui utilise pg_dump[all] et les variables d'environnement pour l'authentification).
Le reste devrait fonctionner...mais en iso8859-1 donc :-/
Merci pour ton test et ce retour d'info en tout cas !
> En passant, j'ai remarqué que sur le site de démo, le charset est ISO8859-1 et non UTF-8. Es-ce que phpPgAdmin ne supporte pas UTF-8 ? Ou es-ce que la valeur est récupérée de la configuration de la base de données ?
En fait, ppa choisi l'encodage de ses pages en fonction de celui de la base.
Tu peux faire le test sur le serveur de démo avec plusieurs bases avec des encodages différents, tu verra l'entête xml et le Content-Type évoluer en fonction de la base sélectionnée.
Oui, effectivement, nous /devrions/ passer en php 5.2.
Cependant, la dernière discussion à ce sujet portait bien sur l'adoption 5.0, le but étant de passer sur le maximum de configuration possible, certaines distrib supportant toujours ces versions officiellement (enfin, théoriquement...RedHat ? Ubuntu ?).
> Félicitations pour ce journal, n'hésite pas à compléter pour une dépêche quand la version finale sera dispo
Merci :)
À vrai dire, j'ai un peu hésité entre faire un journal ou une dépêche, mais j'ai finalement opté pour le journal aujourd'hui et la dépêche pour la sortie officielle.
>Je n'ai pas trouvé de roadmap...
Non, effectivement, sans équipe suffisamment étoffée, il nous serais impossible de tenir les délais d'une roadmap...
Cependant, nous avons potentiellement 2/3 codeurs sur les rangs qui attendent la sortie de 4.2 pour commencer à coder correctement sur ppa 5 (ça tombe bien non :) ? ).
Avec cette aide fortement bienvenue et un bon paquet d'idée, nous avons dans l'idée d'essayer de publier nos versions plus souvent, quitte à n'y ajouter qu'une ou deux nouvelles fonctionnalité à la fois !
> Dans les fonctions, est-il prévu d'ajouter de la rétroingénierie de base de données pour obtenir un modèle UML (Unified_Modeling_Language) ou Merise_(informatique) du Modèle Physique de Données (MPD) ?
Il me semble que ça avait été proposé, notamment grâce à un projet bourré à l'ajax. Depuis, les choses font leur petit bout de chemin avec par exemple ce genre de choses : http://dalibo.org/WWW-SQL-Designer.html
Reste à voir si tout le code a la bonne licence, si le projet est viable pour des bases de données conséquentes et s'il est intéressant de l'intégrer à ppa.
Une choses est sûre, avec la qualité des schémas système de pg, rien n'est impossible.
> Sinon autodoc fonctionne-t-il toujours aussi bien pour générer les schémas ?
Aucune idée. Je crois me souvenir l'avoir testé il y a quelques temps, mais je ne me souviens plus du tout de ce que j'en avais tiré...
C'est bon, c'est bon, n'en jetez plus, je ne suis pas un anti-LDAP non plus hein...
Ceci dit merci à vous pour vos info diverses (histoire de lecture plus efficace et param multi-valeurs), j'ai été me documenter un peu plus là dessus et me suis rendu compte d'une chose qui m'avait *bien* échappée (chkreugneugneu) jusqu'ici : Berckley DB n'est pas une base de données au même sens que les bases SQL bien connues...
..Et là, beaucoup de choses s'expliques du coup :)
Tu peux aussi me citer en entier, tu notera que j'avais pourtant bien précisé "si le SI en question le permet" (SI: Système d'Information, au cas où hein)...
Et puis pas mal d'applications ont des extensions permettant d'authentifier sur une base SQL, nativement en pgsql ou via ODBC par exemple.
Maintenant, si vous voulez coller du LDAP à tous les étages même dans une entreprise n'en ayant pas le besoin hein...Perso LDAP ne me sort pas encore totalement par la tête...Mais allez en parler à Kaf :)
For other storage engines, MySQL Server parses and ignores the FOREIGN KEY and REFERENCES syntax in CREATE TABLE statements. The CHECK clause is parsed but ignored by all storage engines. See Section 1.8.5.4, “Foreign Keys”.
(cf. http://dev.mysql.com/doc/refman/5.1/en/create-table.html)
Non seulement MySQL laisse passer des choses sans les faires, mais ne supporte pas non plus la clause CHECK.
Donc bon...support des contraintes hein...
PostgreSQL lui, en plus de bien entendu supporter CHECK, remet le couvert en proposant les domaines et la céation de type personnalisé qui peuvent encore enfoncer le clou de l'intégrité...
Bon, allé, je sais que la plupart d'entre vous ont déjà vu passé ce document ici, mais je le recolle tout de même : "Pourquoi préférer PostgreSQL à MySQL : comparatif de fiabilité et de rapidité en 2007" http://www.postgresqlfr.org/?q=node/1432
Bon, sinon, à part ça, oui LDAP est utile pour mutualiser des choses et des services comme l'authentification, mais parfois, adns ce dernier cas, PAM peut trés bien suffir aussi pour faire la colle avec une simple base.
De plus, LDAP reposant sur une base de donnée, pourquoi se priver de virer ce protocol supplémentaire si le SI en question le permet ? Et justement ce pourrait être le cas de Kaf si le module pdbsql était un peu mieux supporté/documenté...
Mais il faut croire que la norme est à Samba/LDAP depuis les fameux scripts smbldap et pour se rapprocher au mieux d'Active Directory je suppose...
> J'en profite pour demander si quelqu'un à une experience Samba / postrgre
> pour un domaine doz à la place de Samba / LDAP. Ca semble interessant
> mais mal documenté...
Oui, malheureusement...Samba a abandonné les backend db et un projet à emergé pour "maintenir" la chose : http://pdbsql.sourceforge.net/
Mais effectivement la doc et les exemples y sont trés pauvre et pas à jour...
Il reste toujours un Samba / LDAP / PgSQL qui lui semble un peu mieux documenté :)
Non, ça n'explique pas en quoi tu trouves MySQL mieux que PostgreSQL.
Si tu veux parler d'un meilleur support professionnel pour MySQL, sache que Sun intègre PostgreSQL par défaut dans Solaris10 et le supporte auprès de ses clients utilisateurs.
Note aussi qu'ils ont employé un des core développeur de PgSQL depuis à peu près 2 ans...
1/ Grande qualité de code, élégance, sérieux, pas de bidouille
3/ Libre
2/ Pérennité et intégrité des données
4/ Richesse fonctionnelle
5/ Trés extensible
6/ Communauté
...
Oui oui, je sais, j'auais dû effectivement retoucher un peu le texte pour rafraichir tout ça...
Ceci dit, tu notera que pour rester dans le contexte du vendredi, j'y ai aussi ajouté une petite pincée ne poudre de troll des bois préallablement séché dans un endroit frais et aéré :)
Le tout associé à la traduction d'un document dont j'ai estimé intéressant de faire la promotion ici.
Oui, il y avait peu d'éffort, mais un poil peu qd même.
Alors, j'aurais peut-être pas dû le tourner ainsi.
Mais pour être bien clair, je sais ce que sont les journaux, je sais ce que sont les dépêches et je sais que pgfr "vit ave les dépêche".
Si je n'ai pas proposé de dépêche, c'est que je (et le reste de pgfr en fait) préfère attendre la sortie officielle de PostgreSQL pour proposer (moi ou un autre) en dépêche la traduction de l'annonce officielle du "PGDG" accompagnés éventuellement de commentaires de pgfr.
Voilà voilà, je pense pas que ce soit la peine de monter dans les tours aussi vite...on est vendredi après tout.
En attendant, je suis étonné que si peu de gens ici s'interessent cette nouvelle...j'aurais peut-être dû balancer un lien sur "Why PostgreSQL Instead of MySQL: Comparing Reliability and Speed in 2007" [1] pour affoler un peu plus les foules (traduction en court de relecture avant publication sur pgfr)...
runit est un projet qui se propose en remplacement du init traditionnel. Son avantage est qu'il est trés léger et utilise un programe pour gérer et monitorer les services lancé : runsvdir.
J'ai ouï dire cette même semaine via une source de confiance que runit dopait significativement la durée de boot.
Seul petit hic : se repalucher une conf de chaque service pour runit (notez que Debian a un paquet qui propose ça : runit-services).
Bref, j'en dis pas plus car je n'ai toujours pas testé le bestiot...Avis à ceux-ce qui ont tenté l'expérience.
[^] # Re: Avis persos ?
Posté par ioguix . En réponse à la dépêche symfony 1.1 est sorti. Évalué à 1.
Depuis le temps que je me pose cette même question...bien que je ne soit pas un pro du C++, pendant un moment, si j'en avais pris le temps, je me serais peut-être lancé...
[^] # Re: Vision macroscopique
Posté par ioguix . En réponse à la dépêche phpPgAdmin 4.2. Évalué à 1.
[^] # Re: Vision macroscopique
Posté par ioguix . En réponse à la dépêche phpPgAdmin 4.2. Évalué à 2.
Cependant, Free utilise pour le moment la version 4.1 de ppa.
[^] # Re: La tendance PostgreSQL
Posté par ioguix . En réponse à la dépêche phpPgAdmin 4.2. Évalué à 9.
Ça assure, par exemple, la strict conformance des données au type défini dans la table (la base ne tronquera pas un entier trop grand ou n'interprètera pas une date inexistante pour les faires entrer dans la table).
Si tu veux un point de vue concernant le développement, la grosse différence entre PostgreSQL et MySQL pour moi, c'est qu'ils ne jouent pas sur le même terrain.
Certains dev veulent des entrepôts stupide où stocker leurs données, gérant tout le système de contraintes et d'intégrité dans leur code.
D'autre préfèrent reléguer ça à la base de données et alléger d'autant leur code coté appli, ne pas avoir à les maintenir à plusieurs endroits si plusieurs applis utilisent la base, accélerer leur code, ...
A propos des "migrations", c'est aussi certainement dû aux projets qui veulent élargir leurs base utilisateur en proposant plus d'une base en backend. Le choix est un bon principe dans le libre, et il tend à s'améliorer dans le domaine des bases.
Mais ce que j'aime vraiment par dessus tout dans PostgreSQL, c'est sa grande qualité générale et sa formidable communauté !
PostgreSQL est un fier représentant du monde du logiciel Libre dans toute sa splendeur :)
[^] # Re: GoPHP 5
Posté par ioguix . En réponse au journal Des nouvelles de phpPgAdmin. Évalué à 3.
Mais je te rassure, je ne portais pas spécialement mon attention là dessus que pour toi hein ;)
Je pensais aussi à tout ceux qui auraient la même configuration que toi et donc potentiellement un ppa avec des caractères tout cassé...
Après, il est vrai qu'une fois acquises ses petites habitudes dans psql, on a pas forcément envi d'aller s'embêter avec d'autres outils :)
A mon tour donc de te remercier qd même pour ton test et ton retour d'expérience !
:)
[^] # Re: Voilà qui fait plaisir
Posté par ioguix . En réponse au journal Des nouvelles de phpPgAdmin. Évalué à 2.
Passe le bonjour à dr de ma part si tu as encore l'occasion de le croiser ;)
/me ancien i2k nostalgique
[^] # Re: GoPHP 5
Posté par ioguix . En réponse au journal Des nouvelles de phpPgAdmin. Évalué à 1.
Pour le reste, le problème de putenv() ne concerne que l'export des bases depuis ppa (qui utilise pg_dump[all] et les variables d'environnement pour l'authentification).
Le reste devrait fonctionner...mais en iso8859-1 donc :-/
Merci pour ton test et ce retour d'info en tout cas !
[^] # Re: GoPHP 5
Posté par ioguix . En réponse au journal Des nouvelles de phpPgAdmin. Évalué à 1.
En fait, ppa choisi l'encodage de ses pages en fonction de celui de la base.
Tu peux faire le test sur le serveur de démo avec plusieurs bases avec des encodages différents, tu verra l'entête xml et le Content-Type évoluer en fonction de la base sélectionnée.
[^] # Re: bravo
Posté par ioguix . En réponse au journal Des nouvelles de phpPgAdmin. Évalué à 1.
D'après les sources, je dirais que ton liens est plus à jour (1.3.x vs. 1.4)
[^] # Re: GoPHP 5
Posté par ioguix . En réponse au journal Des nouvelles de phpPgAdmin. Évalué à 3.
Cependant, la dernière discussion à ce sujet portait bien sur l'adoption 5.0, le but étant de passer sur le maximum de configuration possible, certaines distrib supportant toujours ces versions officiellement (enfin, théoriquement...RedHat ? Ubuntu ?).
[^] # Re: bravo
Posté par ioguix . En réponse au journal Des nouvelles de phpPgAdmin. Évalué à 10.
Merci :)
À vrai dire, j'ai un peu hésité entre faire un journal ou une dépêche, mais j'ai finalement opté pour le journal aujourd'hui et la dépêche pour la sortie officielle.
>Je n'ai pas trouvé de roadmap...
Non, effectivement, sans équipe suffisamment étoffée, il nous serais impossible de tenir les délais d'une roadmap...
Cependant, nous avons potentiellement 2/3 codeurs sur les rangs qui attendent la sortie de 4.2 pour commencer à coder correctement sur ppa 5 (ça tombe bien non :) ? ).
Avec cette aide fortement bienvenue et un bon paquet d'idée, nous avons dans l'idée d'essayer de publier nos versions plus souvent, quitte à n'y ajouter qu'une ou deux nouvelles fonctionnalité à la fois !
> Dans les fonctions, est-il prévu d'ajouter de la rétroingénierie de base de données pour obtenir un modèle UML (Unified_Modeling_Language) ou Merise_(informatique) du Modèle Physique de Données (MPD) ?
Il me semble que ça avait été proposé, notamment grâce à un projet bourré à l'ajax. Depuis, les choses font leur petit bout de chemin avec par exemple ce genre de choses : http://dalibo.org/WWW-SQL-Designer.html
Reste à voir si tout le code a la bonne licence, si le projet est viable pour des bases de données conséquentes et s'il est intéressant de l'intégrer à ppa.
Une choses est sûre, avec la qualité des schémas système de pg, rien n'est impossible.
> Sinon autodoc fonctionne-t-il toujours aussi bien pour générer les schémas ?
Aucune idée. Je crois me souvenir l'avoir testé il y a quelques temps, mais je ne me souviens plus du tout de ce que j'en avais tiré...
[^] # Re: Yo
Posté par ioguix . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 1.
Ceci dit merci à vous pour vos info diverses (histoire de lecture plus efficace et param multi-valeurs), j'ai été me documenter un peu plus là dessus et me suis rendu compte d'une chose qui m'avait *bien* échappée (chkreugneugneu) jusqu'ici : Berckley DB n'est pas une base de données au même sens que les bases SQL bien connues...
..Et là, beaucoup de choses s'expliques du coup :)
[^] # Re: Yo
Posté par ioguix . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 1.
Et puis pas mal d'applications ont des extensions permettant d'authentifier sur une base SQL, nativement en pgsql ou via ODBC par exemple.
Maintenant, si vous voulez coller du LDAP à tous les étages même dans une entreprise n'en ayant pas le besoin hein...Perso LDAP ne me sort pas encore totalement par la tête...Mais allez en parler à Kaf :)
[^] # Re: postgresql c'est mieux
Posté par ioguix . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 7.
For other storage engines, MySQL Server parses and ignores the FOREIGN KEY and REFERENCES syntax in CREATE TABLE statements. The CHECK clause is parsed but ignored by all storage engines. See Section 1.8.5.4, “Foreign Keys”.
(cf. http://dev.mysql.com/doc/refman/5.1/en/create-table.html)
Non seulement MySQL laisse passer des choses sans les faires, mais ne supporte pas non plus la clause CHECK.
Donc bon...support des contraintes hein...
PostgreSQL lui, en plus de bien entendu supporter CHECK, remet le couvert en proposant les domaines et la céation de type personnalisé qui peuvent encore enfoncer le clou de l'intégrité...
Bon, allé, je sais que la plupart d'entre vous ont déjà vu passé ce document ici, mais je le recolle tout de même : "Pourquoi préférer PostgreSQL à MySQL : comparatif de fiabilité et de rapidité en 2007" http://www.postgresqlfr.org/?q=node/1432
[^] # Re: Yo
Posté par ioguix . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 1.
Bon, sinon, à part ça, oui LDAP est utile pour mutualiser des choses et des services comme l'authentification, mais parfois, adns ce dernier cas, PAM peut trés bien suffir aussi pour faire la colle avec une simple base.
De plus, LDAP reposant sur une base de donnée, pourquoi se priver de virer ce protocol supplémentaire si le SI en question le permet ? Et justement ce pourrait être le cas de Kaf si le module pdbsql était un peu mieux supporté/documenté...
Mais il faut croire que la norme est à Samba/LDAP depuis les fameux scripts smbldap et pour se rapprocher au mieux d'Active Directory je suppose...
[^] # Re: postgresql c'est mieux
Posté par ioguix . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 6.
Nous sommes pour le moment en beta1, le projet avance, malgrès une équipe de développement pas trés étoffée et plutôt surchargée par ses a-cotés.
Bref, tirez la version CVS de PPA, et testez là !!
Pour ce faire:
$ cvs -d:pserver:anonymous@phppgadmin.cvs.sourceforge.net:/cvsroot/phppgadmin login
$ cvs -z3 -d:pserver:anonymous@phppgadmin.cvs.sourceforge.net:/cvsroot/phppgadmin co -P webdb -d phpPgAdmin
Contributeurs bien venu, rdv sur les ml et sur freenode #phppgadmin
[^] # Ploup
Posté par ioguix . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 1.
Merci mon grand kak^WCoco :)
> J'en profite pour demander si quelqu'un à une experience Samba / postrgre
> pour un domaine doz à la place de Samba / LDAP. Ca semble interessant
> mais mal documenté...
Oui, malheureusement...Samba a abandonné les backend db et un projet à emergé pour "maintenir" la chose : http://pdbsql.sourceforge.net/
Mais effectivement la doc et les exemples y sont trés pauvre et pas à jour...
Il reste toujours un Samba / LDAP / PgSQL qui lui semble un peu mieux documenté :)
[^] # Re: Mysql c'est mieux
Posté par ioguix . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 10.
Si tu veux parler d'un meilleur support professionnel pour MySQL, sache que Sun intègre PostgreSQL par défaut dans Solaris10 et le supporte auprès de ses clients utilisateurs.
Note aussi qu'ils ont employé un des core développeur de PgSQL depuis à peu près 2 ans...
[^] # Re: postgresql c'est mieux
Posté par ioguix . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 10.
3/ Libre
2/ Pérennité et intégrité des données
4/ Richesse fonctionnelle
5/ Trés extensible
6/ Communauté
...
[^] # Mea culpa
Posté par ioguix . En réponse au journal Postgresql 8.3 en béta2. Évalué à 2.
Ceci dit, tu notera que pour rester dans le contexte du vendredi, j'y ai aussi ajouté une petite pincée ne poudre de troll des bois préallablement séché dans un endroit frais et aéré :)
Le tout associé à la traduction d'un document dont j'ai estimé intéressant de faire la promotion ici.
Oui, il y avait peu d'éffort, mais un poil peu qd même.
[^] # ...ou pas
Posté par ioguix . En réponse au journal Postgresql 8.3 en béta2. Évalué à 3.
Mais pour être bien clair, je sais ce que sont les journaux, je sais ce que sont les dépêches et je sais que pgfr "vit ave les dépêche".
Si je n'ai pas proposé de dépêche, c'est que je (et le reste de pgfr en fait) préfère attendre la sortie officielle de PostgreSQL pour proposer (moi ou un autre) en dépêche la traduction de l'annonce officielle du "PGDG" accompagnés éventuellement de commentaires de pgfr.
Voilà voilà, je pense pas que ce soit la peine de monter dans les tours aussi vite...on est vendredi après tout.
[^] # Re: hein ?
Posté par ioguix . En réponse au journal Sortie de PostgreSQL 8.3 beta1. Évalué à 3.
[1] http://www.mysql.com/mysql60/faq.html
[^] # maintenant qu'on est vendredi hein...
Posté par ioguix . En réponse au journal Sortie de PostgreSQL 8.3 beta1. Évalué à 3.
le petit test présenté ici http://j-davis.com/postgresql/83v82_scans.html démontre trés clairement l'interêt de la chose.
En attendant, je suis étonné que si peu de gens ici s'interessent cette nouvelle...j'aurais peut-être dû balancer un lien sur "Why PostgreSQL Instead of MySQL: Comparing Reliability and Speed in 2007" [1] pour affoler un peu plus les foules (traduction en court de relecture avant publication sur pgfr)...
[1] http://www.postgresql.org/docs/techdocs.83
# runit
Posté par ioguix . En réponse au journal Temps de démarrage: Mac OS X contre Linux. Évalué à 2.
http://smarden.org/runit/
runit est un projet qui se propose en remplacement du init traditionnel. Son avantage est qu'il est trés léger et utilise un programe pour gérer et monitorer les services lancé : runsvdir.
J'ai ouï dire cette même semaine via une source de confiance que runit dopait significativement la durée de boot.
Seul petit hic : se repalucher une conf de chaque service pour runit (notez que Debian a un paquet qui propose ça : runit-services).
Bref, j'en dis pas plus car je n'ai toujours pas testé le bestiot...Avis à ceux-ce qui ont tenté l'expérience.
[^] # Re: Traducteurs traduisez...
Posté par ioguix . En réponse au journal IBM se joint à la communauté OOo. Évalué à 4.
Petite précision, ce n'est pas vraiment un faux ami (sauf si tu traduit au mot à mot), c'est un "phrasal verb" http://en.wikipedia.org/wiki/Phrasal_verb
Voilà une notion de l'anglais qui devrait, si tu ne la connaissais pas, occuper beaucoup de tes nuits sans sommeil vu leur utilisation massive...