pas taxés, disséqués, pour une fois qu'on verrait des neurones impliqués dans une chanson de la québécoise....

[ Répondre ]

> ET les cartes mémoires d'appareil photo numérique c'est taxé ?

oui, rassure-toi, ils y ont pensé, c'est taxé. (regarde à http://www.vachealait.com/actu-index.html(...) , comme les supports amovibles numériques pour enregistrer de l'audio sont taxés, et que les SmartMedia et autres CompactFlash sont utilisées dans certains lecteurs MP3, ben ils sont taxés, même si tu t'en sers dans ton appareil photo).
je crois que seuls les disques durs non-amovibles ne le sont pas.

pour le reste, c'est vrai, les disquettes servent principalement au sein des entreprises pour le transport et l'échange de documents internes à l'entreprise (pour les secrétaires, mais aussi par ex pour les nombreuses boites qui n'ont pas d'internet sur le poste de travail, et qui doivent ramener leur pdf/document word qu'un partenaire leur a envoyé sur leur mail lisible sur une machine dédiée à internet, et partagée). d'ailleurs, il devient de plus en plus difficile pour le grand public d'en trouver, des disquettes.

bref, cette redevance supplémentaire est un scandale, mais ces temps-ci il est de bon ton de considérer que nous avons des poches d'une profondeur infinie remplies de billets et qu'on peut financer tous les privilèges et prébendes avec.

[ Répondre ]

> Enfin, les corrections et ajout de driver que tu annonces sont d'un mois environ. Soit en pleine phase rc.

Les liens que je pointe sont en effet pendant la phase RC, mais justement, la phase RC ça sert à fusionner les correctifs de bug, d'autant que, pour le sis5513, le gros changement a été fusionné au -pre2 (mais ce changement contenait des bugs, qui sont l'objet des mails que je pointais). Les bugs, c'est normal, ça arrive, j'ai jamais dit non plus le contraire !

Bon, après, pour la com entre les devs, c clair que ce doit être là qu'il y a eu un problème, mais justement, je "répare" en faisant de la com ici pour avertir directement les utilisateurs ;-)

Ceci dit, je trouve que changer la couche IDE était une excellente initiative, d'autant qu'Andre Hedrick, son mainteneur historique, tirait un peu la langue tellement c'était devenu lourd à maintenir (il faut dire aussi que les chipsets et contrôleurs IDE sont de plus en plus complexes, le temps où ça marchait presque tout seul est bien loin).
Au passage, si j'ai bien suivi, dans le pilote pour le sis5513 dont je parle, certains changements proviennent de SiS directement, ce qui est une excellente nouvelle, car un fabriquant de matériel qui supporte Linux en OpenSource, ça devient hélas de plus en plus rare.

[ Répondre ]

rien à voir examine le fichier dont je t'ai parlé (dans la version officielle et -ac), et tu verras qu'il n'y a que de la correction de bug, comme c'est d'ailleurs expliqué dans les mails que je pointe. Sur le 2.4.21, il y a eu une grosse fusion de la branche -ac, et notamment de la couche IDE, mais certaines corrections de bug ultérieures n'ont pas été fusionnées (en tous cas pour le sis5513), d'où mon interrogation. ceci dit, pour le reste, il est vrai que la branche -ac profite d'un nettoyage complet de la couche IDE depuis qu'Alan a pris le taureau par les cornes, mais justement, le 2.4.21 marque la fusion de ces efforts dans le noyau officiel.

[ Répondre ]

