Jerome Herman a écrit 1870 commentaires

Une petite question métaphysique m'a traversé l'esprit ce soir : Comment les codeurs codent avec du code flottant ?

Réponse de gascon : Ca dépend du code.
En fait il y a plusieurs cas de figures :
- Ranapété : Je me fous de ce que font les flottants dans la mesure ou ils me donnent un résultat suffisament juste rapidement. C'est le cas par exemple en programmation 3D (ou on peut toujours s'arranger à posteriori pour éliminer les cas problématiques en corrigeant les cartes ou les modèles 3D
Par exemple la plupart des moteurs de Carmak ont de gros problèmes de Z aliasing, mais ca ne se voit pas sur les cartes car les cas à problème sont soigneusement évités) C'est aussi le cas dans évaluation biologique (ou la norme sanitaire est entre 10 at 1000 fois inférieure à la dose toxique, donc on se moque un peu de savoir si on a 0,0800 µg de saleté ou 0,07999954215 ) et dans la plupart des calculs fait à partir de prélèvement capteurs en temps réel (le capteur a une précision de 0,01 alors le 17ème chiffre après la décimale est de toutes les façons faux)

- Ranapété du moment que ca concorde : Là je me moque de savoir ce que font les décimales parceque 1°) de toutes les façon au final je vais arrondir 2°) j'ai largement assez de précision pour m'en sortir et/ou 3°) de toutes les façon je suis sur des valeurs qui fluctuent tellement que je vais me mettre d'accord avec un tiers et qu'on va fixer ensemble un résultat de connivence. Tout ce qui m'interesse c'ets qu'à la fin de la journée j'ai des résultat cohérent avec mes choix et vérifiables par une authorité.
par exemple une comptabilité en francs que je veux passer en euros. Il faut juste que la somme de toutes mes opérations converties en euros soit égale au réel des comptes converti en euros. En d'autres termes si Somme(Ai)=B je veux Somme(conv(Ai))=conv(B) avec une fonction de converion conv() qui soit identique d'un coté et de l'autre de l'opération et qui soit normalisée et approuvée par un organisme de controle le cas échéant. C'est ce qui se passe dans les chambres de compensation internationales quand les entiers à décimales fixées commencent à plus en pouvoir (additionner des centainnes de milliers d'opérations au dix-milième d'euros près ca devient coton)

- Ca serait bien que deux ordinateurs différents trouvent le même résultat.
La le truc c'est pas vraiment que l'on veuille que résultat soit super précis, on veut juste qu'il soit vérifiable. En d'autres termes si une suite de calculs donne come résultat 0.73244298 ca serait bien que la même suite d'opération donne le même résultat sur l'ordinateur d'a coté. Pourquoi ? parceque ca permet de savoir que l'on est pas en train d'atteindre une condition limite (genre quand on trouve des résultats trop différents d'un ordinateur à l'autre, il est temps de changer d'algorithme), ca permet de vérifier qu'un ordi n'est pas en train de rendre l'ame (tiens ca fait quatre fois que l'ordi 1 trouve un résultat qui diverge, apelle le broker je signe le certificat de décès) ou qu'un bit d'execution ou de données n'a pas été perturbé par un effet magnétique farceur (rarissime mais réel sur terre, plus courant dans les satellites et autres engins spatiaux) etc. C'est là que les IEEE rentrent en ligne de compte en faisant un choix abitraire parfois faux, mais vérifiable.

- 100% pure vraies décimales dedans. Là il s'agit de ne pas faire d'erreur d'arrondi du tout. En d'autres termes l'arrondi n'est fait que sur la dernière décimale stoquée et seulement au moment de stoquer le résultat final. C'est là que les entiers 64 bits calculés sur 80 bits rendent bien service. En d'autres termes on rentre des chiffres exacts avec une précision x, tous les calculs sont faits en précision y (y > x) suffisament grande pour qu'il n'y ait pas de perte d'information avant que les calculs ne soient finis. Et quand les calculs sont finis on repasse en précision x avec un arrondi dans les règles de l'art. Là le boulot du programmeur et de vérifier que l'on ne peut pas perdre d'information dans les opérations avant la sortie du résultat. C'est ce que l'on a dans les calculs par éléments finis simple, ou dans les simulations moléculaires limitées a quelques atomes/molécules. Ce qui nous ammène a l'utilisation la plus chiante des flottants :

