TImaniac a écrit 6423 commentaires

, je créé mon package d'install avec TOUTES les dépendances en mode forcé et j'installe les DLLs a la bourinne.

Bah je viens de dire que Windows est capable de garder plusieurs versions d'une même dll... (dans un environnement bien particulier celà dis mais je te laisse deviner lequel ;-) ) Et puis celui qui se fait pas chier et qui fait un truc en mode forcé à la bourrine, il se fait pas chier à essayer de mettre les dll dans un dossier system, il les laisse dans le répertoire de son appli... Et puis faut quand même voir que le développeur feignant il utilise un truc qui fait tout le taf pour lui, genre Visual Studio qui lui fait le setup et gère les dépendances en empaquetant tout ce qu'il faut... du coup il évite des problèmes potentiels... En fait celui qui fait un setup foireux, c'est le non feignant qui veut tout faire à la patte qui fait tout planté... mais là encore c'est de plus en plus rare de trouver ce genre de développeur...

En fait je me demande si la multiplication des dll c'est pas plus mal : après tout c'est négligeable vu la taille des durs actuels et c'est quand même plus propre à installer/désinstaller quand chacun met ce dont il a besoin dans son dossier...

dll statiques... y'a pas un problème dans ta phrase ? Y'a un d dans dll ;-)

Allez encore une petite question :

je passe un contrat avec une boite qui développe une lib 100% proprio, bien entendu j'ai les droits d'utilisation et l'accès aux mises à jour et nouvelles versions pendant une durée de disons, 5 ans.
Je développe une appli non compatible avec la GPL au dessus de cette lib.