Attention, il y a des problèmes avec le support de l'ultra-dma sur les cartes mères à base de chipset sis (récent). SiS a changé l'architecture de ses chipsets récents (SiS745 , 645, 635 entre autres), et distingue à présent le northbridge du southbridge (où réside le controlleur IDE). Conséquence, le driver linux, qui se basait sur l'ID du northbridge pour trouver le type de controleur IDE, a quelques problèmes. Le driver inclus dans le 2.4.21 (sis5513.c), a été partiellement patché, mais Alan n'a pas livré à Marcelo la dernière version (pour une raison inconnue), et donc quelques sérieux problèmes pouvant occasionner de grosses pertes de données subsistent (d'ailleurs, regardez le fichier en question, ya encore un gros FIXME dedans...). Bref, prenez au moins le driver en question dans le noyau -ac... http://marc.theaimsgroup.com/?l=linux-kernel&m=105292163431153&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=105300087109403&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=105308854825215&w=2 http://www.nikosoft.net/howtos/a7s333.php#ide

[ Répondre ]

Mon passage préféré:

Les militants du logiciels libres ne représentent pas les milieux industriels, créateurs d'emplois et de richesse durables en Europe. Actionnés par des théoriciens du " logiciel libre " n'ayant aucune expérience du monde de l'entreprise ou de l'innovation, et ils développent une construction intellectuellement séduisante, mais déconnectée de la réalité industrielle.

Parmi les grandes entreprises françaises impliquées dans la logiciel libre, on trouve Bull, France Telecom, Thalès, ... (pour la plupart, cf le consortium ObjectWeb, entre autres).
Des gens dont le métier primaire est de vendre des services, (alors qu'il était avant de vendre des logiciels dans certains cas, dont celui de Bull), et de le faire dans un contexte industriel.
Il n'y a pas de doute, c'est clair que dans ces boites là, ce ne sont que des adolescents boutonneux, des chercheurs payés par des fonds publics, des consommateurs de logiciels gratuits: bref, que des gens n'ayant aucune logique industrielle, aucune connaissance du métier, du marché, rien, des gros branquignolles.

[ Répondre ]

une BD ? "Les phalanges de l'ordre noir", par Bilal et Christin. Ce n'est pas sur la guerre d'Espagne à proprement parler, mais c'en est quand même le sujet central, et c'est vraiment très beau, même si Bilal n'avait pas à l'époque la maitrise qu'il a aujourd'hui (la BD date de 1979).

[ Répondre ]

En parlant de feed de news, il y a un problème avec la boiboite de /. :

- Your Headline Reader Has Been Banned
- You May Only Load Headlines Every 30 Minutes
- In 72 Hours, Your Ban Will Be Lifted
- Do Not Bother Contacting Us For 72 Hours

Je sais pas si vous avez un moyen d'arranger ça, et si vous vous en êtes aperçus...

[ Répondre ]

Ils ont trouvé leur modèle économique: le plagiat !

http://www.yoper.com/forum/viewtopic.php?t=160(...)

J'aime bien leur façon de résoudre leurs bugs, c'est pratique: "ils font comment nos concurrents ? ok, on copie !"

(bien sûr, j'ironise un peu, mais pour un machin à l'origine payant à $100 - et toujours payant si on veut les MAJ - c'est plus que léger comme méthode ! )

[ Répondre ]

aucune, mais leur page SF marche: http://sourceforge.net/projects/quake/(...)

[ Répondre ]

Ah j'oubliais, en plus, effacer ta partoche windows augmentera aussi la taille de ton sexe.
Seulement si, sous Linux, tu as patché NTPL avec Low-Latency, sinon ça n'augmente que la taille des poils. Par ailleurs, ton explication sur Starck est capillotractée, ce qui me laisse à pensé que tu n'as pas patché ton noyau.
Et de toutes façons, Kamoulox.

(sinon, je voulais re-signaler, pour les fans de Quake et autres, sous Linux: http://www.quakeforge.net/(...) : Quake1 et Quake2 assez fortement améliorés)

[ Répondre ]

D'après ce que je sais, c'est pas entièrement vrai, ça dépend de la nature du NDA et des specs. Les specs renseignent en général sur bien plus que la partie interface exposée du matériel. Elles explicitent ce qui se passe dedans, afin que l'interface exposée soit bien utilisée (zones mémoire, registres, etc. appelés dans le bon ordre, etc.). Et le fait de voir une implémentation ne renseigne pas forcément sur ces choses (mais un peu quand meme). C'est d'ailleurs le changement opéré par ATI après la 8500: les specs ne sont plus disponibles, meme sous NDA.

[ Répondre ]

il me semble que ce n'est que pour de vieilles Ati, seulement jusqu'à l'Ati Rage 128

non, les specs des premières radeon (jusqu'à la 7500 comprise) sont aussi dispos (via NDA hélas, donc j'ai pas de lien à te proposer, en dehors de celui où ils disent qu'il y a un NDA: http://dri.sourceforge.net/doc/faq/other-formats/html-single/DRI-De(...) ), meme les 8500 ont un DRI correctement implémenté, grace à du revrese-engineering et du passage de specs sous le manteau (si j'ai bien compris). En revanche, après, ça s'est complètement fermé pour ce qui est de la 3D, au moment où ATI rejoignait (et même dépassait) NVidia dans la course aux perfs.
par ailleurs, si j'ai bien suivi, même dans les versions à peu près documentées des cartes graphiques récentes, il y a des problèmes de brevets (S3TC par ex.), qui font qu'on ne pourra jamais avoir d'implémentation à 100% avec des pilotes libres.

[ Répondre ]

A mon avis, cher pbpg, tu ne connais absolument rien au milieu hospitalier, ni meme celui de la santé en général.

Outre le fait que les logiciels généralistes fournis par microsoft sont en général totalement indadaptés au milieu de la santé, certaines contraintes (les données médicales doivent etre conservées pendant 30 ans, et exploitables pendant toute cette durée) recalent d'Office ( ;-) ) Microsoft, car c'est à l'exact opposé de votre politique commerciale (va relire un document Word 2000 dans 30 ans, et on en rigolera ensemble: d'ici là, il n'y aura simplement plus aucun moyen de le relire.. et avec les versions XP de vos produits et leurs codes d'activation, ce sera encore pire). Certains le font malgré tout, d'ailleurs pas qu'avec des produits MS, on a vu la meme chose avec des produits Claris (sous Mac), et ça donne par la suite des problèmes énormes à cause de ces obligations.
AMHA, ces particularités sont la raison numéro un pour laquelle MS ne pénètre pas ce milieu. Les applications coeur de métier étaient en général par le passé sur des UNIX ou des petits Mainframe (c'est d'ailleurs un beau bordel hétérogène), et elles le restent encore largement. Les besoins en bureautique "pure" sont relativement faibles, et en tous cas pas prépondérants, et pour l'adéquation des produits MS pour ces besoins, cf. ma remarque au § précédent.
De ce que j'en ai vu, seuls les médecins, avec le système Vitale, ainsi que d'autres acteurs tels que les mutuelles, utilisent des applicatifs sous Windows, mais il faut dire qu'ils n'ont pas tous les impératifs sus-cités, et meme eux, en général, n'utilisent pas les autres produits MS. D'ailleurs, toujours d'après ce que j'ai vu, cette tendance à utiliser Windows avec exclusivement des logiciels non-MS dessus, est très répandue dans ce secteur d'activité, c'est à dire celui de la santé en général (ce qui au passage me fait perdre en conjectures sur l'email pointé par la news: comprends pas tout ! parle-t-il des hopitaux de l'assistance publique uniquement ? CHU ? cliniques ?)

[ Répondre ]

Je parlais de l'attitude d'IBM vis à vis de la communauté Linux, pas du noyau Linux, et il y a plein de dégats qu'ils peuvent y faire, rien qu'en ayant un minimum d'imagination. Quand on a un portefeuille de brevets comme le leur, on peut en faire des procès à tout va pour couler la concurrence, et ce n'est qu'un exemple.

[ Répondre ]

Vu les emmerdes que j'ai eues avec Access, ce n'est ni gratuit, ni injustifié. Ceci dit, j'ai décroché au moment où c'était Access 97, ça a peut etre évolué depuis...
Ce truc là était une innomable merde hyper instable, et dont le fonctionnement devient souvent mystique quand on essayait d'en tirer quelque chose de plus via VB. J'ai vu des ingénieurs en info, de surcroit certifiés Microsoft, y perdre leur latin en essayant de comprendre les réactions d'Access (97), dans un environnement, certes un peu compliqué.
Access un vrai SGBD ? mouais.. bien spécial alors, hein... la norme SQL il en fait un peu ce qu'il veut, etc.
Pour moi, un "vrai SGBD", c'est un truc qui au minimum suit la norme et est accessible via des requêtes réseau. Et oui, j'ai tendance à réduire SGBD à SGBDR, ce qui veut dire suivre la norme SQL. Or, Access s'assoit dessus (à vrai dire l'interface SQL est symbolique et anémique), et pour les requêtes réseau, tu repasseras... comme c'est un produit Microsoft, on peut vaguement y accéder via leur framework ODBC/ADODB/etcdb. , mais c limité.
Access c'est une tentative pitoyable de vulgarisation des SGBD, qui est dans l'ensemble préjudiciable aux utilisateurs, parce que là encore, on cherche à leur faire "croire qu'ils savent", ce qui amène aux pires catastrophes.
Pour finir, si tu veux un "équivalent" raisonnable d'Access, va voir du coté de pgAccess et de phpMyAdmin. et il y en a d'autres dans le gout, notamment si tu veux faire du maquettage rapide (ce sera surement distribuable en un fichier, au pire un .tar.gz). D'ailleurs, OpenOffice, via ses interfaces de données, peut également remplir une partie des rôles d'Access.
Il y a aujourd'hui un truc que tu ne peux vraiment pas faire "comme Access", sans mettre un minimum les mains dans le cambouis, c'est ce que tu fais en VB, effectivement. Mais il existe des générateurs de formulaires/scripts de traitement en php, que tu peux ensuite reprendre et retoucher dans ce langage, ce qui devrait largement recouvrir le besoin. Une url au hasard si tu veux aller voir: http://www.dadabik.org/(...)

[ Répondre ]

non, le plus marrant c'est que, si je le suis bien, Access est "un vrai SGBD"... hmpfmouhahahahahahahaha ! celle là, c'est la meilleure de l'année !

[ Répondre ]

Je suis bien d'accord, et ce qui m'inquiète, c'est qu'en plus, une relativement petite boite sur le point de crever qui attaque un concurrent énorme du secteur, en général c'est pour faire passer un message du type "ça vous coutera à peine plus cher de nous racheter, et vous éviterez des problèmes et que votre image soit chahutée dans la presse".
Or SCO racheté par IBM, c pas forcément la meilleure chose qui soit pour Linux... Pour l'instant IBM est tout gentil parce qu'ils ont encore Sun et HP en face d'eux, et qu'ils ne veulent pas risquer de se mettre tout le monde à dos dans la communauté Linux, mais si par exemple Sun se casse la gueule, ils risquent de changer de partition, les gens de big blue.

[ Répondre ]

Mouais, non, tu noteras que JNDI, JDBC, etc. étaient déjà présents dans J2SE 1.3, et ce pour une très bonne raison: les 3/4 (voir 9/10) des composants en dehors des Servlet/JSP/EJB dans J2EE sont avant tout des composants d'accès à des services/composants hétérogènes à Java (bases SQL, DNS, LDAP, Système sous-jacent, Système de fichier, mail, librairies en C/C++, etc.), ce qui explique qu'on les retrouve dans J2SE, car tout programme Java a potentiellement besoin d'accéder à ces service/composants hétérogènes via une API Java. D'ailleurs, tu noteras que, par défaut, dans J2EE distribué par Sun, il n'y a pas grand chose de plus que Servlet/EJB: http://java.sun.com/j2ee/sdk_1.3/techdocs/api/index.html(...)
Bien sur, le reste (JNDI, etc.) peut etre rajouté après, c pas la question... D'ailleurs tout Java est modulaire, tu peux rajouter des composants autant que tu veux à J2SE aussi.
Donc je réitère, le système Servlet/EJB est le coeur de J2EE. C'est d'ailleurs tellement vrai que le plus gros de la bataille dans les serveurs d'application J2EE est là: avoir le conteneur d'EJB le plus optimisé (via des appels locaux notamment, ou via du RMI amélioré, comme le fait Jonas avec Jeremie). Enfin... je les connais pas tous, donc il y en a peut etre qui réimplémentent à leur sauce des choses comme cette daube de JNDI, mais ce qui est sur c'est que personne ne se bat là-dessus (hélas).

[ Répondre ]

Je schématise beaucoup en effet (j'étais pressé). Mais les tests sont très intéressants néanmoins. C'est à ma connaissance les seuls tests comparant les différents patterns J2EE, ainsi que RMI et Jeremie, le tout pour Jonas, et je voulais surtout fournir le lien en pâture à la faune locale ;-)

Par ailleurs, JNDI, Web services, JDBC, tout ça n'est pas le propre de J2EE. A peu près tous les serveurs d'applications Java utilisent ces couches (ya pas vraiment le choix, sauf peut-être pour la couche LDAP, qui est grave pourrie dans JNDI, alors que Novell en a une belle qu'ils ont filé à OpenLDAP), et même si tu fais du développement servlet-only dans Tomcat, tu vas les utiliser (d'ailleurs, c'est ce que tu fais, non ? ;-)). Ce qui fait le coeur de J2EE c'est bel et bien les EJB (mais je suis d'accord avec toi que ce n'est pas le seul élément).

De plus, les EJB et J2EE ont un autre avantage que je n'ai pas cité, c'est que leur aspect modulaire fait qu'en réalité, pour les programmer, on utilise en général largement de la génération de code (à vrai dire, on a pas vraiment le choix, cf. les indications de complexité du code dans le test).

Enfin, je pense que tu devrais vraiment regarder du coté d'Enhydra pour ton projet. En gros Enhydra offre également un support de type MVC, mais en bien propre: il y a DODS, qui fait de l'encapsulation objet JDBC pour les accès base (par génération de code). Tu utilises ensuite ces objets de données (DO) pour implémenter ta couche business, et pour finir tu construis des objets de présentation (PO) qui utilisent les objets business, ainsi que des objets DOM pour générer les pages web. Ces objets DOM sont générés par XMLC, qui "compile" des pages HTML (ou XML, ou WML, ou XHTML) de template en DOM Java, en fournissant via de la génération de code les raccourcis idoine pour y accéder facilement. Le tout est lancé dans ce qu'ils appelent une SuperServlet.

En conclusion, tout dépend de la taille du projet et de tes besoins. Il va de soi que plus le projet est gros, plus la modularité est un atout. De même, si le projet doit être inséré dans un environnement déjà assez complexe et J2EE et qu'on veut de l'interopérabilité à mort, ben il faut faire du J2EE. Par contre sur un petit ou moyen projet mieux vaut privilégier les perfs par rapport à ce qu'apporterait J2EE, et si on veut de l'interopérabilité, il suffit de développer un backend XML.

[ Répondre ]