- Bonjour, j'additionne des fourmis avec des éléphants.
Là on a des trucs du style 45E32 + 0.1E-14 + 0.2E-12 + 0.4E-12 + ... (plusieurs centaines de millions de nombre à faible exposant) ...+ 0.7E-11
Laissé à lui même avec des arrondis classiques l'ordinateur donnera un résultat très différents suivant l'ordre dans lequel il effectuera les opération.
Dans pas mal de cas on peut s'en sortir de façon élégante en prioritisant les opérations. C'est à dire en n'essayant d'éviter de faire des opérations entre des nombres qui ne sont pas du même ordre. En d'autres termes on garde l'unité flottante du processeur, mais on lui passe les opérations dans le bon ordre pour que ca se passe bien. Dans les autres cas il faut faire autrement. Par exemple faire appel à des bibliothèques extérieures boostées, faire mumuse avec les registres, la carry et les différents flags soi-même ou passer par des modes de calculs différents (en passant sur des entiers très long ou en utilisant des fonctions vectorielles ou encore ou faisant les opérations sur des "blocs" de précisions différentes que l'on récolle à la fin.)

Bref, ca dépend du problème à résoudre. De façon générale les calculs en flottants sont casse-pieds, on évite donc autant que possible. Et quand on est obligé de s'en servir (pour des raisons de vitesse ou de précision) on ne surveille les décimales que si on en a vraiment, vraiment besoin.

Parcequ'on pourrait utiliser le meme genre d'astuce pour utiliser une librairie en GPL dans un logiciel proprio, le cas est aborde dans la FAQ de la FSF, et il est clairement dit que c'est une violation de la GPL.

Pour qu'il y ait violation de la GPL il faut que certaines conditions soient remplies, il est parfaitement possible de faire dialoguer du code GPL avec un module propriétaire si :
- Le code source GPL est suffisant pour avoir une application fonctionnelle en mode stand alone (même si il lui manque des options)
- Le module propriétaire est indépendant du programme licencié sous GPL et est suffisament générique pour pouvoir être invoqué par d'autres programmes
- L'interface de dialogue du coté programme sous GPL est ouvert du point de vue des sources et non encombré de brevets.

Dans les faits des centaines de programmes sous GPL sont capable de lier et d'utiliser, par exemple, les pilotes de bases de données Oracle sans que celà pose le moindre problème en regard de la licence.

Rien n'interdit depuis un programme GPL d'invoquer un objet propriétaire, de dialoguer via SHM/Named Pipes/socket etc. avec un objet propriétaire ou même de se lier à l'execution avec un objet propriétaire (ce dernier cas est beaucoup plus casse gueule, mais on peut citer en exemple les modules pilotes propriétaires qui se lient au noyeau Linux)

Pratiquement, cette licence va faire en sorte que les projet seront renforcés, par la contrainte, dans un cadre communautaire en forçant la redistribution de l'application modifiée dès que celle-ci est utilisée publiquement.

Je pense que c'est l'idée derrière cette licence, seulement de même qu'il est possible de dire pour la GPL que le logiciel n'a pas été distribué et que la machine sur lequel il tourne appartient toujours à la société d'origine, il est également possible d'écrire un proxy (au sens large) propriétaire et de dire que l'utilisateur interagit non pas avec le logiciel sous licence AGPL mais avec le proxy. Autre solution créer une interface de dialogue vers l'extérieur dans le logiciel AGPL et mettre les fonctionnalités proprios en stand alone en dehors du logiciel sous AGPL. L'obligation de redistribution du code source n'a alors d'autre effet que de faire connaitre le source de l'interface de dialogue.

Si je développe un serveur Web, je suis en droit de demander le code source du navigateur qui l'utilisera ?

Seulement si le navigateur est sous licence AGPL ou est basé sur des sources sous licence AGPL (mais alors il est AGPL de facto pour l'instant, peut-être que le distinguo servira quand il y aura une GPLv4 ou une AGPL v2 ou une autre licence compatible AGPL dans les deux sens)

Dès lors, nier l'existence d'une "distribution", c'est admettre que l'on est en porte-à-faux vis à vis de la GPL 2.

Euh, Je ne suis pas sur d'avoir suivi ta logique. mais si j'ai bien compris pour toi la GPL v2 n'autorise la modification que si il y distribution. C'est inexact. La GPLv2 authorise les modifications mais oblige à les divulguer si il y a distribution. Sans celà aucun des contributeurs du libre n'auraient le droit de modifier du code GPLv2 sans distribuer leurs modifications d'abord... Pas facile.
La question reste donc de savoir si il y a distribution ou pas...

Je ne suis pas allé explorer les formats en question, mais dans l'absolu, rien ne t'empêche d'écrire explicitement dans un papier que tel ou tel bloc de données doit être mouliné avec un composant ActiveX ou autre, que l'on invoquerait avec une API écrite d'une manière particulière. Dès lors, le résultat escompté ne peut pas être déduit de la simple norme, et si les spécifications du composant concerné ne sont, elles, pas accessibles

Dans ce cas, la norme ne t'explique pas comment lire le format. Il ne faut pas confondre les documentations qui existent sur un format avec le format lui même. Si la norme te dit que pour lire tel ou tel format tu dois acheter des licences, du code ou même utiliser des binaires spécifiques, alors il te suffit de ne pas respecter la norme pour lire le format. Un bon exemple est la lecture de DVD vidéos, la norme stipule pleins de choses, ce qui n'empêche pas DeCSS de lire quand même le format sans pour autant respecter la norme.

alors le format proprement dit est enfermé, et ce sans avoir écrit la moindre ligne de code ...

Le format est enfermé parceque non doccumenté. Il est complexe d'interpreter un format pour lequel on a pas les docs (mais pas totalement impossible). Par contre le format n'est en aucun cas lié à une plateforme. C'est juste que les personnes qui tiennent les clefs du format ne veulent pas faire de versions qui tourneraient sur une autre plateforme. Une fois de plus le format n'y est pour rien.

Et après ça,on PBPG viendra sans doute nous dire que l'OOXML c'est un format indépendant de la plateforme (sic)

Loin de moi l'idée de jouer les défenseurs de PBPG (il se défend remarquablement bien tout seul), mais il va falloir m'expliquer ce qu'est un format dépendant d'une plateforme. Que l'implémentatin, le code ou encore les binaires soient dépendant je veux bien. Que le support hardware ne soit pas suffisant sur les plateformes concurrentes pour permettre des poirtages ou des implémentations passe encore. A la limite que des brevets te "bloquent" le droit légal d'utiliser certaines techniques sur ce qui n'est pas la plateforme officielle OK. Mais le format lui, il y est pour rien. C'est pas parceque sous windows il faut utiliser des ActiveX pour lire le SVG que le format SVG nécessite des ActiveX pour être lu...

Alors que si GIMP exportait en CMJN tout irait bien.

Ouais, faut le dire vite. Il faudrait aussi que les utilisateurs calibrent un tant soit peu leurs moniteurs (Parceque le mec pour qui le rendu de référence est sur un LCD en température de couleur à 9200 et un gamma qui tourne à 2.4, il va forcément avoir une sale surprise lors de la livraison de la version papier).
Idéalement il faudrait aussi que les graphistes se rendent comptent que les effets de scintillement (surrouge, survert, tramage rouge/vert ou brulages blancs bordés de bleu ou de violet) ne passent pas sur papier, ou alors sur certains papiers glacés avec des encres spéciales, mais là ca va faire très mal au portefeuille sur de petits tirages.

Le CMJN ca reste quand même une affaire de pro. Les schéma de conversions automatiques sont le plus souvent comme tu le disais assez dégueulasse. La conversion Adobe pour PDF étant une des pires qui soit (elle n'a pas concu pour être bonne, mais pour avoir un rendu correct sans plus qui ne pose presque jamais de problèmes aux imprimeurs). Ensuite quand on parle CMJN on en arrive forcément à parler couverture GAMMUT, ICC, etalonnage, calibrage et bien sur echelle de nuanciers.

Bref si je veux une couleur précise (parceque c'est la signature de ma marque) il faut faire appel à un pro. Par contre si je moque d'avoir des couleurs proche en lieu et place des couleurs exactes alors le RGB converti par un filtre générique suffit dans pas mal de cas.

Leur nouveau business model qui consiste à percevoir une taxe sur tout ce qui ressemble de près ou de loin à du matériel informatique et à se faire envoyer des SMS à 0,30¤ par millions fonctionne très bien.

Un cube de données est de façon générique un agregat de données en dimension supérieure à 2.
Pour schématiser prenons une socitété. Cette société comprend plusierus services. Chaque service a un budget qui lui est propre et qu'elle répartie dans différent centre de couts ou qu'elle investit sur différents projets. bein entendu il y a à la tête de chaque service un chef et idem à la tête de chaque projet. Tous les mois ces gens font le bilan entre ce qui a été budgeté, Ce qui a été dépensé et ce qu'il est prévu de dépenser au final. Bien entendu celà doit être remonté, par service, par projet et en global par rapport total pour que la société puisse savoir mois après mois ou elle en est.
en approche classique c'est à se taper la tête contre les murs. Il faut créer des clefs et des contraintes dans tous les sens, faire la différence entre ce qui a été alloué directement au projet et ce qui vient des services, le tout avec un suivit mensuel. Et si par malheur deux services fuisonnent ou qu'un projet passe à la trappe, il faut appeler un DBA chevronné pour réussir à recréer des données cohérentes.

Un cube va permettre d'organiser tout celà comme un seul agrégat de données. On va définir des hierarchies et c'est le cube qui va se charger de faire les opérations qui vont bien pour donner des chiffres cohérents.

On aura donc un cube "société"
Une première hiérarchie "année" portant sur toutes les années interressantes (de 2004 à 2008 par exemple)
une seconde hiérarchie "mois" avec les trimestres qui sont la somme des mois correspondant. etc.
Au final :
Année
- 2004
- 2005
- 2006
- 2007
- 2008

Mois
-1 er trimestre
-- janvier
-- février
-- mars
- 2eme trimestre
-- avril
etc.

Services
- informatique
-- administration
--- admin linux
--- admin windows
--- réseaux
--- bases de données oracle
--- bases de données DB2
--- support

etc.

Ensuite on interroge les dimensions : par exemple on peut demander pour l'année 2007 au mois de mars combien le service windows a couté. Le cube va alors chercher l'ensemble des données qui correspondent aux critères et les combine (ici ce sera une addition) pour donner le résultat souhaité.
Le requètage devient alors simplissime. Au cas ou deux services fusionnent il suffit de les déplacer en hiérarchie pour obtenir les données combinées.
exemple :
Services
- informatique
...
--- bases de données unifiées
---- bases de données oracle
---- bases de données DB2

et le cube se charge de mettre dans le nouveau service "bases de données unifiées" la somme des deux anciens services.
Une fois le travail (fastidieux, et j'en sais quelquechose) de définition des hiérarchies terminé on a alors un système de données extrèmement simple et intuitif à interroger. Les utilisateurs finaux peuvent alors créer eux mêmes leurs propres requètes et le DBA n'a qu'à surveiller la charge machine et l'occupation disque (dans un monde théorique hein...)

uh non, pas dans le cas général en tout cas, pour exécuter du php avec moins de droits, voir module suphp de apache

Attention à ne pas confondre deux choses :
- D'une part la descente de droits. A savoir que le process initialisé par Apache se récupère un autre uid au moment de l'execution et de fait perd des droits.
- D'autre part l'isolation : à savoir que IIS ne peut pas du tout faute de droit initaliser tel fonction ou tel objet.

Pour modéliser rapidement dans un cas on a un utilisateur système qui gère tout et qui ensuite rabaisse les droits des différents processus, et dans l'autre on a plusieurs utilisateurs qui gèrent chacun leur morceau et pas plus et qui communiquent entre eux.

suphp permet de rabaisser les droits du script d'execution à ceux du propriétaire du fichier, mais rien n'empècherait l'utilisateur httpd de lancer le fichier sans passer par suphp et de fait de l'executer avec les mêmes drotis que ceux d'Apache. Donc si il y a une faille dans le script PHP lui même, on est protéger, mais si il y a une faille dans httpd la porte est grande ouverte et l'intrus qui gagnerait les droits pourrait alors avoir accès à l'ensemble des fichiers et des modules/CGI gérés par Apache.
A contrario si il y a une faille dans IIS 6.0 en mode isolation, l'intrus peut arreter et redemarer IIS envoyer des requètes au différents modules et objets COM normalement appelés directement par IIS, mais il n'a pas accès, aux source des pages, aux scripts .Net ni aux comportement des objets COM.

Mais que je sache il n'y a pas de possilités similaires au chrootage ou
à la mise en jail pour IIS - sauf à virtualiser. Ce n'est donc pas
véritablement de l'isolation.

C'est possible, mais ca demande un boulot de dingue et ca n'est pas franchement recommander. Généralement on se contente de déplacer dans le bon répertoire les DLL et les objets COM que l'on veut instantier avec des droits spécifiques.

Mais bon d'un autre coté dans APACHE l'utilisateur qui hérite du HTTPD et qui écoute sur le port 80 a tous les droits en lecture sur toutes les pages de tous les sites web, et tous les droits en execution sur tous les modules et tous les CGI. Sous IIS il est possible d'avoir un utilisateur qui ne fait que lancer le service et d'avoir d'autres utilisateurs pour la lecture et l'execution des pages et des middle tier.

Dans les deux cas il y a des avantages et des inconvennients. L'ideal serait d'avoir les deux, comme c'est le cas par exemple avec TOMCAT ou le demon APACHE ne sert que de vecteur au middle tier, lequel peut ainsi être complètement isolé (que ce soit au niveau des droits ou au niveau système). Mais je serais personellement bien en peine de dire laquelle des deux strategie (isolation des droits ou isolation système) est en théorie la plus forte. Dans un cas on est sur que même si il y a escalade de privilèges, l'intrus ne pourra pas détruire plus que le contenu du jail, dans l'autre cas on est sur que si l'on a un site qui est percé, celà ne présente pas d'avantages pour percer le site d'à coté.

Cependant il existe sous Linux un moyen d'avoir les deux en créant un chroot-jail divisé en domaines SE-Linux et avec une gestion d'ACL-Posix. Seulement SE-Linux c'est à se taper la tête contre les murs. Aucune distribution ne gère SE-Linux au niveau des paquetages (pour les utilisateurs de Fedora, bien que la gestion utilisée soit mieux que rien, elle n'apporte au final pas grand chose) ce qui entrainne que toute mise à jour implique que l'on passe pas mal de temps (ie plusieurs jours) le nez plongé dans la doc à corriger les domaines et les droits...
Donc la double isolation existe sous Linux, mais elle n'est pas utilisable...

un fichier texte est simple à déployer d'environnement en environnement (recette, intégration, préproduction, production, maintenance, ...). Reproduire des gestes de conf' dans un clickodrome devient vite fastidieux dès qu'il y a plus d'une dizaine de sites à gérer...

Tout d'abord il est assez simple sous IIS de sauvegarder et de restaurer une config ou l'ensemble des configs web que ce soit via une sauvegarde brute (par vbs ou par copie des entrées de la base de registre) et de la redéployer derrière. De plus généralement il ne suffit pas de dupliquer les fichier de config, mais il faut aussi redéployer tout les objets qui font tourner le site. C'est à dire redéclarer les bibliothèques, redescendre les bons droits sur les répertoires et les fichiers, ouvrir les règles firewall etc. Là un Windows 2003 peut, suivant les cas être au final plus facile à déployer qu'un équivalent libre. Une règle dans l'Active Directory, un MSI (packageur sous windows) bien fait et ca rouel tout seul.
Même si personellement je préfère avoir un CHROOT assez complet que je peux trimblaller facilement d'un serveur à un autre, la lourdeur liée aux clickodromes est facile à esquiver pour peut que l'on se donne un peu de mal au début sous Windows.

La première hypothèse est que IIS 6.0 est un bon produit. En mode isolation complète on peut changer la configuration d'un site web ou d'un ensemble de sites webs sans impacter quoi que ce soit à coté. De plus les meccanismes ISAPI, OLE et DCOM permettent facilement de le lier à une interface d'intégration customisée, ie il est beaucoup plus facile de faire dialoguer un programme lourd spécifique avec IIS/ASP.net qu'avec Apache/perl ou Apache/PHP. Donc une maintenance et une integration beaucoup plus aisée sous IIS... A titre d'exemple mettre sur le même serveur IIS deux configuration ASP avec des paramètres totalement différents pour des raisons de sécurité qui appellent la même base de données avec d'un coté des appels extrèmement intensifs pour une mise à jour immédiate des données et de l'autre une gestion de cache optimisée pour minimiser les accès base est assez délicat sous Apache/PHP, rien que de gérer des php.ini différents en fonction des sites est problématique, et pour la gestion des accès il va probablement falloir se farcir une gestion du cache à la main (ce qui est toujours une très mauvaise idée, tant la question est délicate). Sous IIS ca se fait facilement. On met un processus middle tier par site et on règle les paramétrages OleDB par site et basta.

La seconde hypothèse est que PHP/Perl ont complètement loupé le coche. je ne veux pas tomber dans le troll sur langage PHP, mais ilf aut bien admettre que malgré les gros efforts du zend optimizer et les améliorations dans la série 5, le PHP a pris une génération de retard au niveau de la faclité de dev et de la productivité. Ruby (on rail ou pas), Python et (mon favori personnel) Erlang ne sont pas encore au niveau pour assurer la relève. Résultat on a rien de comparable à la plateforme .Net sous Linux. J2EE étant un poil trop complexe pour pouvoir être utilisé "partout". Et pourtant .Net est une très mauvaise plateforme (gestion mémoire catastrophique, système de cache à la con, threads à configurer un par un pour éviter les catastrophes en j'en passe).

Dernière hypothèse, et c'est à mon sens une grave lacune du monde libre aujourd'hui : on a pas de cubes et surtout pas de plateformes pour les exploiter. Vu l'espace disque dont on dispose aujourd'hui, pourquoi créer une base de données quand on peut faire un cube ? Si celui-ci est bien créé on se facilite la tache de façon monstrueuse pour tout ce qui est reporting. Plus besoin de faire venir un dev qui touche bien se bille en SQL si il faut consolider les données de l'années. Et au niveau simulation c'est le jour et la nuit par rapport aux BDD classiques. Seulement interroger un cube OLAP ou même en Star-Schema en ligne de commande bonjour. Il faut donc un SDK complet avec un générateur de requètes optimisé et un système d'audit de perf capable de remonter quelles hiérarchies simplifieraient/accelerreraient le travail. A ce niveau là en solution sous Linux (propriétaires ou libres) on est au point mort. Et pas de bras, pas de chocolat...

Sinon il y a aussi un phénomène boule de neige. Avec un Active Directory, Exchange (autre très mauvais produit, même en version 2005) et IIS il y a moyen assez simplement de créer un groupware complet extranet. Si on ajoute reporting services (obligatoire avec Exchange 2005) on a un outil de gestion de documents et de suivi assez complet. Donc on fait rentrer des compétences IIS pour tirer parti à fond des licences qui ont déjà été achetées, et un fois que les compétences IIS sont là...

Faut pas confondre deux choses :
a) Un pilote qui permet d'utiliser la carte son
b) Un device/serveur qui peut eventuellement faire office de mixer.

OSS n'avait pas à l'époque d'autres but que de fournir le a). Pour tout un tas de raisons (motivation des interressés, problèmes avec la sécurité du noyeau, opacité du hardware et j'en passe) il a fallu attendre un moment avant d'avoir un b) qui tienne la route. Le fait qu'une seule application puisse accéder à la carte graphique en même temps, n'a jamais empéché un serveur X d'afficher plusieurs fenêtres. Sauf que le serveur "son" n'existait pas (et d'ailleurs dans une grande mesure n'existe toujours pas) sous linux...

Oups, grosse erreur de ma part. En lieu et place de "charges patronnales" il faut lire charge patronales et taxes professionnelles diverses.

Je n'oserais pas remettre en doute tes pourcentages, mais ça doit expliquer comment des ingénieurs en province sont payé 28K¤ brut par an en sortant de l'école tout en étant facturé 300¤ par jour...

Plusieurs explications :
- Soit le projet est plus long. A savoir l'ingénieur bosse sans qu'il y ait besoin de rerencontrer le client ou de lui faire valider le dev en cours pendant des semaines voir des mois. C'est le cas par exemple de la commande d'un programme complexe sur mesure, il peut se dérouler six mois avant d'arriver à une version alpha présentable au client. De fait les coûts de prospection et de négociation sont dilués dans le projet.
- Soit l'ingénieur est en régie chez le client. Là on coupe tous les charges de l'entreprise et en plus comme l'ingénieur est sur place, tous les coûts de validation et de correction sont automatiquement pris en charge par le client.
- Il se peut aussi qu'il s'agisse de contrat de masse. IE avec uen seule négotiation on place 10 ingénieurs. la aussi le couts annexes sont dillués
- Encore une autre chose : l'ingénieur est un "junior" qui sort d'école et qui doit faire ses preuves pendant un an avant qu'on puisse le vendre plus cher sur d'autres projets. Ou alors, l'ingénieur est embauché dans une SSII qui préfère le vendre à perte plutôt que de le voir rester dans la boite à ne rien rapporter du tout.
Ou un mélange de tout celà.

A 300¤ H.T jours, sur une base de 220 jours travaillés dans l'année on a 66k¤ si on compte les charges patronales légales minimum de 45% il reste 36k¤. Si l'ingénieur est payé 28k¤ il reste pas lourd pour les frais de déplacement, de rédaction de contrat, les tickets restos, les couts locatif des locaux etc. Et ca c'est si le client paye rubis sur l'ongle et ne génère pas de problèmes de trésorerie.

Si je facturais ma création au prix standard :
deux heures avec flash : 100¤
trois jours+ en W3C : 1500¤
donc si je calcule bien :
3 jours = 1500 ¤
1 jour =500¤.
Partons sur 20 jours ouvrés/mois => 10 k¤
donc 120 k¤ /an


Ouais, je ne parle jamais avec le client, je n'ai jamais besoin d'écrire de contrats, papiers ou autres cahiers des charges ou de les faire valider/signer, j'écris un code parfait donc je débuggue jamais et comme en plus je ne paye pas de charges, taxes ou autres je me met tout l'argent dans la poche direct.

Pour te donner un ordre d'idées :
- Prospection, appels d'offres, validation de la faisabilité et de la fiabilité du client : 10 à 15% du temps.
- Ecriture des contrats, protection juridique, discussion, négotiation du prix avec le client, changements d'avis du client, choix d'un hébergeur et commande de la future architecture de prod etc. : 20% du temps
- Developpement du site (seul truc facturé) : 40% du temps
- Debuggage, aménagements graphiques ou fonctionnels post dev, maintenance et formation du client à l'utilisation de l'interface d'admin : 25 à 30% du temps
Donc sur tes 20 jours ouvrés il en reste 8 facturés.
Ensuite : charges patronales + charges sociétés + frais de déplacements+ éventuels problèmes de trésoreries avec les aggios qui vont bien : environ 50% du cout.
Reste 4 jours facturés.
Total salaire brut annuel si le dev travaille en moyenne 20 jours par mois et que la société ne fait pas de bénéfices : 4x500x12 = 24000¤ ....

Moralité : Sur une facturation à 500¤ par jour de dev, on ne gagne de l'argent que sur les fonctionnalités supplémentaires que le client demande à rajouter sur un site qu'on a déjà créé (à perte).

Donc tu attaque le web 2.0 , en sachant qu'il y a de nombreuses définitions, mais sans expliciter celle que tu prend.
Pas mal ...

CF
Pour ma part celà recouvre l'ensemble des sites sur lesquels l'utilisateur peut interagir avec le contenu en temps réel (ou légèrement décalé en cas de validation/modération) et de manière visible par tous les autres usagers du site, ce qui place de vieux trucs comme les forums ou les commentaires dans le cadre du web 2.0. Idéalement cette interaction se fait sans rechargement complet de la page.

Ca veut rien dire ce que tu dis. Soit c'est accessible, soit c'est pas acessible. Pas 'oui mais non'.

As-tu entendu parler de : http://www.webstandards.org/files/acid2/test.html#top ?
En theorie c'est conforme aux standards donc accessible. En pratique c'est illisible sur une grosse majorité des navigateurs. Donc c'est accessible, mais en fait pas trop...

Et si le truc dépend de flash 9 ?

Ben alors l'utilisateur ne peut pas passer en plein écran en mode direct hardware, faire du téléchargement multiple en simultané ou regarder les toutes dernières vidéos. Tout le reste est compatible. A moins que la video soit le contenu il n'a donc aucun problème d'accessibilité.

Tu as pas montré en quoi:
1°) ca sera une fraction du prix
2°) ca sera visible par plus de personne
3°) qu'il y aura moins de maintenance.
Bref, tu as juste affirmer sans rien montrer.