Du jour au lendemain, la boite tombe amoureux du LL et décide de sortir une nouvelle version de sa lib, mais cette fois sous GPL (ce que mon contrat n'interdit pas). Et là en tant que client j'ai l'impression de m'être fait avoir : j'ai bien entendu le droit d'utiliser la nouvelle version comme promis dans le contrat mais me voilà dans l'obligation de passer à la GPL...

Vous en pensez quoi ?

Enfin on a beau dire, le système des rpm c'est théoriquement bien plus avancé que ce qui existe sous Windows, mais moi je constate que sous linux celà pousse à la feignantise : je développe un soft, je te file les sources voir un rpm si j'ai pas trop la flemme et démerde toi avec les dépendances. Bref : end-user c'est à toi de bosser.

Sous windows, c'est plutôt le boulot du développeur de faire un installeur, et il est obliger de réfléchir à son utilisation par l'utilisateur final (peut être parcque plus généralement ils vendent le produit et qu'ils se doivent de faire un peu attention à ce que le client puisse installer et utiliser le produit...). L'utilisateur final lancera le setup.exe, qui s'installera gentiment, même si parfois la cohabitation avec l'environnement est hasardeuse (problème des dll par exemple)... Mais celà devient de plus en plus rare, et la plupart des applications marchent du premier coup, alors que sous nux je dirais que c'est la proportion inverse pour peux que le soft utilisé ne soit pas estempillé red-hat ou mandrake dans une distri officielle (et encore des fois).

De toute façon Microsoft a trouvé la solution au problème des installations et des dll-qui-change-de-version : Windows peut conserver plusieurs versions d'une même dll au même endroit (hop plus de conflit de version) et abandon progressif de l'utilisation de la base de registre (l'installation se fait à la bourrine, paèrs vérification des dépendances évidemment : copié-collé).

Une question : C'est où la limite pour utiliser un truc sous GPL ? Parcque bon, le kernel Linux est sous GPL, donc toutes les appli qui tournent au dessus utilisent à un moment ou un autre une des fonctionnalités du noyau, qu'il soit proprio ou non...

Une autre question : et si on fait du linkage dynamique avec une lib sous GPL ?

Et si je ne sais pas à l'avance avec quoi mon appli sera linké ? (genre je parcours tous les binaires et je recherche des méthodes dedans et je les appelle just for fun)

Euh... lobbying ?
Un homme politique doit bien prendre une décision même si celà ne le concerne pas (et pourtant)... Donc il va appuyer le choix qui va l'influencer le plus par la suite (à cours terme)...

Normalement il devrait être remplacé par un nouveau format
Bah vi, pas un format mais plusieurs formats : les formats numériques sans support matériel. Mais là le problème c'est qu'ils ne maitrise pas ce nouveau support, qu'ils leur fait peur, et que le client est en avance ;)

Freenet devrait répondre à tes attentes :
http://freenetproject.org/(...)
Par contre tu ne sais absolument pas ce que tu stock sur ton ordinateur :-)

Une rapide explication en français avec liens de téléchargement :
http://www.ratiatum.com/logitheque.php?id_log=112(...)

Si tu as déjà formaté, arme toi d'un pc avec Windows et www.getdataback.com il récupère tout si tu n'as rien écrit sur la partition après formatage (par contre il veut absolument un endroit ou copier les données récupérées.)

A bah sous Windows je branche l'imprimante, elle s'ajoute comme une grande dans le dossier Imprimantes... Fichier > Partager et zou elle est aussi reconnu par tous les autres pc du rezo... c'est vrai que c'est dur aussi.

Microsoft propose évidemment des applications qui s'intègrent parfaitement (celà paraît logique). Il y a de nombreuses applications tierce partie qui s'intègrent(intégreront) très bien dans l'environnement Windows, et un des objectifs du prochain OS de Microsoft est qu'il y en ai encore plus...

Et puis l'intégration ne se situe pas seulement au niveau des applications dans leur environnement, mais aussi l'intégration des différents API entre eux, et c'est là le point fort de Microsoft, si tu regarde le lien vers l'image représentant l'ensemble des API de LongHorn, là il y a un réel soucis d'intégration de l'ensemble, et c'est surtout cette intégration qui fait défaut sous Linux, sauf bien entendu au niveau des API de bas niveau, étant donné qu'il y a un "consensus" sur le kernel et des normes sur les API de base à respecter. Mais à part celà, il est bien difficile d'unifier tout ce qui se fait un peu partout, bref, c'est le bazare et Microsoft est en train de nous faire une jolie cathédrale ;) Heuresement il existe des projets comme http://www.linuxbase.org/(...) qui ont des objectifs qui vont dans ce sens...

Elles sont là (les generics) : télécharge le framework 1.2 (version béta mais utilisable)

Vu les objectifs de Microsoft et l'intérêt qu'ils portent désomais à MFC, il semble assez logique qu'ils ne supportent pas ce framework qui n'a aucune place dans la stratégie de Microsoft...
Après il me semble que bien qu'ayant de nombreuses qualité, le C++ n'est plus vraiment à la mode pour faire des GUI... Celà peut s'avérer un choix basé sur un existant, mais pour une nouvelle solution je suis pas convaincu de l'intérêt... (pour le GUI j'entend)

Avalon est effectivement l'ensemble du module graphique de LongHorn, tu peux le situer dans le vaste ensemble d'API sur cette image : http://download.microsoft.com/download/a/2/f/a2fc47d2-8bdf-4977-836(...)

Quel danger ?
Le premier danger c'est "l'inconnu", tout semble montrer que Microsoft réécrit une mouture complète de son OS et le succès de Linux n'y est pas étranger, rien que pour ça il faut avoir peur, parcque Microsoft a les outils pour.

Sinon techniquement le principal intérêt de cette couche est l'intégration, et surtout une uniformisation des applications dites "lourdes" (traditionnelles) et les applications web. Je crois que c'est surtout celà qui fait peur, surtout du côté de l'équipe de Mozilla qui risque d'être toujours limité aux sites web alors que sous LongHorn le site en html ca sera un peu... dépassé. Le problème c'est que Microsoft maîtrise toutes sa plateforme, et question intégration, comme Apple, il n'y a pas photo avec les solutions Linux où les acteurs sont beaucoup plus disperser et n'ont pas les même objectifs... C'est ce qui fait son charme mais qui risque de faire sa vulnérabilité. Parcqu'il paraît clair que les applications à la LongHorn vont apparaître, la démo du site Amazon est un exemple concrêt. Et Linux risque de ne proposer aucun moyen d'y accéder, parcque ne supportant pas ces technologies.
Envisager une solution alternative semble "idéale" mais pas réaliste vu le temps qui reste et les difficultés de regrouper toutes les compétences dans une même équipe.
Se pose donc la question de supporter ces technos. Mais là comme d'hab c'est se soumettre à Microsoft...

Voilà en gros la situation délicate actuelle. Mais le problème ne vient pas seulement d'Avalon, mais aussi des autres parties des API LongHorn : tout existe plus ou moins sous nux, mais ce qui fait aussi la qualité d'un OS c'est l'intégration.

si ca peut t'aider...

euh, le modèle WinFS veut apporter de la simplicité justement parcque la notion d'arborescente ce n'est pas intuitif pour l'utilisateur lambda... Si onp rend exemple sur les bibliothèques multimédias qui sont intégrées au player, c'est un réel confort de ne pas avoir à chercher dans quel dossier j'ai foutu le CD bidule, là je fais juste une recherche par artiste, cd, titre, etc. On demande pas à l'utilisateur de comprendre le fonctionnement d'un SGBD, on lui demande de l'utiliser naturellement pour cacher des implémentations beaucoup moins intuitives...

Il est quand même intéressant de noter que leurs pertes se situent sur le CA "global", avec une forte chute des vente des VHS... en volume ils s'est vendu plus de DVD que l'année passée... et les dvd "discount" font effectivement de plus en plus d'adepte... tiens donc si on baisse les prix on vend plus ? bizzare...

Non non la machine virtuel .NET de Microsoft est parfaitement capable de lire un prog en IL depuis un autre conteneur, les .dll par exemple, qui sont identiques dans leur contenu aux .exe (dans le monde .NET), sans point d'entrée. Tu peux t'amuser à mettre l'extension que tu veux si celà te chante. Le fait de créer un exécutable .exe permet comme dit plus haut de charger le programme par le JIT sans que l'utilisateur est besoin de faire une commande du genre "mono monprog" sous Windows et ainsi l'utilisateur lambda ne voit pas la différence... Ils auraient aussi pu choisir une autre extension, mais là encore l'utilisateur lambda, faut pas lui changer ses habitudes... Mono compile effectivement un programme du même type que .NET par soucis de compatibilité, c'est tout.

Evidemment sous nunux celà fait bizzare.

Perso je comprend pas très bien l'intérêt... Le format PDF signifie pour moi un document agréable à lire et que je vais pouvoir imprimer... Et je vais imprimer quoi avec tous ces trucs multimédias ?

Si je veux vraiment un contenu multimédia je me tournerai plutôt sur les formats plus adapté, comme une bête page HTML ou un outil de présentation...

je rajouterai http://www.labo-dotnet.com(...) dans le même genre
en fait ils ont pleins de ptits labo dans pleins de technos. Et ca l'es empêche pas d'aimer les LL, comme le montre l'engouement sur ce site pour Mono ;)

tu peux par contre utiliser un autre modem pour faire routeur avec la freebox, comme décrit par ici :
http://www.forpage.com/forum/viewtopic.php?t=8509(...)
ca ne répond pas vraiment à ta question, mais c'est une alternative au pc-routeur-qui-fait-du-bruit

Tu pouvais pas résumer ? nan j'déconne :-) Mais ce qui est marrant, c'est que tu ne dis rien de nouveau, tous les points que tu cites ont été débattus plus bas... je vais donc tenter de te résumer les "contre-arguments".

Tout d'abord un intérêt de Mono que tu sembles oubliés : c'est une alternative à Java (je serais tenté de dire la seule qui vise les même objectifs), et rien que pour celà son existence est justifiée.

Ensuite tu rabaches que Mono est et restera une pâle copie de .NET sans intérêt basé sur des spécifications mouvantes...

Mono a 3 buts :
- proposer une implémentation complète des spécifications de l'ECMA.
- proposer un ensemble d'API destiné à la programmation sous Linux (GTK# & Co)
- proposer une compatibilité avec le framework .NET

Evidemment ce dernier point ne pourra jamais être parfait, mais l'ignorer, c'est ignorer le nombre important d'application ou de développeurs qui pourraient "migrer" (genre 300 serveurs à Munich).

Car il faut être clair, aucun outil adapté à .net "n'existe" en dehors des outils de MS (on mettra entre parenthèse les outils de borland, dont la strategie .net et leur implication sur le long terme dans cette plateforme n'est pas encore bien établie).
Eh eh eh... Donc déjà on met de côté Borland qui est pourtant une solution complète... Tu semble indiquer qu'il n'y a quasiment rien pour développer avec .NET à part VS... Et ? Il commence a fleurir un peu partout de nombreux outils, libre ou non, pour exploiter cet environnement, s'il n'y a pas de solution complète (à part si on enlève celles qui existent), c'est aussi dû à la relative jeunesse de .NET... On a mis combien de temps avant d'avoir un environnement potable pour Java ?

Partir sur Mono c'est avant tout faire une fleur à MS en favorisant une technologie entièrement controlée et dirigée par MS
.NET n'est présent que dans la compatibilité, sinon c'est juste le respect d'un standard établi, défini à l'ECMA par un consortium, et Mono a même fait des propositions pour des nouvelles spécifications... On peut dire que celà évolue en tout cas beaucoup plus vite que chez Sun...

La performance, la différence entre les perfs d'exécution d'une JVM et de la VM .net (celle disponible sur WindowsXX) sont négligeable. Sur windows, la VM de MS prend l'avantage
Si je te suis sous WindowsXX les perfs sont identiques mais celle de MS a quand même l'avantage... plutôt que d'aller chercher dans des considérations techniques hasardeuse, regarde plutôt comment les plateformes sont conçus : y'en a une qui a été conçu pour exécuter du code optimisé pour être interprété, et l'exécution commencera toujours par une interprétation; l'autre solution est conçu pour exécuter du code non interprété, il n'y a donc pas de bidouille pour essayer de déterminer la partie du code qu'il faut compiler en natif comme c'est le cas des JVM recentes... Et puis là le débat c'est linux, alors il faut plutôt comparer une JVM sous nux et Mono, je suis curieux de voir les premiers benchs (qui seront de toute façon des nids à troll comme tout bench qui se respecte)...

Pour finir, je dirais simplement que l'innovation ce n'est pas se contenter de copier ce que fais le voisin même si il le fait bien.
A défaut de pouvoir innover (parcque pas tout le monde peut se payer 10000 ingénieurs spécialisés R&D), il faut respecter les standards. Les développeurs ont besoins d'une alternative à Java, qui en comble certaines lacunes (notamment sur les langages, la gestion des versions), et qui de plus respecte les standards : c'est tout ce que fait Mono. le standard de l'ECMA est amené à être améliorer, comme c'est le cas par exemple pour les generics (si on prend la plateforme Sun ils ont choisi de faire des templates et de ne rien faire évoluer du tout)... On peut par exemple penser à des améliorations pour des langages comme OCaml ou encore pour les langages interprétés... En tout cas je trouve qu'il y a beaucoup plus d'avenir sur le long termes aux standards ouverts qu'aux standards de Sun...

Quelle est son utilité face à un éditeur qui peut à tout moment changer la donne ?
De toute façon les spécif sont ouvertes, ils ne peuvent changer la base sans prévenir, et sinon tant pis celà fait une plateforme performante... Et puis si tu prend le modèle de Windows : la plupart des problèmes de sécurité et stabilité viennent de la compatiblité avec les anciennes versions des programmes...Et pourtant ils assurent la compatibilité (évidemment certaines parties finissent par ne plus l'être) Sachant que Microsoft développe son prochain OS autour de .NET, il paraît clair que leur objectif ne sera pas de casser les normes existante en empêchant une compatibilité avec Mono... Sinon ils vont casser la compatibilité avec eux même... Et puis il faut aussi voir qu'il y a une demande de plus en plus forte de compatilibté entre Linux et Windows pour les applications, je crois surtout que Microsoft a voulu proposer une solution à ses clients pour répondre à leurs attentes (pour concurrencer Sun par exemple), et Mono est pour eux la preuve du bon fonctionnement de leur stratégie, c'est un atout supplémentaire, bref, aucune raison de casser la compatibilité.

Alors qu'a l'opposé un projet comme Classpath à besoin de beaucoup de ressources pour fournir lui une implémentation GPL intégrale d'une plateforme complètement définie et qui assurerait une réelle suprématie aux logiciels libres.
Alors là je comprend pas, tu dis de ne pas suivre Microsoft parcque il faut innover et toi tu proposes de copier la solution de Java...
Ta phrase suivante me fait encore plus rire... C'est vrai que le projet CLassPath a plus d'ambition que le projet Mono... Ah bon en quoi ? Sachant que Mono a quand même l'ambition de proposer une plateforme complète qui s'intègre à Gnome, que propose ClassPath de plus ?

Un point où on est d'accord : la portabilité. Evidemment c'est illusoire, à moins de concevoir une application dans cette perspective... Mais justement, tout ce qui est défini à l'ECMA, c'est l'équivalent du J2RE de Sun sans la partie liée aux interface graphiques, bref, il manque ce qui n'est pas portable, on ne va pas s'en plaindre. Celà forcera peut être certains développeurs à concevoir une interface différente pour chaque environnement, et d'en exploiter les possibilités spécifiques plutôt que d'utiliser un toolkit à la Java qui ne s'intègre nul part et auquel il manque beaucoup de fonctionnalités... Sinon ce sera toujours la même chose, quelque soit l'environnement : les applications seront dépendantes des API qu'elles utilisent, et seront supportés sur les plateformes où ces API sont implémentés...

Certains morceaux "facheux" genre COM+ ont été oubliés ;-)
Tu sais ce que c'est com+ ? Sous Windows il y a effectivement une certaine compatilibité avec com+, parcqu'il y a l'existant. Sous Linux aucun intérêt d'être implémenté.

PS : allez, n'oublies pas que Microsoft a fait parti du consortium qui a normalisé le XML et ses dérivés (schémas & Co), je te déconseille donc d'utiliser ces technos qui sont des standards sans avenirs, que Microsoft peut changer à tout moment...

Je crois surtout qu'ils ont compris de l'absence total d'intérêt de mettre une protection : ca enmerde l'utilisateur lambda et c'est toujours contourné. Lors du dernier service pack, les seuls enmerdés étaient les sociétés dont leur numéro de série était dans la black-list... Et je suppose que ca la fou mal pour Microsoft de devoir expliquer au client qu'il est coupable...

erf c'est une skin, elle n'utilise même pas les widgets natif de MacOSX, d'ailleur tu peux faire exactement le même screenshot sous Windows :-)

"En ce qui concerne la protection, il me semble qu'il est très dur de trouver des platines sacd qui sortent les 6 channels en numérique"

Ah bon on peut même pas branché son lecteur SACD sur son ampli numérique ? C'est où l'intérêt ?

Installe la version "normale" de videolan :
http://www.videolan.org/vlc/download-mandrake.html(...)

au vu du screenshot sous Gnome, c'est déjà plus potable...
http://www.videolan.org/vlc/screenshots/20030228-gnome-02.png(...)

euh Paramètre > Changer l'interface... Perso j'ai des boutons et le player prend même pas le tiers de l'écran en largeur en 1280...
T'as fais exprès d'obtenir cette interface affreuse ou quoi ? :-)