--
Je passe evidemment sur le "fond" du commentaire précédent, qui ne démontre rien tout en prétendant faire de la logique, précisemment parce qu'il n'y a rien a démontrer, et qui enfonce tant de portes ouvertes. Je ne sais pas s'il est venu à l'esprit de ThesmallgamerS qu'un médaille Fields est peu être légèrement plus capable et doué de raisonnement qu'un sombre "imbécile", et que ce qu'il raconte mérite au moins d'être étudié avant de prononcer un jugement attif, rempli de préjugés et hors propos. Apparament il est devenu de bon ton de déblattérer des totologies lourdes d'insinuations sur ce site, alors j'essaie moi aussi de m'y mettre, qui sait, j'aurais peut être des bonnes notes. Sérieusement jettez un oeil au programme "moderne" de "Français", vous aurez des surprises et comprendrez sans doutes pourquoi les momes n'écrivent plus qu'en SMS. (PS: inutile -- ou plutôt devrais-je dire puéril! -- de pointer de potentielles faute dans ce présent commentaire étant donné que c'est un petit jeu sans aucun intérêt)
En fait en parlant de la RFC 2822 (qui remplace la 822) je parle surtout du formatage des headers qui, tel que ladite RFC les décrits, est la manière standard de facto pour tout ce qui est de la forme
Header1: blabla
Header2: foobar
sur internet et ailleurs.
La RFC 2822 en elle même décrit le format des e-mails, mais elle (ou la 822) est référencé par l'HTTP, le SIP, etc... justement en ce qui concerne le format des headers. Et pour les trucs binaires on fait effectivement du base64. cf RFC 2047 et 2045
Étant donné que tu fais un truc en rapport à mon avis tu gagnerais à te taper toute la lecture des RFC 2045 à 2049 de toute manière, qui décrit MIME.
Ya pas que le C dans la vie (ya aussi l'asm ppc et le code objet MIPS mais bon, c'est une autre histoire ...)
Quand aux différences entre langage procédural (type C), et langage orienté objet (C++), elles sont bien minces face aux différences entre un langage impératif et un langage fonctionnel ou bien déclaratif.
Si tu n'as _jamais_ vu d'interet à la POO en dehors de la création de GUI, c'est que tu n'as pas encore assez programmé (ou alors dans des domaines pas assez variés). Amuse toi à faire par exemple de la modélisation géométrique et tu comprendra tout de suite.
Le python est un langage très attrayant. Il permet de faire allègrement du procédural, de l'objet, un peu de fonctionnel (voir beaucoup selon l'humeur, mais quelque fois peut efficace si on force trop la dose, il faut de temps en temps garder le comportement lié à l'impératif qui reste plus utilisé par les développeur python en tête pour ne pas coder un truc qui va ramer), utilise intensément le duck typing, permet de faire de l'introspection extrêmement dynamique.
Qu'en aux cours de programmation pour débutant, n'importe quel langage permettant d'illustrer le concept d'algorithme peut faire l'affaire (d'ailleurs Python en est un excellent pour le coup). Puis tant qu'à faire autant illustrer le plus vite possible les autres concepts de programmation et faire de l'OCaml / Prolog / etc... le plus tot possible histoire de pas être biaisé par le tout impératif.
Quand au langage D, c'est sans doute un bon langage quand on vient du Python. Perso ya quelques point qui me chagrinent un peu et aussi le support dans le monde du LL est assez léger (c'est ptet dommage, ça).
Ce que j'aime bien : tout ce que tu as cité.
+ le support des closures et quelques autres constructions autorisant du code évolutif et très modulaire.
Ce que j'aime moins :
Features To Drop (<- donc pas dans le D) :
# Support for 16 bit computers. No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space. D will fit smoothly into 64 bit architectures. <-- limitation un peu arbitraire à mon gout, peut etre que le choix a été fait avec lhorrible mode 16 bits des X86 en tete, mais il est dommage de se couper de tout un domaine de l'embarqué.
+ writefln est un nom ridicule (mais printf aussi, sauf que printf était la avant ;)))
Les exceptions que peuvent lever les fonctions n'ont pas l'air d'être spécifiable dans une white list. C'est dangereux dans certain cas, et ca peut aussi parfois etre moins pratique que des codes d'erreurs du coup.
La syntaxe des contrats est inutile à mon gout, (le concept de contrat un peu moins, sauf que ca existait déjà avant que le terme soit "inventé") d'autant que tester ne serait ce que des invariants de boucle est essentiel si on veut un vague semblant de sureté et que la syntaxe est super lourde pour faire ça.
Certaines limitations sont bizarres, on dirait que les concepteur du compilo ont buté sur un pb qu'ils ont pas su régler :
ex. Pas de récurrence croisé entre des constructeurs de signature différente d'une même classe. (je crois pas que ca soit interdit en C++, mais faut être pervers pour en avoir besoin de toute façon)
Le concept de Nested Class n'est pas vraiment utile sans closure sur les classes en question et sans dynamicité des types et de types first class citizen, ce qui n'est pas à l'ordre du jour du fait même de ce que D cible comme implémentation. Ils auraient donc mieux fait de ne pas faire de Nested Class du tout.
Le type de 128 bits (reservé pour usage futur) est bizarre : sans faire de SIMD, le besoin en taille de mot vient plus de l'adressage mémoire que des capa de calcul, et on verrait mal un processeur généraliste implémenter des mots de 128 bits juste pour optimiser les calculs sur les entiers long vu le cout que ca aurait.
Certaines constructions sont curieuses :
struct S
{ int x;
invariant int y;
}
(avec l'allocation de y qui est en fait de plus potentiellement déportée)
Enfin certains points du site oueb énoncent des affirmations catégorique sur des sujets soumis à caution et j'ai typiquement horreur de ce genre de chose. Manque d'esprit critique ! bouh c'est mal :P
En conclusion je pense que D est un langage respectable mais on a la sensation d'un langage plutôt conséquent mais concu par trop peu de monde, contrairement à Python par exemple ou les nouveautés sont toujours incluse de manière à ne rien déstabiliser et à garder une grande cohérence, voir à augmenter la cohérence.
Bref j'ai un arrière gout de petit manque de cohérence pour le D, qui peut être aurait gagné a être encore un peu plus épuré tout en incluant quelques constructions "acédémiques" évoluées supplémentaires (une petite touche fonctionnelle ? ;), sans toutefois que ce petit manque soit rédhibitoire.
Ocaml a été rapidement éliminé car je me suis vite rendu compte qu'il serait beaucoup trop long à apprendre pour quelqu'un comme moi dont la programmation n'est pas le métier. J'ai tout de même été déçu de ne pas pouvoir consacrer plus de temps à l'étude de ce langage.
Ça dépend... Si tu es mathématicien tu aura peut-être plus de facilité à apprendre un langage fonctionnel qu'un langage impératif. Peut-être aussi que la tendance s'inverse si tu es responsable qualité (faudrait faire des stats :p)
je peux te garantir qu'en entreprise, c'est quasiment mission impossible de respecter scrupuleusement la GPL.
HEIN?
Et moi je peux garantir que non.
L'alternative serait de ne pas utiliser du tout de code en GPL, mais ce serait vraiment dommage.
Euh, pourquoi ???
Si on est incapable d'utiliser du code en GPL parce que c'est trop dur de respecter la licence (ou impossible à cause de loi locale ou whatever), on n'en utilise pas, c'est tout. No surrender, touca... Et entre les bibliothèque proprio et les libres sans copyleft, c'est pas le code qui manque pour les remplacer par autre chose au besoin.
Ca n'est pas "dommage" c'est le respect de la volonté de l'auteur (sauf si c'est ton meilleur pote t'es bien obligé de t'en tenir à une interprétation stricte des droits qu'il te donne par écrit...)
Apple a très bien réussi jusqu'à qu'ils se mettent à conseiller dans leur guidelines à peu près aux début d'OS X d'arreter de faire les chose intelligemment et de plutôt considérer les extensions, comme "tout le monde".
Le gros problème c'est qu'en passant d'un truc purement proprio à un truc basé sur Posix, il ne pouvait plus s'amuser à dire que les type de fichiers seraient gérés comme ça et JAMAIS autrement.
Ca illustre bien le poids de l'existant et à mon avis pour qu'un système standard spécifiant des méta donnés arrive à prendre, faut que ça s'intègre facilement et efficace sur un système ou ça n'a pas du tout été prévu à l'origine, et à mon avis rajouter un header au payload des fichiers ne satisfera jamais cette condition.
Ya déjà pleins de systèmes de fichiers qui supportent des attributs étendus/perso/etc et autres petits trucs sympa comme les fork (NTFS ou HFS+, sur un système de fichier Linux je sais pas trop).
Malheureusement c'est vrai que les solutions existantes pour les méta données sont pas vraiment 100% compatible les unes avec les autres, mais pour faire un truc efficace et susceptible de prendre il faut commencer par étudier ce qui existe déjà et être sur que ça peut s'intégrer efficacement et simplement avec tous les systèmes, surtout quand ils sont pas prévu pour à l'origine.
En outre ton format limite l'évolutivité sans raison apparente (il faudrait au minimum prévoir la possibilité d'ajouter des headers valide d'interprétation non obligatoire dans le format que les anciennes implémentations seraient susceptible d'ignorer) et de plus le seul header spécifié vraiment important est Content-Type ce qui un peu léger à l'époque où les environnement dominant ont tous des solutions d'indexation de méta données... d'ailleurs au dela de la description du format de fichier il faudra une spécification plus importante de l'intégration à l'existant et des recommendations pour la mise en application sur de nouveaux systèmes.
Enfin, les fichiers de descriptions "inclus" me semblent peu intéressants tels que décrits ici dans la mesure ou leur content type masque celui du payload et qu'ils sont donc incompatible avec l'existant. L'idéal serait de les stocker dans un fork sur les systèmes qui supportent, sauf que de tels système mémorisent généralement déjà le content-type ou équivalent comme des grands, donc ca limite l'interet.
Enfin ton format ressemble à celui de la RFC 2822 tout en étant incompatible ce qui est plutôt génant. Il serait préférable de tout simplement référencer la RFC 2822 histoire de ne pas réinventer la roue ni obliger de réimplementer avec du nouveau code des parser et générateurs justes un poil pas pareil.
Apple est doué en ergonomie et pour faire des produit avec un design sympa. OK.
Est-ce que ça justifie le fait de vendre un téléphone de merde à 600 euros ? Je ne pense pas. Maintenant si ya des gens qui ont envie de l'acheter, c'est leur problème. Ils feraient quand même mieux d'exiger un petit diamant et des dorures à ce prix là :P
C'est quoi l'interet d'utiliser une techno de communication pour faire de la bureautique ? La multiplication des couches pour faire ramer le tout toujours plus ? L'absence de standard completement implémenté de rendu pour être sûr d'obtenir des résultats légèrement ou complètement différents d'une machine à l'autre ? Donner du boulot aux dev de mozilla ? :p
Debian est (pas que!) une grosse bureaucratie pointilleuse sur la définition de "libre". C'est un très bon garde fou contre la propriétarisation du libre. Cela engendre quelquefois des réactions un peu violentes. Toujours est-il qu'un accord avec la fondation Mozilla n'était pas souhaitable car cela aurait necessité de changer radicalement les règles du jeu d'un coté ou de l'autre, ce à quoi personne n'était prêt...
Finalement Debian fait ce qu'il veut sur sur Iceweasel et en quelque sorte respecte le branding de la MoFo en ne lui faisant subir rien de contraire à leur désirs, et la MoFo n'a aucune raison d'avoir peur que leur marque soit mal utilisée par Debian, ou par quelqu'un d'autre à cause de Debian. Tout le monde est content.
Et je ne crois pas que Firefox subisse de glissement majeur vers le non-libre pour autant.
ok, les techos de MS s'améliorent (quoiqu'à voir Vista ;p ) et on peut dire que c'est une bonne nouvelle, pcq les windows zomby et autres os défoncés qui servent à tout et n'importe quoi a une bande de dégénérés, ca regarde pas vraiment la couleur de ton OS pour te peter les burnes.
Maintenant j'ai aussi lu attentivement les "case study" de MS sur les boites qui "reviennent" à windows server apres avoir tenté Linux, et je peux crieer haut et fort que le marketing chez MS, ca se détériore sérieusement...
Ceci étant tant que ca convainc quelques clients, c'est ca qui compte, nan ? :)
C'est bien beau ton raisonnement, mais tu ne possèdes pas Windows en achetant une license, du coup tout tombe à l'eau... Dommage hein ? (enfin pas pour les détaxeurs... :)
En plus les DRM pour prendre soin de la sécurité des utilisateurs qui sont trop cons... On a l'habitude d'entendre ce discours, mais en général ca vient d'ailleurs... :/
On va dire pour rester poli que le scheduler de windows est inutilement complexe et bien peu performant en terme de critères classiques de mesure de performance de scheduler :p
Alors si en plus maintenant MS le modifie... Enfin nan je suis mauvaise langue, il est tellement obscure qu'ils osent plus le modifier ; ils rajoutent du code pour modifier dynamiquement les priorités selon une politique X ou Y pour qu'on obtienne un comportement pas trop pourrav étant donné leur schéduler existant...
The ability to restrict audio outputs (e.g., S/PDIF) for certain types of content has been available since Windows Millennium Edition (ME) and has been available in all subsequent versions of Windows.
Qu'elle merveilleuse feature :))
(bon ok MS est bloqué par les prod., toussa, je sais... en même temps s'ils leur disaient qu'ils sont completement tarés, je suis pas sûr que l'industrie du divertissement puisse se passer du marché des PC sous Win.)
"Énorme bout de code buggué" me viens plus souvent à l'esprit quand j'entends "openoffice" ou "mozilla (firefox, thunderbird)", plutôt que "logiciel de qualité"
Enfin bon peut-être que sous Windows ça fonctionne mieux ? :p
Ceci étant dit pour quelqu'un qui attends sagement que le soft arrete de bosser pour passer son prochain clic, ça doit à peu près fonctionner. Bref c'est surrement bourré de graves problèmes de synchro et comme d'hab dans ce genre de truc il en plus probable que seuls 10% aient été rencontrés par le parc d'utilisateurs...
[^] # Re: Mouaif
Posté par Guillaume Knispel . En réponse au journal La dégradation de l'enseignement. Évalué à 4.
--
Je passe evidemment sur le "fond" du commentaire précédent, qui ne démontre rien tout en prétendant faire de la logique, précisemment parce qu'il n'y a rien a démontrer, et qui enfonce tant de portes ouvertes. Je ne sais pas s'il est venu à l'esprit de ThesmallgamerS qu'un médaille Fields est peu être légèrement plus capable et doué de raisonnement qu'un sombre "imbécile", et que ce qu'il raconte mérite au moins d'être étudié avant de prononcer un jugement attif, rempli de préjugés et hors propos. Apparament il est devenu de bon ton de déblattérer des totologies lourdes d'insinuations sur ce site, alors j'essaie moi aussi de m'y mettre, qui sait, j'aurais peut être des bonnes notes. Sérieusement jettez un oeil au programme "moderne" de "Français", vous aurez des surprises et comprendrez sans doutes pourquoi les momes n'écrivent plus qu'en SMS. (PS: inutile -- ou plutôt devrais-je dire puéril! -- de pointer de potentielles faute dans ce présent commentaire étant donné que c'est un petit jeu sans aucun intérêt)
[^] # Re: Toujours aussi étrange...
Posté par Guillaume Knispel . En réponse au journal Tiscali contraint au filtrage. Évalué à 1.
C'est cool la justice finalement ;)
[^] # Re: NIH
Posté par Guillaume Knispel . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Header1: blabla
Header2: foobar
sur internet et ailleurs.
La RFC 2822 en elle même décrit le format des e-mails, mais elle (ou la 822) est référencé par l'HTTP, le SIP, etc... justement en ce qui concerne le format des headers. Et pour les trucs binaires on fait effectivement du base64. cf RFC 2047 et 2045
Étant donné que tu fais un truc en rapport à mon avis tu gagnerais à te taper toute la lecture des RFC 2045 à 2049 de toute manière, qui décrit MIME.
[^] # Re: peut etre que...
Posté par Guillaume Knispel . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 6.
Quand aux différences entre langage procédural (type C), et langage orienté objet (C++), elles sont bien minces face aux différences entre un langage impératif et un langage fonctionnel ou bien déclaratif.
Si tu n'as _jamais_ vu d'interet à la POO en dehors de la création de GUI, c'est que tu n'as pas encore assez programmé (ou alors dans des domaines pas assez variés). Amuse toi à faire par exemple de la modélisation géométrique et tu comprendra tout de suite.
Le python est un langage très attrayant. Il permet de faire allègrement du procédural, de l'objet, un peu de fonctionnel (voir beaucoup selon l'humeur, mais quelque fois peut efficace si on force trop la dose, il faut de temps en temps garder le comportement lié à l'impératif qui reste plus utilisé par les développeur python en tête pour ne pas coder un truc qui va ramer), utilise intensément le duck typing, permet de faire de l'introspection extrêmement dynamique.
Qu'en aux cours de programmation pour débutant, n'importe quel langage permettant d'illustrer le concept d'algorithme peut faire l'affaire (d'ailleurs Python en est un excellent pour le coup). Puis tant qu'à faire autant illustrer le plus vite possible les autres concepts de programmation et faire de l'OCaml / Prolog / etc... le plus tot possible histoire de pas être biaisé par le tout impératif.
Quand au langage D, c'est sans doute un bon langage quand on vient du Python. Perso ya quelques point qui me chagrinent un peu et aussi le support dans le monde du LL est assez léger (c'est ptet dommage, ça).
Ce que j'aime bien : tout ce que tu as cité.
+ le support des closures et quelques autres constructions autorisant du code évolutif et très modulaire.
Ce que j'aime moins :
Features To Drop (<- donc pas dans le D) :
# Support for 16 bit computers. No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space. D will fit smoothly into 64 bit architectures. <-- limitation un peu arbitraire à mon gout, peut etre que le choix a été fait avec lhorrible mode 16 bits des X86 en tete, mais il est dommage de se couper de tout un domaine de l'embarqué.
+ writefln est un nom ridicule (mais printf aussi, sauf que printf était la avant ;)))
Les exceptions que peuvent lever les fonctions n'ont pas l'air d'être spécifiable dans une white list. C'est dangereux dans certain cas, et ca peut aussi parfois etre moins pratique que des codes d'erreurs du coup.
La syntaxe des contrats est inutile à mon gout, (le concept de contrat un peu moins, sauf que ca existait déjà avant que le terme soit "inventé") d'autant que tester ne serait ce que des invariants de boucle est essentiel si on veut un vague semblant de sureté et que la syntaxe est super lourde pour faire ça.
Certaines limitations sont bizarres, on dirait que les concepteur du compilo ont buté sur un pb qu'ils ont pas su régler :
ex. Pas de récurrence croisé entre des constructeurs de signature différente d'une même classe. (je crois pas que ca soit interdit en C++, mais faut être pervers pour en avoir besoin de toute façon)
Le concept de Nested Class n'est pas vraiment utile sans closure sur les classes en question et sans dynamicité des types et de types first class citizen, ce qui n'est pas à l'ordre du jour du fait même de ce que D cible comme implémentation. Ils auraient donc mieux fait de ne pas faire de Nested Class du tout.
Le type de 128 bits (reservé pour usage futur) est bizarre : sans faire de SIMD, le besoin en taille de mot vient plus de l'adressage mémoire que des capa de calcul, et on verrait mal un processeur généraliste implémenter des mots de 128 bits juste pour optimiser les calculs sur les entiers long vu le cout que ca aurait.
Certaines constructions sont curieuses :
struct S
{ int x;
invariant int y;
}
(avec l'allocation de y qui est en fait de plus potentiellement déportée)
Enfin certains points du site oueb énoncent des affirmations catégorique sur des sujets soumis à caution et j'ai typiquement horreur de ce genre de chose. Manque d'esprit critique ! bouh c'est mal :P
En conclusion je pense que D est un langage respectable mais on a la sensation d'un langage plutôt conséquent mais concu par trop peu de monde, contrairement à Python par exemple ou les nouveautés sont toujours incluse de manière à ne rien déstabiliser et à garder une grande cohérence, voir à augmenter la cohérence.
Bref j'ai un arrière gout de petit manque de cohérence pour le D, qui peut être aurait gagné a être encore un peu plus épuré tout en incluant quelques constructions "acédémiques" évoluées supplémentaires (une petite touche fonctionnelle ? ;), sans toutefois que ce petit manque soit rédhibitoire.
# OCaml
Posté par Guillaume Knispel . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 3.
Ça dépend... Si tu es mathématicien tu aura peut-être plus de facilité à apprendre un langage fonctionnel qu'un langage impératif. Peut-être aussi que la tendance s'inverse si tu es responsable qualité (faudrait faire des stats :p)
[^] # Re: Réponse
Posté par Guillaume Knispel . En réponse au journal Violation de la GPL sur VMime ?. Évalué à 3.
mouahahahahha
[^] # Re: Réponse
Posté par Guillaume Knispel . En réponse au journal Violation de la GPL sur VMime ?. Évalué à 4.
HEIN?
Et moi je peux garantir que non.
L'alternative serait de ne pas utiliser du tout de code en GPL, mais ce serait vraiment dommage.
Euh, pourquoi ???
Si on est incapable d'utiliser du code en GPL parce que c'est trop dur de respecter la licence (ou impossible à cause de loi locale ou whatever), on n'en utilise pas, c'est tout. No surrender, touca... Et entre les bibliothèque proprio et les libres sans copyleft, c'est pas le code qui manque pour les remplacer par autre chose au besoin.
Ca n'est pas "dommage" c'est le respect de la volonté de l'auteur (sauf si c'est ton meilleur pote t'es bien obligé de t'en tenir à une interprétation stricte des droits qu'il te donne par écrit...)
[^] # Re: je n'ai pas tout lu mais...
Posté par Guillaume Knispel . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Le gros problème c'est qu'en passant d'un truc purement proprio à un truc basé sur Posix, il ne pouvait plus s'amuser à dire que les type de fichiers seraient gérés comme ça et JAMAIS autrement.
Ca illustre bien le poids de l'existant et à mon avis pour qu'un système standard spécifiant des méta donnés arrive à prendre, faut que ça s'intègre facilement et efficace sur un système ou ça n'a pas du tout été prévu à l'origine, et à mon avis rajouter un header au payload des fichiers ne satisfera jamais cette condition.
# NIH
Posté par Guillaume Knispel . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Malheureusement c'est vrai que les solutions existantes pour les méta données sont pas vraiment 100% compatible les unes avec les autres, mais pour faire un truc efficace et susceptible de prendre il faut commencer par étudier ce qui existe déjà et être sur que ça peut s'intégrer efficacement et simplement avec tous les systèmes, surtout quand ils sont pas prévu pour à l'origine.
En outre ton format limite l'évolutivité sans raison apparente (il faudrait au minimum prévoir la possibilité d'ajouter des headers valide d'interprétation non obligatoire dans le format que les anciennes implémentations seraient susceptible d'ignorer) et de plus le seul header spécifié vraiment important est Content-Type ce qui un peu léger à l'époque où les environnement dominant ont tous des solutions d'indexation de méta données... d'ailleurs au dela de la description du format de fichier il faudra une spécification plus importante de l'intégration à l'existant et des recommendations pour la mise en application sur de nouveaux systèmes.
Enfin, les fichiers de descriptions "inclus" me semblent peu intéressants tels que décrits ici dans la mesure ou leur content type masque celui du payload et qu'ils sont donc incompatible avec l'existant. L'idéal serait de les stocker dans un fork sur les systèmes qui supportent, sauf que de tels système mémorisent généralement déjà le content-type ou équivalent comme des grands, donc ca limite l'interet.
Enfin ton format ressemble à celui de la RFC 2822 tout en étant incompatible ce qui est plutôt génant. Il serait préférable de tout simplement référencer la RFC 2822 histoire de ne pas réinventer la roue ni obliger de réimplementer avec du nouveau code des parser et générateurs justes un poil pas pareil.
[^] # Re: Encore un truc du visionnaire
Posté par Guillaume Knispel . En réponse au journal L'Iphone : Révolution culturelle ou simple coup de génie ?. Évalué à 1.
Est-ce que ça justifie le fait de vendre un téléphone de merde à 600 euros ? Je ne pense pas. Maintenant si ya des gens qui ont envie de l'acheter, c'est leur problème. Ils feraient quand même mieux d'exiger un petit diamant et des dorures à ce prix là :P
# Bonne idée à la base ???
Posté par Guillaume Knispel . En réponse au journal Google Gears, le retour de l'incompatibilité des navigateurs Web. Évalué à 0.
[^] # Re: Sens du commentaire
Posté par Guillaume Knispel . En réponse au journal Dans quel secteur travaillez vous ?. Évalué à 1.
[^] # Re: L'oeuf et la poule...
Posté par Guillaume Knispel . En réponse au journal [HS] Détente CV d'"informaticien". Évalué à 3.
[^] # Re: c'est la vie
Posté par Guillaume Knispel . En réponse au journal La qualité des journaux ET DES COMMENTAIRES. Évalué à 5.
Finalement Debian fait ce qu'il veut sur sur Iceweasel et en quelque sorte respecte le branding de la MoFo en ne lui faisant subir rien de contraire à leur désirs, et la MoFo n'a aucune raison d'avoir peur que leur marque soit mal utilisée par Debian, ou par quelqu'un d'autre à cause de Debian. Tout le monde est content.
Et je ne crois pas que Firefox subisse de glissement majeur vers le non-libre pour autant.
# kikoo lol
Posté par Guillaume Knispel . En réponse au journal La qualité des journaux ET DES COMMENTAIRES. Évalué à 4.
C'est rédhibitoire pour pas mal de monde...
[^] # Re: Gonflé
Posté par Guillaume Knispel . En réponse au journal Pourquoi les entreprises qui essaient Linux reviennent-elles à Windows Server ?. Évalué à 2.
Maintenant j'ai aussi lu attentivement les "case study" de MS sur les boites qui "reviennent" à windows server apres avoir tenté Linux, et je peux crieer haut et fort que le marketing chez MS, ca se détériore sérieusement...
Ceci étant tant que ca convainc quelques clients, c'est ca qui compte, nan ? :)
# quelle réponse??
Posté par Guillaume Knispel . En réponse au journal Joost : quelle réponse du libre ?. Évalué à 2.
[^] # Re: Pour la première fois, je fais aussi un choix de conviction...
Posté par Guillaume Knispel . En réponse au journal Christophe Espern appelle à voter Bayrou. Évalué à 3.
# bof
Posté par Guillaume Knispel . En réponse au journal Est-ce légitime de dénoncer la "vente liée".. Évalué à 3.
[^] # Re: Pessimisme
Posté par Guillaume Knispel . En réponse à la dépêche Bitfrost : Un nouveau modèle de sécurité. Évalué à 6.
[^] # Re: Les windows fanboys errent sur ce journal !!
Posté par Guillaume Knispel . En réponse à la dépêche Comparatif Vista / Linux pour les performances des jeux. Évalué à 4.
Aller les enfants, soyez gentils, arretez de vous chamailler :)
[^] # Re: Les windows fanboys errent sur ce journal !!
Posté par Guillaume Knispel . En réponse à la dépêche Comparatif Vista / Linux pour les performances des jeux. Évalué à 4.
[^] # Re: Pour les ignorants.
Posté par Guillaume Knispel . En réponse au journal Windows Vista Internals. Évalué à 1.
Alors si en plus maintenant MS le modifie... Enfin nan je suis mauvaise langue, il est tellement obscure qu'ils osent plus le modifier ; ils rajoutent du code pour modifier dynamiquement les priorités selon une politique X ou Y pour qu'on obtienne un comportement pas trop pourrav étant donné leur schéduler existant...
# Capacité de bloquer... :p
Posté par Guillaume Knispel . En réponse au journal Microsoft promet de ne pas achever les gens malades avec Vista. Évalué à 3.
Qu'elle merveilleuse feature :))
(bon ok MS est bloqué par les prod., toussa, je sais... en même temps s'ils leur disaient qu'ils sont completement tarés, je suis pas sûr que l'industrie du divertissement puisse se passer du marché des PC sous Win.)
[^] # Re: Philosophie
Posté par Guillaume Knispel . En réponse au journal Precher le libre.. Évalué à -1.
Enfin bon peut-être que sous Windows ça fonctionne mieux ? :p
Ceci étant dit pour quelqu'un qui attends sagement que le soft arrete de bosser pour passer son prochain clic, ça doit à peu près fonctionner. Bref c'est surrement bourré de graves problèmes de synchro et comme d'hab dans ce genre de truc il en plus probable que seuls 10% aient été rencontrés par le parc d'utilisateurs...