Ah bon ? Il me semblait pourtant avoir été clair. Le snavigateurs modernes ne respectent pas les standards. Ca s'améliore lentement pour les CCS niveaux 1, on est loin du compte pour les niveau 2 et les niveaux 3 sont une utopie. De plus les machines javascripts fonctionnent un peu toutes comme elles veulent et possèdent des bugs divers et variés. de fait quand on code un truc aussi "sophistiqué" par exemple qu'un menu déroulant ou une interface de navigation qui suit le scrolling de la page il faut y passer des heures, prendre des libertés avec les standards et souvent écrire des bouts de codes spécifique pour la détection du type de navigateur et écrire des codes différents en fonction du résultat. Ca fait donc plus de code à écrire, plus de code à maintenir, et bien entendu plus de temps pour faire tout çà donc un surcout.
Si on developpe en flash 8 les mêmes fonctionnalités prennent quelques minutes à developper (et encore si il s'agit pas juste d'un drag and drop de template) et on est certain que 90% des navigateurs qui se connecteront à la page auront exactement le rendu qu'on veut leur donner.
Personellement je ne fais quasiment jamais de flash, alors que j'ai codé des applis entières en AJAX. Au niveau vitesse et facilité de developpement il n'y a pas photo.
A moins de n'avoir jamais essayé l'un et l'autre (ou que tu sois parti dans un trip mauvaise foi aigue) il est difficile de prétendre le contraire. Même en étant non agriculteur il est assez facile de comprendre qu'il est plus complexe de faire pousser des orangers que des pommes de terre.
ton

