> Ravi d'apprendre que la mise à jour automatique du noyau n'aura pas lieu
Ce qui scandaleux et définitivement une honte dans le libre.
> à cause de ce choix pourtant plein de sagesse
Laisser des trous de sécurité est un choix plein de sagesse....
Comme à dit je ne sais plus qui : "seul l'imbécilité donne une idée de l'infini".
Les autres distributions installes par défaut le nouveau noyau en parallèle et le nouveau noyau est le noyau par défaut. Si le nouveau noyau ne marche pas, tu démarres sur l'ancien (ça se fait en 2 secondes maxi). Certes il y auras une poignées de bécanes qui restent avec un trou de sécurité mais ce n'est pas 100 % et ce n'est pas intentionnellement 100 %.
> Du coup, ils peuvent le fermer très facilement en refusant de faire l'amélioration.
Non.
Tu ne fermes pas le bug car tu as la flemme de faire l'amélioration, mais car tu trouves que l'amélioration n'apporte rien, ou ne fait pas partie des objectifs du programme (par exemple tu veux faire un programme très léger), etc...
Mais définitivement tu ne fermes pas une demande d'amélioration car il n'y a personne pour la faire.
Par contre il faut effectivement clairement distinguer une demande d'amélioration et un bug.
> et il est donc stupide de rendre la chose illisible.
Il est stupide aussi de rendre du xml illisible.
> XML par contre, la taille des balises influe sur le resultat final en terme de vitesse et espace.
Si XML est illisible, ça influe sur le développement (toujours avoir le nez dans la doc, problèmes de communication, etc...) et négativement.
Mauvais développement => mauvais programme => utilisateur pas content.
Et ne c'est pas les 0,2 % de gain en performance qui vont changer grand chose.
Quand tu codes, que t'utilises des noms cours ou des noms longs, la compilation n'est pas significativement plus courte ou plus longue.
> mais ca n'a jamais ete prevu pour etre un format modifiable par un humain.
Ben si. Ce qui ne veut pas dire que c'est pertinent de le faire.
Par contre ce qui est créé/modifié à la main doit être contrôlé (si on ne fait pas les choses comme un porc, c'est très facilement faisable).
Tu oublies aussi par exemple les scripts php/etc qui générent du xml quasiment à la main.
Ne soit pas "ridicule".
Pourquoi pas une API de ce type (j'ai gardé les mots clés C) : /* t_qngr_arj() returns an invalid date, you then have to _frg() stuff
* to get a usable object. You can also allocate a TQngr statically,
* then call t_qngr_pyrne() to initialize.
*/
/* check t_qngr_inyvq() after doing an operation that might fail, like
* _cnefr. Almost all t_qngr operations are undefined on invalid
* dates (the exceptions are the mutators, since you need those to
* return to validity).
*/
TQngrJrrxqnl t_qngr_trg_jrrxqnl (const TQngr *qngr);
TQngrZbagu t_qngr_trg_zbagu (const TQngr *qngr);
TQngrLrne t_qngr_trg_lrne (const TQngr *qngr);
TQngrQnl t_qngr_trg_qnl (const TQngr *qngr);
thvag32 t_qngr_trg_whyvna (const TQngr *qngr);
thvag t_qngr_trg_qnl_bs_lrne (const TQngr *qngr);
/* First monday/sunday is the start of week 1; if we haven't reached
* that day, return 0. These are not ISO weeks of the year; that
* routine needs to be added.
* these functions return the number of weeks, starting on the
* corrsponding day
*/
thvag t_qngr_trg_zbaqnl_jrrx_bs_lrne (const TQngr *qngr);
thvag t_qngr_trg_fhaqnl_jrrx_bs_lrne (const TQngr *qngr);
thvag t_qngr_trg_vfb8601_jrrx_bs_lrne (const TQngr *qngr);
Même si c'est documenté, c'est brise couille.
La version originale : /* g_date_new() returns an invalid date, you then have to _set() stuff
* to get a usable object. You can also allocate a GDate statically,
* then call g_date_clear() to initialize.
*/
GDate* g_date_new (void);
GDate* g_date_new_dmy (GDateDay day,
GDateMonth month,
GDateYear year);
GDate* g_date_new_julian (guint32 julian_day);
void g_date_free (GDate *date);
/* check g_date_valid() after doing an operation that might fail, like
* _parse. Almost all g_date operations are undefined on invalid
* dates (the exceptions are the mutators, since you need those to
* return to validity).
*/
gboolean g_date_valid (const GDate *date);
gboolean g_date_valid_day (GDateDay day) G_GNUC_CONST;
gboolean g_date_valid_month (GDateMonth month) G_GNUC_CONST;
gboolean g_date_valid_year (GDateYear year) G_GNUC_CONST;
gboolean g_date_valid_weekday (GDateWeekday weekday) G_GNUC_CONST;
gboolean g_date_valid_julian (guint32 julian_date) G_GNUC_CONST;
gboolean g_date_valid_dmy (GDateDay day,
GDateMonth month,
GDateYear year) G_GNUC_CONST;
GDateWeekday g_date_get_weekday (const GDate *date);
GDateMonth g_date_get_month (const GDate *date);
GDateYear g_date_get_year (const GDate *date);
GDateDay g_date_get_day (const GDate *date);
guint32 g_date_get_julian (const GDate *date);
guint g_date_get_day_of_year (const GDate *date);
/* First monday/sunday is the start of week 1; if we haven't reached
* that day, return 0. These are not ISO weeks of the year; that
* routine needs to be added.
* these functions return the number of weeks, starting on the
* corrsponding day
*/
guint g_date_get_monday_week_of_year (const GDate *date);
guint g_date_get_sunday_week_of_year (const GDate *date);
guint g_date_get_iso8601_week_of_year (const GDate *date);
Ça me fait rire car en août 2006 je me suis fait massivement moinser car je disais que plasma ne sera pas dispo avant fin 2006 (conclusion faite en lisant un thread où une personne n'arrivait pas à avoir un état d'avancement de plasma).
Pas sûr maintenant que plasma sorte en 2007.
Des doutes subsistent toutefois sur certaines innovations comme plasma (pour l'interface graphique) ou le projet portable akonadi [3] (pour la synchronisation des téléphones, PDA, etc.) dont l'état d'avancement reste indéterminé.
Tu peux, je n'ai pas de pointeur sous le coude.
J'ai vu ça dans une discussion sur le planning de sorti de KDE 4.0. En gros plasma passera après kde-pim par exemple. Il n'y a pas que plasma qui ne sera pas dans KDE 4.0. KDE doit sortir rapidement la version 4.0 car des développeurs abandonnent KDE pour aller vers Qt 4.x exclusivement, et qu'au rythme où ça va, KDE 4 risque de sortir après Qt 5.
Ça n'empêchera pas de voir plasma dans KDE 4.1 par exemple.
> En fait actuellement ils en sont à se demander si ils peuvent réaliser Plasma en réutilisant uniquement ce qu'offre Qt ou si ils doivent coder un truc à leur sauce qui sera alors taillé sur mesure pour Plasma
Je vais être mauvaise langue, mais ça craind. Ça fait depuis plus d'un an que plasma fait du buzz. À 6 mois de la sortie KDE 4.0, il n'est pas normal de se demander quelle librairie va être utilisée pour coder plasma.
Oui et non.
Si les balises ont des noms compréhensibles, ça aide les développeurs, ça aide les échanges. Un standard qui est difficile pour les développeurs, ce n'est pas in fine un plus pour les utilisateurs.
Si le standard est utilisé que par un logiciel, pourquoi pas.
Mais ODF est utilisé par les développeurs de OOo, KOffice, Abiword, Gnumeric, etc... Comme c'est un standard, il y aura des outils pour convertir en pdf, en html, pour y faire des requêtes, alimenter une base de données, faire de la doc d'API depuis des sources par exemple en C vers ODF, etc...
Il est important que le standard soit accessible aux développeurs. C'est important aussi pour les utilisateurs.
> Bref, la gauche et la droite ils sont relativement "créatif" quand il s'agit de magouilles, mais alors quand il faut faire avancer le pays, là plus personne...
Il n'y aurait pas moyen d'éviter ce type de commentaire ?
Ils apportent quoi à part acréditer les discours "tous pourris" et "la démocratie ça sucks" ?
> Tu oublie quand même que l'OpenXML a un certain avantages sur le support d'outils pour handicapé.
Tu peux développer ?
Le format OpenXML permet des outils que ne permet pas le format ODF ?
Ou c'est simplement que ces outils n'ont pas encore été développé pour ODF ?
Troll à part, je trouve fascinant cette obsession maladive à vouloir se distinguer, à refuser toute sorte de parenté.
J'ai survolé les articles QuebecOs (les traductions) et je trouve qu'il y a des choses de Gnome (et d'autres) dans KDE.
SVG n'est bien. Que ce soit dans Gnome ou KDE.
Les icones avec du texte c'est bien. Que ce soit dans Gnome ou KDE.
Il y a quelques idées spécifiques à KDE 4 qui sont bien et que j'aimerai voir dans Gnome.
En survolant les copies d'écran, c'est la première fois que je ne trouve pas KDE moche.
> Les anglophones, comment qu'ils prononcent "Nouveau"?
"Nouveau".
C'est la bonne réponse ?
D'ailleurs j'ignore si "nouveau" se prononce en anglais s'il n'y a pas plus de précision. Pour ce qui est écrit en anglais, il n'est pas toujours facile de savoir comment ça se prononce (il faut un dictionnaire). C'est beaucoup plus rarement le cas en français.
"Qt", je le prononce "Qt". Et toi ?
Quand un truc peu se lire (à haut voix) en français, ben prenons la version française.
Tu dis Ubuntu ou <Ubuntu prononcé par un anglais> ?
Tu dis Linux ou ...
> Le probleme avec ca c'est que MS n'avait pas d'autre choix que TCP/IP et les normes W3C, il n'existait rien d'autre qui offre les memes possibilites.
Pour W3C, c'est un peu faux. MS voulait laisser tomber html/etc. Mais comme Firefox grimpe, MS a sortit IE7 par exemple.
> N'étant pas un spécialiste du domaine et des problèmatiques liées à ce genre de formats
Idem
> je me demandais ce qui dans ce format le rendais mal foutu ?
Parce que OpenXML veut offrir une grosse compatibilité avec les fonctionnalités .doc .xls, etc.
Donc les trucs mal foutus des anciens formats se retourne dans OpenXML. Il y a même des parties qui sont des "blobs" sur des formats partiellement documentés (wmf par exemple).
> En effet, on fait il me semble partie de l'Europe qui ne PROPOSE pas mais IMPOSE des DIRECTIVES qu'il faut TRANSPOSER. Quel pouvoir de dire non pour un politique ? euh... accepter de payer l'amende.
Un corse peut dire :
- "En effet, on fait il me semble partie de la France qui ne PROPOSE pas mais IMPOSE des LOIS qu'il faut TRANSPOSER. Quel pouvoir de dire non pour un politique ? euh... accepter de payer l'amende."
On fait parti de l'Europe, on participe aux décisions de l'Europe, on y a adhéré librement.
[^] # Re: Mise à jour automatique du noyau
Posté par IsNotGood . En réponse au journal Cooker ; The Inside Man VI ( version française ). Évalué à -3.
Ce qui scandaleux et définitivement une honte dans le libre.
> à cause de ce choix pourtant plein de sagesse
Laisser des trous de sécurité est un choix plein de sagesse....
Comme à dit je ne sais plus qui : "seul l'imbécilité donne une idée de l'infini".
Les autres distributions installes par défaut le nouveau noyau en parallèle et le nouveau noyau est le noyau par défaut. Si le nouveau noyau ne marche pas, tu démarres sur l'ancien (ça se fait en 2 secondes maxi). Certes il y auras une poignées de bécanes qui restent avec un trou de sécurité mais ce n'est pas 100 % et ce n'est pas intentionnellement 100 %.
La décision de Mandriva est une HONTE !
[^] # Re: Que du bon :-)
Posté par IsNotGood . En réponse à la dépêche KDE 4 : publication escomptée en octobre 2007. Évalué à 2.
Non.
Tu ne fermes pas le bug car tu as la flemme de faire l'amélioration, mais car tu trouves que l'amélioration n'apporte rien, ou ne fait pas partie des objectifs du programme (par exemple tu veux faire un programme très léger), etc...
Mais définitivement tu ne fermes pas une demande d'amélioration car il n'y a personne pour la faire.
Par contre il faut effectivement clairement distinguer une demande d'amélioration et un bug.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 4.
Il est stupide aussi de rendre du xml illisible.
> XML par contre, la taille des balises influe sur le resultat final en terme de vitesse et espace.
Si XML est illisible, ça influe sur le développement (toujours avoir le nez dans la doc, problèmes de communication, etc...) et négativement.
Mauvais développement => mauvais programme => utilisateur pas content.
Et ne c'est pas les 0,2 % de gain en performance qui vont changer grand chose.
Quand tu codes, que t'utilises des noms cours ou des noms longs, la compilation n'est pas significativement plus courte ou plus longue.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 4.
http://www.w3.org/TR/2006/REC-xml-20060816/
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 2.
Ben si. Ce qui ne veut pas dire que c'est pertinent de le faire.
Par contre ce qui est créé/modifié à la main doit être contrôlé (si on ne fait pas les choses comme un porc, c'est très facilement faisable).
Tu oublies aussi par exemple les scripts php/etc qui générent du xml quasiment à la main.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 2.
Pourquoi pas une API de ce type (j'ai gardé les mots clés C) :
/* t_qngr_arj() returns an invalid date, you then have to _frg() stuff
* to get a usable object. You can also allocate a TQngr statically,
* then call t_qngr_pyrne() to initialize.
*/
TQngr* t_qngr_arj (void);
TQngr* t_qngr_arj_qzl (TQngrQnl qnl,
TQngrZbagu zbagu,
TQngrLrne lrne);
TQngr* t_qngr_arj_whyvna (thvag32 whyvna_qnl);
void t_qngr_serr (TQngr *qngr);
/* check t_qngr_inyvq() after doing an operation that might fail, like
* _cnefr. Almost all t_qngr operations are undefined on invalid
* dates (the exceptions are the mutators, since you need those to
* return to validity).
*/
tobbyrna t_qngr_inyvq (const TQngr *qngr);
tobbyrna t_qngr_inyvq_qnl (TQngrQnl qnl) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_zbagu (TQngrZbagu zbagu) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_lrne (TQngrLrne lrne) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_jrrxqnl (TQngrJrrxqnl jrrxqnl) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_whyvna (thvag32 whyvna_qngr) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_qzl (TQngrQnl qnl,
TQngrZbagu zbagu,
TQngrLrne lrne) T_TAHP_PBAFG;
TQngrJrrxqnl t_qngr_trg_jrrxqnl (const TQngr *qngr);
TQngrZbagu t_qngr_trg_zbagu (const TQngr *qngr);
TQngrLrne t_qngr_trg_lrne (const TQngr *qngr);
TQngrQnl t_qngr_trg_qnl (const TQngr *qngr);
thvag32 t_qngr_trg_whyvna (const TQngr *qngr);
thvag t_qngr_trg_qnl_bs_lrne (const TQngr *qngr);
/* First monday/sunday is the start of week 1; if we haven't reached
* that day, return 0. These are not ISO weeks of the year; that
* routine needs to be added.
* these functions return the number of weeks, starting on the
* corrsponding day
*/
thvag t_qngr_trg_zbaqnl_jrrx_bs_lrne (const TQngr *qngr);
thvag t_qngr_trg_fhaqnl_jrrx_bs_lrne (const TQngr *qngr);
thvag t_qngr_trg_vfb8601_jrrx_bs_lrne (const TQngr *qngr);
Même si c'est documenté, c'est brise couille.
La version originale :
/* g_date_new() returns an invalid date, you then have to _set() stuff
* to get a usable object. You can also allocate a GDate statically,
* then call g_date_clear() to initialize.
*/
GDate* g_date_new (void);
GDate* g_date_new_dmy (GDateDay day,
GDateMonth month,
GDateYear year);
GDate* g_date_new_julian (guint32 julian_day);
void g_date_free (GDate *date);
/* check g_date_valid() after doing an operation that might fail, like
* _parse. Almost all g_date operations are undefined on invalid
* dates (the exceptions are the mutators, since you need those to
* return to validity).
*/
gboolean g_date_valid (const GDate *date);
gboolean g_date_valid_day (GDateDay day) G_GNUC_CONST;
gboolean g_date_valid_month (GDateMonth month) G_GNUC_CONST;
gboolean g_date_valid_year (GDateYear year) G_GNUC_CONST;
gboolean g_date_valid_weekday (GDateWeekday weekday) G_GNUC_CONST;
gboolean g_date_valid_julian (guint32 julian_date) G_GNUC_CONST;
gboolean g_date_valid_dmy (GDateDay day,
GDateMonth month,
GDateYear year) G_GNUC_CONST;
GDateWeekday g_date_get_weekday (const GDate *date);
GDateMonth g_date_get_month (const GDate *date);
GDateYear g_date_get_year (const GDate *date);
GDateDay g_date_get_day (const GDate *date);
guint32 g_date_get_julian (const GDate *date);
guint g_date_get_day_of_year (const GDate *date);
/* First monday/sunday is the start of week 1; if we haven't reached
* that day, return 0. These are not ISO weeks of the year; that
* routine needs to be added.
* these functions return the number of weeks, starting on the
* corrsponding day
*/
guint g_date_get_monday_week_of_year (const GDate *date);
guint g_date_get_sunday_week_of_year (const GDate *date);
guint g_date_get_iso8601_week_of_year (const GDate *date);
[^] # Re: Eté 2007 : il va faire chaud sous les trolls
Posté par IsNotGood . En réponse au journal KDE4.0 : Sortie prévue le 23 octobre !. Évalué à 3.
Pas sûr maintenant que plasma sorte en 2007.
[^] # Re: \o/
Posté par IsNotGood . En réponse au journal Microsoft , une entreprise franchement douteuse.. Évalué à 6.
Ou mais que le fournisseur de l'OS m'impose un moteur de recherche, je comprend moins.
> MSOffice pour la bureautique
Je paie pour MSOffice et non l'inverse.
> Outlook pour le mail
Je paie pour Outlook et non l'inverse.
> CATIA pour ton dev
Je paye pour CATIA et non l'inverse.
Là on a MS qui paie pour qu'on utilise live, et pour interdir google.
C'est de la science fiction. J'ai du mais à y croire tellement c'est gros.
Heureusement que Bill Gates n'est pas président d'un état.
[^] # Re: [:aloy]
Posté par IsNotGood . En réponse au journal Microsoft , une entreprise franchement douteuse.. Évalué à -4.
[^] # Re: Coquille
Posté par IsNotGood . En réponse à la dépêche KDE 4 : publication escomptée en octobre 2007. Évalué à 3.
[^] # Re: côté députés
Posté par IsNotGood . En réponse à la dépêche Vente liée : les politiques s'en mêlent !. Évalué à 1.
Ok ok ok ok...
[^] # Re: Eté 2007 : il va faire chaud sous les trolls
Posté par IsNotGood . En réponse au journal KDE4.0 : Sortie prévue le 23 octobre !. Évalué à 2.
Linuxfr le dit :
http://linuxfr.org/2007/03/22/22260.html
[^] # Re: Eté 2007 : il va faire chaud sous les trolls
Posté par IsNotGood . En réponse au journal KDE4.0 : Sortie prévue le 23 octobre !. Évalué à 1.
Tu peux, je n'ai pas de pointeur sous le coude.
J'ai vu ça dans une discussion sur le planning de sorti de KDE 4.0. En gros plasma passera après kde-pim par exemple. Il n'y a pas que plasma qui ne sera pas dans KDE 4.0. KDE doit sortir rapidement la version 4.0 car des développeurs abandonnent KDE pour aller vers Qt 4.x exclusivement, et qu'au rythme où ça va, KDE 4 risque de sortir après Qt 5.
Ça n'empêchera pas de voir plasma dans KDE 4.1 par exemple.
> En fait actuellement ils en sont à se demander si ils peuvent réaliser Plasma en réutilisant uniquement ce qu'offre Qt ou si ils doivent coder un truc à leur sauce qui sera alors taillé sur mesure pour Plasma
Je vais être mauvaise langue, mais ça craind. Ça fait depuis plus d'un an que plasma fait du buzz. À 6 mois de la sortie KDE 4.0, il n'est pas normal de se demander quelle librairie va être utilisée pour coder plasma.
[^] # Re: Eté 2007 : il va faire chaud sous les trolls
Posté par IsNotGood . En réponse au journal KDE4.0 : Sortie prévue le 23 octobre !. Évalué à 2.
Il ne sera peut-être pas dans KDE 4. Du moins à la sortie de KDE 4. J'ai lu ça je ne sais plus où.
[^] # Re: Coquille
Posté par IsNotGood . En réponse à la dépêche KDE 4 : publication escomptée en octobre 2007. Évalué à 4.
Tu ne le changes pas, tu le traduis.
[^] # Re: Coquille
Posté par IsNotGood . En réponse à la dépêche KDE 4 : publication escomptée en octobre 2007. Évalué à 3.
certaines concessions aux effets visuels, aux fioritures visuelles, artifices visuels.
[^] # Re: Eté 2007 : il va faire chaud sous les trolls
Posté par IsNotGood . En réponse au journal KDE4.0 : Sortie prévue le 23 octobre !. Évalué à 2.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 5.
Si les balises ont des noms compréhensibles, ça aide les développeurs, ça aide les échanges. Un standard qui est difficile pour les développeurs, ce n'est pas in fine un plus pour les utilisateurs.
Si le standard est utilisé que par un logiciel, pourquoi pas.
Mais ODF est utilisé par les développeurs de OOo, KOffice, Abiword, Gnumeric, etc... Comme c'est un standard, il y aura des outils pour convertir en pdf, en html, pour y faire des requêtes, alimenter une base de données, faire de la doc d'API depuis des sources par exemple en C vers ODF, etc...
Il est important que le standard soit accessible aux développeurs. C'est important aussi pour les utilisateurs.
[^] # Re: côté députés
Posté par IsNotGood . En réponse à la dépêche Vente liée : les politiques s'en mêlent !. Évalué à 2.
Il n'y aurait pas moyen d'éviter ce type de commentaire ?
Ils apportent quoi à part acréditer les discours "tous pourris" et "la démocratie ça sucks" ?
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 3.
Tu peux développer ?
Le format OpenXML permet des outils que ne permet pas le format ODF ?
Ou c'est simplement que ces outils n'ont pas encore été développé pour ODF ?
[^] # Re: KDE4.0 : Sortie prévue le 23 octobre !
Posté par IsNotGood . En réponse au journal KDE4.0 : Sortie prévue le 23 octobre !. Évalué à 3.
J'ai survolé les articles QuebecOs (les traductions) et je trouve qu'il y a des choses de Gnome (et d'autres) dans KDE.
SVG n'est bien. Que ce soit dans Gnome ou KDE.
Les icones avec du texte c'est bien. Que ce soit dans Gnome ou KDE.
Il y a quelques idées spécifiques à KDE 4 qui sont bien et que j'aimerai voir dans Gnome.
En survolant les copies d'écran, c'est la première fois que je ne trouve pas KDE moche.
Je parle de Gnome, car j'utilise beaucoup Gnome.
[^] # Re: Prononciation
Posté par IsNotGood . En réponse à la dépêche KDE 4 : publication escomptée en octobre 2007. Évalué à 4.
"Nouveau".
C'est la bonne réponse ?
D'ailleurs j'ignore si "nouveau" se prononce en anglais s'il n'y a pas plus de précision. Pour ce qui est écrit en anglais, il n'est pas toujours facile de savoir comment ça se prononce (il faut un dictionnaire). C'est beaucoup plus rarement le cas en français.
"Qt", je le prononce "Qt". Et toi ?
Quand un truc peu se lire (à haut voix) en français, ben prenons la version française.
Tu dis Ubuntu ou <Ubuntu prononcé par un anglais> ?
Tu dis Linux ou ...
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 2.
Pour W3C, c'est un peu faux. MS voulait laisser tomber html/etc. Mais comme Firefox grimpe, MS a sortit IE7 par exemple.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 3.
Idem
> je me demandais ce qui dans ce format le rendais mal foutu ?
Parce que OpenXML veut offrir une grosse compatibilité avec les fonctionnalités .doc .xls, etc.
Donc les trucs mal foutus des anciens formats se retourne dans OpenXML. Il y a même des parties qui sont des "blobs" sur des formats partiellement documentés (wmf par exemple).
[^] # Re: On sent à peine l'électoralisme...
Posté par IsNotGood . En réponse à la dépêche Réponse de la candidate Marie-George Buffet à Candidats.fr. Évalué à 3.
Un corse peut dire :
- "En effet, on fait il me semble partie de la France qui ne PROPOSE pas mais IMPOSE des LOIS qu'il faut TRANSPOSER. Quel pouvoir de dire non pour un politique ? euh... accepter de payer l'amende."
On fait parti de l'Europe, on participe aux décisions de l'Europe, on y a adhéré librement.