C'est vachement plus simple de faire un site en XHTML+JS propre, qu'un site en Flash propre.
Hum oui ca marche bien comme ca aussi.

fonctionne uniquement avec des personnes qui n'ont pas essayé de faire un site accessible avec l'une puis l'autre technique.

Déjà c'est possible, ce qui n'est pas toujours le cas avec le W3C
Encore une fois, quel argumentation...
Pas la peine de trouver de contre argumentation, il n'y a pas d'argumentation.

C'est facile pourtant, il n'est pas toujours possible de faire à la fois un site XHTML+JS qui a) fonctionne comme on voudrait et b) respecte les standards. Donc comme il faut que le site fonctionne soit on abandonne la fonctionnalité problématique, soit on sort des standards. Je te renvois à l'acid test pour comprendre. Ce rpoblème ne se pose pas (ou très rarement) en flash

(super sympa d'avoir une CSS qui valide quand aucun navigateur ne l'interprete correctement)
Ce qui n'a rien a voir avec le W3C mais bon c'est pas grave hein...

Comme vu plus haut Et le mec qui paye le site ET le mec qui regarde le site se foutent du standard utilisé. Ils veulent jsute que ca marche "tout seul". donc entre uen CSS valide qui s'affiche mal et une CSS pas valide mais qui s'affiche bien partout il y a pas photo un seul instant.

/me a fait un framework stable et simple pour du brainfuck. Donc c'est vachement facile a maintenir mettre en place etc... Beaucoup plus que du java ou il y a pléthore d'outils et autre !

Si ton framework est meilleur, plus convivial, plus faciel à utiliser, plus productif etc. Alors oui tu remportes le marché. Il n'existe pas à ma connaissance de framework middleware+database+rendu+gestion d'évènement en XHTML+JS qui arrive au niveau de celui de flash. Même en laissant de coté la question des outils de dev dispo (ou la encore flash gagne haut la main) ca rend le dev XHTML+JS plus difficile.Un site grand public, qui ne ménage pas ses efforts pour l'open source et la communeauté Linux, qui possède dans son équipe de dev une pléthore de gens qui touchent plutôt bien leur bille niveau standards W3C met en bas de chacune de ses pages Cette page est peut-être conforme xhtml 1.0. . Peut-être....

Pas la peine, t'es cpu bound bien avant.

C'est clair que le rendu CSS dynamique c'est gratuit niveau CPU. Et JS pareil...

Tu dev 'une fonctionnalité qui décoiffe' en seulement trois jour ?
Pas étonnant qu'on ait pas les meme centres d'intérets.
On parle pas des kikoo lol qui veulent foutre un blog hein.
Un site de vpc ou autre ca se fait pas en une semaine.

Disons qu'une fonctionnalité rigolotte et attrayante visuellement ca se développe en trois quatre jour ou pas du tout. Le mec qui paye à l'autre bout c'est pas forcément France Telecom ou EDF. Si tu arrives à lui vendre un site web pour 10 000¤ c'est déjà le bout du monde. Un site vitrine pour une agence immobilière, une petite société spécialisée ou un relais/chateau ca doit se faire en une semaine oui...

A part 'xhtml ca puxor flash ca roxxor' je n'ai rien vu qui ressemblai a un argument.

J'aimerais que tu me dises exactement ou j'ai dit que XHTML "puxor". J'ai juste dit que c'était beaucoup plus de boulot que flash. Je n'ai pas dit non plus que falsh ca "roxxor" juste que quand on avait pas l'argent pour faire un site web en XHTML, la solution flash était nettement moins couteuse.

Laisse tomber, encore un Flash Fanboy, comme ceux qui ont pourri les commentaires du blog cité dans le journal.

Je tiens à préciser tout de suite, même si je ne suis pas super crédible dans le rôle que je déteste flash.
Ca fait trois jours que je bosse sur un système de visualisation/crop/réorganisation d'images, mon code est en grande partie une repompe des CSS de http://www.cssplay.co.uk/menu/index.html (qui est une vraie mine d'or, à conseiller à tous les dev ) et que malgré tout il ne fonctione pas encore tout à fait comme je veux. Ce que je cherche à faire prendrait deux heures à faire en flash.
Si je facturais ma création au prix standard :
deux heures avec flash : 100¤
trois jours+ en W3C : 1500¤

J'ai bon espoir qu'au final mon code soit visible/utilisable sur plus de 90% des navigateurs, mais je n'oserais pas en jurer... Quand à savoir dans comment il sera interpreté dans 3 ou 6 mois ...

Au fond, je crois qu'il y a un antagonisme naturel entre l'accessibilité et le rendu constant.
Je suis d'accord, sans aller jsuqu'au rendu constant, simplement un rendu cohérent. Je calcule toutes mes pages en em et autant que possible j'évite d'utiliser les bordures pour que l'on puisse augmenter la taille du texte sans exploser la mise en page. Ca marche mais du coup je rajoute des div qui sont purement des containers d'autres div ou blocks de div (et donc j'abime un peu la décorélation fond/forme si chère au W3C)

Pour Flash, j'imagine que ça doit être un cauchemar...
Malheureusement pas tant que çà. Si tout est en vectoriel, il est très facile de créer une fonction pour "zoomer". Il y a deux choses casse pieds à faire : chopper la nouvelle taille de police si l'utilisateur en change après que l'objet flash soit chargé et faire aller le contenu à la ligne par cbloc pour éviter les ascenceurs (ca par contre ca se fait presque tout seul en CSS si on a fait proprement tout le reste)

Le web 2.0 pas dispo sur 90% des postes clients ?Faut que tu m'explique la.

Dans l'ordre.
- Il existe de nombreuses définitions du Web 2.0, Qui vont du tout au tout. Pour ma part celà recouvre l'ensemble des sites sur lesquels l'utilisateur peut interagir avec le contenu en temps réel (ou légèrement décalé en cas de validation/modération) et de manière visible par tous les autres usagers du site, ce qui place de vieux trucs comme les forums ou les commentaires dans le cadre du web 2.0. Idéalement cette interaction se fait sans rechargement complet de la page.
- On peut considérer qu'un site web 2.0 est accessible par 99% des clients. Mais l'ensemble de la masse web 2.0 n'est accessible en plein par aucun navigateur ou presque à ma connaissance. L'ensemble de la amsse des sites en flash est accessible par tous les utilisateurs flash 8 et plus. Soit environ 90% du parc des navigateurs.
- Sur les navigateurs non testés par le dev, même sur des pages statiques HTML 4.0 la mise en page peut exploser et rendre le site inutilisable. Typiquement le genre de choses qui ne se produisent jamais en flash.
Au final pour un site "W3C" un peu évolué, la masse de travail nécessaire pour le rendre lisible par 90% des personnes surfant le web est enorme, alors qu'elle est quasiment nulle avec Flash.

Cool. Et dreamweaver est aussi parfaitement défini si on veut jouer ...
Je veux bien, mais seulement si on veut jouer à comparer des choux et des bananes. Je en vois pas bien le rapport entre une norme d'un coté et un outil qui permet de developper (et qui au passage prend pas mal de libertés avec la norme) d'autre part.

Un utilisateur s'en FOUT du framework.
Et tu sais quoi ? Le mec qui paye les dev web aussi, et en prime il se fout également des standards du web. Si pour une fraction du prix il peut avoir un site web qui sera visible par plus de personnes avec moins de maintenance il va pas se poser la question bien longtemps....

Tu peux faire les choses bien avec du brainfuck (et voui, turing complet). C'est pas pour autant que je le prendrais pour un projet...
Le truc c'est que dans notre histoire, le langage qui prend la place du brainfuck c'est celui défini dans les standard du W3C. C'est vachement plus simple de faire un site en Flash propre, qu'un site en XHTML+JS propre. Déjà c'est possible, ce qui n'est pas toujours le cas avec le W3C (super sympa d'avoir une CSS qui valide quand aucun navigateur ne l'interprete correctement) et puis c'est vachement plus simple à coder, à tester, à maintenir, à mettre en place etc.
Ensuite en flash tu passes pas tes journées à te demander si tu créé volontairement une fuite de mémoire pour que telle ou telle fonctionalité reste utilisable sous IE (oui parceque le mec qui paye il aime bien les super fonctionnalités qui décoiffent, mais si c'est trois jours de dev pour pas être visible par 75% des navigateurs du marché il est tout de suite moins chaud), tu ne passe pas ta vie à te demander comment faire rentrer ton super design dans le DIV amputé de pixels de chez MS, tu te prend pas la gueule à découper ton javascript et tes images à l'octect près pour econnomiser des tombereaux de bande passante etc.
Bref la raison pour laquelle tu ne veux pas coder en brainfuck est exactement celle pour laquelle certaines web agencies ne veulent pas entendre parler de XHTML+CSS : parceque c'est vraiment se casser les pieds pour un résultat aux mieux équivalent.

D'un coté vous avez une technologie opaque, avec des specs pour le moins douteuses dont ona clairement du mal à savoir si elles sont définitive ou pas ce coup-ci, une machine virtuelle qui varie grandement dans son coportement d'une architecture à l'autre et des rendues plus ou moins compatibles selon le navigateur et de l'autre vous avez Flash.

Pour mettre les choses au clair Flash est en tout point comparable aux framework AJAX.
On peut en flash
- faire une version texte lisible, accessible aux handicapés et copiable/collable.
- s'arranger pour que les bouttons back et forward se coportent de façon naturelle
- s'arranger pour que chaque page soit possible à ranger dans les bookmarks
-s'adapter à la version du plugin et à la puissance de la machine du client
-créer des pseudos-liens (ou même de vrais liens) pour permettre une navigation classique et/ou une indexation par les robots de recherche
- d'avoir un historique (les bidouilles supplémentaires consistent le plus souvent à coder proprement et à utiliser la fonction toute faite d'Adobe)
- d'imprimer le contenu flash soit à la volée soit via la création d'une page "pour imprimante" qui va copier le contenu flash dans un buffer et le mettre à disposition au format jpeg (utilie seulement pour les vieux navigateurs)
Et de facon générale on peut depuis flash via action script piloter tout javascript et réciproquement.

Bref le flash a exactement les même ennuis que le web 2.0 à deux exceptions près
- Il est diponible sur plus de 90% des postes clients, sur lesquels il va avoir un rendu quasiment identique d'une machine/architecture à l'autre
- Il dispose d'un framework complet, défini et parfaitement doccumenté

Quand le flash est dégueulasse, et qu'il ne permet pas le copier/coller, la mise en bookmark ou que sais-je encore c'est qu'ila été codé [avec les pieds] dans des contraintes budgetaires qui ne permettait pas de faire comme il faut. Si vous codez n'importe comment en flash (ie en regardant juste si ca marche sur votre machine) vous aurez un produit utilisable sur 75 à 80% des navigateurs connectés à internet. En Web 2.0 vous ne dépasserez pas les 20%.

Honnêtement vous croyez vraiment que la boite web qui bosse à la va vite pour faire un site web en flash avec une envellope de 5 000 à 10 000¤ (ie entre 10 et 20 jours de dev création du graphisme et déploiement compris) va tester son produit dans le navigateur konqueror en FreeBSD sur architecture Alpha si on lui demande pour la même enveloppe de faire le site en web 2.0?
Et vous pensez vraiment qu'une boite qui veut un site web et qui a le choix entre une solution flash à 5 000¤ qui va passer sur 90% des clients et une solution AJAX au double qui va marcher sur 80% avec 1000 à 2000¤ de rallonge à chaque fois que l'on veut grapiller 1% supplémentaire va prendre la solution "conforme aux standards du W3C pour peu qu'ils laissent sécher l'encre ce coup ci" en priant pour que son site marche encore après le prochain patch de sécurité IE ?
Restons sérieux, flash a une part de marché aussi importante pour la simple et bonne raison qu'il n'a pas de concurrents. Aucun. Quelque soit la façon dont on regarde. Et c'est pas en répétant des choses qui feraient mourir de rire un dev flash confirmé qu'on va y changer quoi que ce soit.

>> Ceci n'interdit pas les DRM, ou n'importe quelles autres de ces fonctionnalités

Ouf, on a toujours la liberté d'emprisonner l'utilisateur !

Ou de n'installer que des paquets signés, validés. Ou de rendre confidentielles des transactions banquaires, ou de chiffrer un disque dur ou ....

Les DRM ca ne s'applique pas seulement au Blu-Ray.

Dans un cas la famille a le droit(enfin a l'exception) de le voir (le 2em), dans un autre cas, non.
Bizarre ce 'De fait' alors

En fait le truc est que sur le disque acheté à la FNAC tu as le droit de faire des représentations pour la famille et les amis, par contre si tu fais une copie de sauvegarde du disque, tu n'as pas le droit (dans les textes) d'utiliser cette copie pour faire une représentation, même dans le cadre familial. Il semblerait que la jurisprudence soit nettement plus laxe de ce point de vue là...

Alors déjà il s'agit d'une reproduction strictement réservées à l'usage privé du copiste, donc il n'y a aucun droit de représentation ou de prêt attaché à cette copie. De fait il est illégal d'utiliser cette copie pour faire une représentation même gratuite, même dans le cercle familial. De plus ceci est valable à l'exception des copies des oeuvres d'art destinées à être utilisées pour des fins identiques à celles pour lesquelles l'oeuvre originale a été créée or la représentation qui nous intéresse étant un spectacle/divertissement/concert, on n'a donc pas le droit de l'utiliser comme spectacle/divertissement/concert. J'imagine que l'on peut s'en servir pour un travail supplémentaire, une étude scientifique, une analyse colorimétrique ou autre, mais pas pour écouter de la musique/voir un spectacle.

Au final l'utilisation "repasser l'enregistrement à des copains pour qu'ils regardent le contenu" me parait difficilement défendable.