Dis moi juste un truc.
Est ce que la GB a voté oui au TCE ?
Si elle refuse cette clause aujourd'hui, rien ne dit qu'elle n'aurait pas voté non au TCE. Les anglais ont plutôt été soulagés que les français votent non pour ne pas avoir à le faire non plus.
Avec des si et des mais on mettrait Londres en bouteille.
Bien joli c'est dernière version d'Eclipse, mais au lieu de tout faire, ils feraint mieux de se concentrer sur l'essentiel, c'est-à-dire les technos Java.
Oui mais pourquoi avoir décidé de séparer la production d'electricité (RTE non rentable) avec sa distribution qui est rentable.
Comme par hasard la partie non rentable va aller au contribuable et la rentable aux actionnaires.
Qui décide de segmenter ainsi le marché si ce n'est Bruxelles.
On a encore l'exemple avec le réseau ferré de france, ....
Et après on dit que l'état est déficitaire et que pour s'en sortir, il faut vendre encore plus de bijoux de famille.
C'est un cercle vicieux qui conduit inéluctablement à une disparité des richesses et à terme à l'appauvrissement des classes moyennes ou la la déterioration des infrastructures
Le principe du monopole est le suivant.
L'Etat par le biais de la démocratie décide ou non d'appliquer un monopole sur un marché.
Tout citoyen se voit donc contraint de cotiser parfois contre son gré par le biais de l'impôt pour le service en retour
Les libéraux contre-argumentent en général de la façon suivante:
- Pourquoi payer pour un service que je n'utilise pas ? (par exemple l'éducation alors que je n'ai pas d'enfant). L'electricité me parait assez indispensable à chacun.
- Le service s'il est ouvert à la concurrence sera mieux géré et donc moins cher que s'il est pris en charge par l'état (cf. adsl). Tous les spécialistes s'accordent pour dire que le prix du marché sera supérieur à celui réglementé. (Si j'en juge par les posts moinssés plus haut certains considèrent qu'il n'est pas "juste", tout dépend de quel point de vue on se place)
- Tout le monde ne contribue pas de façon égalitaire à l'impôt car au nom de la solidarité certains vont payer plus cher que la valeur du marché leur service alors que d'autres en profiteront. Autant donc liberaliser le marché et baisser l'impôt.
Ce point se dissocie en général la politique de gauche de celles de droite et se règle donc aux urnes
Dans tous les cas la libéralisation du marché de l'electricité sera donc préjudiciable au consommateur francais moyen à l'exception de quelques privilégiés qui sont d'ailleurs souvent rentiers et en profiteront doublement.
Ce qu'il faut changer c'est nos dirigeants nationaux (de gauche comme de droite)
L'union européennne n'oblige pas un état à renoncer à un monopole, même si elle fait tout pour l'encourager en imposant tjs plus de contraintes (cf remarque en fin de post)
En revanche, une société nationale n'a pas le droit d'investir des marchés en dehors de son état qui à ouvert son marché à la concurrence car elle peut être faussée (l'Etat propriétaire d'uen société risque de subventionner sa société pour éliminer la concurrence dans les états ou les marchés sont ouverts)
Le pb c'est que nos dirigeants (qui sont svt les mêmes que les dirigeants des sociétés nationales) encouragent les acquisitions de nos champions nationaux et rejettent après la faute sur Bruxelles lorsqu'elle leur tape sur les doigts.
Bruxelles ne remet pas non plus en cause, le fonctionnement d'un service public au niveau national. Pour assurer un service public on peut adopter un monopole d'état avec une société d'état (modèle à la francaise) mais on peut également recourir à un entreprise privée ou une assssociation que l'on subventionne (modèle à la suédoise). Pour assurer l'équité, il faut recourir à des appels d'offres publiques et adopter une transparence (théorique) dans le choix du prestataire.
Le pb c'est qu'à partir du moment où l'etat a renoncé à un monopole il ne peut plus revenir en arrière. Ainsi si les différénts prestataires ne donnent pas satisfaction, l'état ne peut pas recourir à une société nationalisée et encore moins rétablir un monopole (qu'on me corrige si je me trompe)
L'autre pb c'est qu'une société qui veut s'agrandir dans l'union européenne n'a d'autre solutions que de sortir du giron de l'état.
Les institutions actuelles et le TCE excluent la possibilité que 2 service publiques nationaux gérés par un monopole puissent fusionner et conserver un monopole etendu aux 2 états concernés.
La porte est donc définitivement fermée aux services publiques à un niveau européen.
Oui oui on nous la fait sytématiquement celle là.
C'est pas moi c'est les autres.
Mais alors pourquoi lorsque tu commandes un A380 et que tu as des retards à la livraison tu touches des indemnités alors que chez Free ton compte est quand même débité alors que le service n'est pas rendu.
Obligation de faire des montages NFS pour bosser entre les stations de travail sous Linux et les serveurs même avec des vues snapshots alors que CCFS uitilse juste du RPC sous Windows. Intéressant sur des sites distants.
Pour accéder à l' API on a le choix entre COM/DCOM (Windows only) , ccperl (don't feed the troll) ou le parsing du CLI. à comparer avec l'API de SVN et ses 2 couches et la facilité de créer des wrappers (python, SVNkit, .....)
Avec un cleartool find bien paramétré tu peux récupèrer l'historique de tous les éléments, répertoires y compris.
Tu peux aussi te baser sur le clearexport_ccase
ou encore partir de la racine la racine de ta vob, récupérer son arbre de version, et descendre récursivement dans chacune des versions de répertoires.
En revanche avant de remonter ces versions tu dois appliquer un traitement pour reconstituer des baselines ou des révisions de façon cohérente .
Sans ce traitement tu risques de te retrouver avec un repository incompréhensible car CC pratique le versionning au niveau des elts et SVN au niveau de l'arborescence entière. Un fichier ou répertoire regroupe tout son historique dans l'arbre de version de l'elt auquel il est associé alors qu'avec SVN modifier une version de fichier revient à créer une nouvelle configuration i.e une nouvelle révision de toute ton arborescence.
Il faut donc bien réfléchir à la stratégie d'import.
Par exemple regrouper toutes les versions d'arborescence qui ont tiré la branche v1.0 sous CC dans le répertoire /branches/v1.0/mon_projet/
et les baselines labelllisées sous /label/ (exemple /label/V1.0-r1/mon_projet/)
Sinon si tu remontes chronologiquement, tu va te retrouver avec des révisions qui ne seront pas logiquement liées entre elles (genre la révision 43 qui correspond à la release 2.3 sera suivie par la révision 44 qui correspond au dernier patch de la 1.5 avec des. On récupère 2 arboresence mon_projet mais pas moyen de voir à quoi elle corresponde.
Si tu remontes sans traitement préalable c'est encore pire, tu auras un historique du genre
rev 1:
/src
rev 2:
/src
/src/package1
rev 3:
/src
/src/package1
/src
/src/package2
rev 4:
/src
/src/package1/f1.java (version /main/1 de f1.java)
/src
/src/package2
rev 5:
/src
/src/package1/f1.java (version /main/v0.1/1 de f1.java)
/src
/src/package2
/src
/src/package1/f1.java (version /main/v0.1/1 de f1.java)
/src
/src/package2/f2.java (version /main/1 de f2.java qui n'a jamais été associé à f1.java/main/v0.1/1 dans aucune vue)
Bref tu auras l'historique des fichiers mais aucune baseline
Bon allez je vais te lister quelques unes des différences
vue dynamique:
SVN ne fournit que l'équivalent des vues snapshots et pas de vues dynamiques.
Avantage:
pas besoin de charger les données
Inconvénient:
Mode connecté => dépend du bon état du réseau, pas de possibilité de travailler hors ligne, simple point of failure si le serveur de registre ou de vob tombe
Vue snapshot,dynamique vs workspace SVN.:
Ne fonctionne que dans une architecture réseau commune (droits à allouer sur le postes, création d'un compte service dans le domaine.
Performance dégradées à distance au point que le multisite ou les clients Web deviennent incontournables.
Avec SVN derrière un frontend Apache pas de pb de performance
Solution IBM pour la 7.0 => CCRC qui revient à fournir le modèle SVN .
Obligation d'administrer les vues car lors des co le serveur de registres garde la trace des fichiers réservés.
Il faut purger régulièrement de registres les vues qui ne sont plus utilisées.
Avec SVN pas de trace. Si un fichier est locké par un utilisateur on peut forcer le unlock et on a pas de trace
Gestion des licences:
coût des licences et simple point of failure lorsque le serveur est out.
Modèle de concurrence:
obligation de réserver un fichier (même en unreserved ) avant de le modifier pour CC.
SVN : possibilité de choisir pour certain fichiers un fonctionnement avec un lock exclusif (fichier images par exemple) et modifiication sans réserver les fichiers pours les autres.
Gestion des droits administrateurs
Avec CC lié à l'OS => nécessite de contacter les admins pour créer un compte chaque fois qu'on veut ajouter un nouvel utilsateur (pour compliquer le tout obligation d'avoir le même compte sur tous les OS créer le compte dasn Active Dirctory et le recréer sur le serveurs Linux)
Multisite:
Mise en ouevre complexe et nécessaire à cause des perfs lorsque 2 réseaux d'entreprise sont différent et distants.
Avec SVN l'approche centarlisée convient et l'administation derrière Apache permet de ne pas être liée à l'archietcture du réseau (un login et un pw suffisent). IBM propose le CCRC pour contourne le pb dans la 7.0
Merge et intégration
Avantage à CC qui propose depuis tjs le merge tracking (hyperlien de merge), des assistants de merge pour une arborescence complètes et des interfaces de merges adaptés à des fichiers autres que seulement du texte (XML, modèles Rose, RSM, , word, ...)
Triggers
Placés du coté des clients avec CC suaf depuis la 7.0 avec le CCRC.
permet d'intrecepter plus d'opération mais necessite de les déployer sur chacun des clients et de les porter sur tous le OS.
Fabrication:
Cleamake permet le partage d'objets dérivés et l'audit de fabrication
Pb aujourd'hui ANT ou compil incrémentale pour Java
Gestion des changement
Clearcase de bas n'a pas de commit atomique (changeset)
=> obligation d'utiliser UCM pour s'interconnecter avec un outils de change/bug tracking.
Je ne vois pas en quoi l'utilisation de Clearcase rend captif l'utilsateur.
A partir du moment où tu as toutes les versions de fichiers d'un projet tu peux tjs les récupérer par script une par une et alimenter un dépôt d'un autre gestionnaire de version
Tu attaques en disant les Web Services ca sert à rien et DBus fait déjà tout ça en mieux et plus simple.
On t'explique que les problématiques à résoudre ne sont pas les mêmes puisque pour l'un il s'agit de faire communiquer des architectures différentes et pour l'autre d'une architecture de communication particulière et que l'interêt réside dans cette différence et après tu débarques
C'est bien beau ce gros pâté, mais dbus, c'est de l'IPC, pas du web service :) (ne mélangeons pas les torchons et les serviettes). comme si tu allais nous l'apprendre.
Alors effectivement sa conception ne peut être que plus simple puisqu'il ne traite l'intéropérabilté qu'avec les composants d'une même architecture. Aucun mérite donc . Heureusement qu'il n'ont pas cheché la complication. Donc tes remarques du style
L'approche DBus, AMHA, est beaucoup plus saine: le protocole reste SIMPLE, il ne fait qu'UNE chose, et il le fait BIEN.
sont hors sujet
Alors là, faut que tu m'expliques comment les web services répondent mieux à cette problématique que dbus. Un protocole de web service est intéropérable avec... lui même. Comme dbus.
Non différentes architectures qu'elles soient à base de composants ou simplement RPC ou encore orientée services ou que sais-je encore peuvent commmuniquer grâce aux Web Services.
Si je veux communiquer entre du DCOM et du DBUS je devrai prévoir une passerelle particulière en se basant sur un pont) et pareil avec une impléméntation de CORBA sur un quelconque ORB ou encore du RMI ou même du simple RPC.
Je devrai attaquer des réferentiels d'objets qui n'utilisent pas les même façon d'exposer leur composant/services qui n'adoptent pas les mêmes conventions, les même structures ni protocoles d'échanges, ni les même paradigmes (procédural, SOA, architecture à base de composant)..... Bref dès qu'on souhaite communiquer en dehors de l'entreprise il faut tout remettre à plat avec chaque nouveau partenaire et redévelopper ou bien imposer à ses partenaires une migration.
Donc l'idée qui n'a rien de magique certes , c'est de se dire: Adoptons un standard de communication "inter" architecture commun. Ce standard c'est les Web Services. Tu aurais pu le comparer avec CORBA qui avait été une tentative de l'OMG de le réaliser. L'erreur qu'ils ont fait était de ne vouloir se limiter qu'a des architectures à base de composants en mode synchrone alors que si je veux m'interconnecter avec ton système d'information Je me fous de savoir quelle est ton architecture. Pour connaitre tous les comptes d'un client ca ne m'interesse pas de parcourir tous les comptes de ta banque en vérifiant qu'il appartiennent bien au client rechercher dans ta banque alors qu'un autre partenaire à décidé que ses objets clients référencaient directement leur compte ou encore que celui ci a implémenté une facade pour se faire.
Ce qui m'interesse c'est
"Quelle est la liste des RIBs du client "Duchmoll Jean Pierre" dans la banque.
J'attend qu'on renvoie un simple liste de RIB et je ne veux pas savoir comment c'est foutu dans DBUS, DCOM, CORBA ou chez toi avec ton protocole personnalisé au dessus de RPC.
Moi je comprend mais surtout mes AMOs comprenent et là ils se disent que cette requête peut servir dans des autres procesus métiers ou que ce processus peut être amélirié si je la place à un autre endoit . Il peuvent faire des simulation et moi en tant qu'architecte je peux enfin capitaliser sur un catalogue de services réutilsable sans m'arracher les cheveux à chaque evolution du besoin.
Et là on commence à comprendre l'intérêt de WCF puisqu'il unifie tout dans une approche orientée service que ce soit dans mon réseau d'entreprise ou sur internet.
Voilà lorsque tu auras déjà admis ca et la compléxité inhéhente qui en découle (y'a pas d'appproche saine ou pas saine à avoir) tu pourras te pencher sur l'implémentation et comprendre l'interêt de celle de M$ et comparer sa compléxité avec des autres approches du même type. Pas en comparant avec l'API de DBUS comme tu le fais.
Quand ca t'arrange la comparaison vaut le coup et quand ca ne t'arrange pas il faut pas mélanger les torchons et les serviettes.
On ne peut s'empêcher de répondre à ce bon monsieur
"Et comment fait on lorsqu'il n'y a pas qu'une seule technologie à interconnecter ?".
Tu nous cites l'exemple DCOP /DBUS mais comment font ils pour communiquer avec du pur CORBA ou encore du DCOM.
Doit-on développer des ponts dans tous les sens avec toutes les technos existantes ou définir un standard, une couche supplémentaire vers laquelle chacune des technologies pourra s'interconnecter ?
Ce modèle en couche que tu critiques a pourtant permis de belles avancées comme la venue de l'internet.
Tu te souviens, ce fameux modèle OSI en 7 couches qui à permis l'interconnexion des réseaux. http://en.wikipedia.org/wiki/OSI_model
En cherchant un peu tu dois bien trouver une réflexion du même genre qui critique ce modèle et qui regrette que tout le monde ne soit pas en ATM.
Et comment l'OS vérifie qu'un applet que je je télécharge accède à des fichiers auxquel je ne souhaite pas l'autoriser ou qui seraient sensibles. En l'empêchant d'accéder à tous les fichiers parce qu'il n'a pas les droits root ou en créant des ACL dédiés à l'utilisateur qu'il devra appliquer sur tous les fichiers sensibles. Ca va être portable ça
Sans oublier Flex3 qui sera sous GPL aux dernières nouvelles et qui te permet de ne plus faire joujou directement avec le Flash http://labs.adobe.com/technologies/flex/
[^] # Re: Le syndrome "il y a mieux"
Posté par Bozo_le_clown . En réponse au journal Europe. Pourquoi pas la constitution Helvétique?. Évalué à 4.
Est ce que la GB a voté oui au TCE ?
Si elle refuse cette clause aujourd'hui, rien ne dit qu'elle n'aurait pas voté non au TCE. Les anglais ont plutôt été soulagés que les français votent non pour ne pas avoir à le faire non plus.
Avec des si et des mais on mettrait Londres en bouteille.
[^] # Re: « A-t-on besoin de remplacer Flash ? »
Posté par Bozo_le_clown . En réponse au journal Quels outils pour remplacer Flash(c)(tm)(100%cpu) ?. Évalué à 5.
https://openjfx.dev.java.net/JavaFX_FAQ.html
https://openjfx.dev.java.net/
[^] # Re: Netbeans
Posté par Bozo_le_clown . En réponse à la dépêche Eclipse 3.3 (Europa) est sorti. Évalué à 1.
http://www.artima.com/forums/flat.jsp?forum=276&thread=1(...)
http://www.softdevtools.com/modules/news/article.php?storyid(...)
Hem
[^] # Re: A toi de voir
Posté par Bozo_le_clown . En réponse au journal Adobe tente une réconciliation avec le libre ?. Évalué à 2.
"L'ouverture de Flashex se fait elle en réaction à SilverLignt ?"
dsl
[^] # Re: Deux ou troi truc sur les tarifs...
Posté par Bozo_le_clown . En réponse au journal [HS] Enercoop, EDF, Poweo et les autres.... Évalué à 4.
Comme par hasard la partie non rentable va aller au contribuable et la rentable aux actionnaires.
Qui décide de segmenter ainsi le marché si ce n'est Bruxelles.
On a encore l'exemple avec le réseau ferré de france, ....
Et après on dit que l'état est déficitaire et que pour s'en sortir, il faut vendre encore plus de bijoux de famille.
C'est un cercle vicieux qui conduit inéluctablement à une disparité des richesses et à terme à l'appauvrissement des classes moyennes ou la la déterioration des infrastructures
Ma vision de l'Europe n'est pas celle-ci.
[^] # Re: Précisions
Posté par Bozo_le_clown . En réponse au journal [HS] Enercoop, EDF, Poweo et les autres.... Évalué à 4.
L'Etat par le biais de la démocratie décide ou non d'appliquer un monopole sur un marché.
Tout citoyen se voit donc contraint de cotiser parfois contre son gré par le biais de l'impôt pour le service en retour
Les libéraux contre-argumentent en général de la façon suivante:
- Pourquoi payer pour un service que je n'utilise pas ? (par exemple l'éducation alors que je n'ai pas d'enfant). L'electricité me parait assez indispensable à chacun.
- Le service s'il est ouvert à la concurrence sera mieux géré et donc moins cher que s'il est pris en charge par l'état (cf. adsl). Tous les spécialistes s'accordent pour dire que le prix du marché sera supérieur à celui réglementé. (Si j'en juge par les posts moinssés plus haut certains considèrent qu'il n'est pas "juste", tout dépend de quel point de vue on se place)
- Tout le monde ne contribue pas de façon égalitaire à l'impôt car au nom de la solidarité certains vont payer plus cher que la valeur du marché leur service alors que d'autres en profiteront. Autant donc liberaliser le marché et baisser l'impôt.
Ce point se dissocie en général la politique de gauche de celles de droite et se règle donc aux urnes
Dans tous les cas la libéralisation du marché de l'electricité sera donc préjudiciable au consommateur francais moyen à l'exception de quelques privilégiés qui sont d'ailleurs souvent rentiers et en profiteront doublement.
[^] # Re: Interessant mais
Posté par Bozo_le_clown . En réponse au journal [HS] Enercoop, EDF, Poweo et les autres.... Évalué à 10.
L'union européennne n'oblige pas un état à renoncer à un monopole, même si elle fait tout pour l'encourager en imposant tjs plus de contraintes (cf remarque en fin de post)
En revanche, une société nationale n'a pas le droit d'investir des marchés en dehors de son état qui à ouvert son marché à la concurrence car elle peut être faussée (l'Etat propriétaire d'uen société risque de subventionner sa société pour éliminer la concurrence dans les états ou les marchés sont ouverts)
Le pb c'est que nos dirigeants (qui sont svt les mêmes que les dirigeants des sociétés nationales) encouragent les acquisitions de nos champions nationaux et rejettent après la faute sur Bruxelles lorsqu'elle leur tape sur les doigts.
Bruxelles ne remet pas non plus en cause, le fonctionnement d'un service public au niveau national. Pour assurer un service public on peut adopter un monopole d'état avec une société d'état (modèle à la francaise) mais on peut également recourir à un entreprise privée ou une assssociation que l'on subventionne (modèle à la suédoise). Pour assurer l'équité, il faut recourir à des appels d'offres publiques et adopter une transparence (théorique) dans le choix du prestataire.
Le pb c'est qu'à partir du moment où l'etat a renoncé à un monopole il ne peut plus revenir en arrière. Ainsi si les différénts prestataires ne donnent pas satisfaction, l'état ne peut pas recourir à une société nationalisée et encore moins rétablir un monopole (qu'on me corrige si je me trompe)
L'autre pb c'est qu'une société qui veut s'agrandir dans l'union européenne n'a d'autre solutions que de sortir du giron de l'état.
Les institutions actuelles et le TCE excluent la possibilité que 2 service publiques nationaux gérés par un monopole puissent fusionner et conserver un monopole etendu aux 2 états concernés.
La porte est donc définitivement fermée aux services publiques à un niveau européen.
Le libéralisme est donc bien triomphant
# A toi de voir
Posté par Bozo_le_clown . En réponse au journal Adobe tente une réconciliation avec le libre ?. Évalué à 3.
Le titre c'est "Nous adoptons le modèle open source"
Entre autre annonces:
Flex3 sous licence MPL
Le code de l'ActionScript VM donné à Mozilla
Des contribs comme FlexUnit et Cairgorn et Flexlib
et le site communautaire osflah.org
Le PDF 1.7 est en cours de standardisation à l'ISO
Pourr le lecteur Flash rien de concret (Ils y réfléchissent ;)
L'IDE Flex Builder et le bus Flex est tjs proprio.
Par contre à la question
"L'ouverture de Flash se fait elle en réaction à SilverLignt ?"
C'est un pur hasard (langue de bois ?)
[^] # Re: Petit témoignage
Posté par Bozo_le_clown . En réponse au journal Mangez des Oranges :). Évalué à 8.
C'est pas moi c'est les autres.
Mais alors pourquoi lorsque tu commandes un A380 et que tu as des retards à la livraison tu touches des indemnités alors que chez Free ton compte est quand même débité alors que le service n'est pas rendu.
[^] # Re: code ou binaire ?
Posté par Bozo_le_clown . En réponse au journal Microsoft : nouvelle arme anti-pirate, le watermarking de code. Évalué à 3.
Ils vont recompiler pous chaque client et "inventer" une nlle marque pour chacun ?
[^] # Re: .
Posté par Bozo_le_clown . En réponse au message Questions d'exam. Évalué à 2.
[^] # Re: Clearcase
Posté par Bozo_le_clown . En réponse à la dépêche Subversion 1.4.4. Évalué à 2.
Obligation de faire des montages NFS pour bosser entre les stations de travail sous Linux et les serveurs même avec des vues snapshots alors que CCFS uitilse juste du RPC sous Windows. Intéressant sur des sites distants.
Pour accéder à l' API on a le choix entre COM/DCOM (Windows only) , ccperl (don't feed the troll) ou le parsing du CLI. à comparer avec l'API de SVN et ses 2 couches et la facilité de créer des wrappers (python, SVNkit, .....)
Allez je vais arrêter là.
[^] # Re: Clearcase
Posté par Bozo_le_clown . En réponse à la dépêche Subversion 1.4.4. Évalué à 2.
Avec un cleartool find bien paramétré tu peux récupèrer l'historique de tous les éléments, répertoires y compris.
Tu peux aussi te baser sur le clearexport_ccase
ou encore partir de la racine la racine de ta vob, récupérer son arbre de version, et descendre récursivement dans chacune des versions de répertoires.
En revanche avant de remonter ces versions tu dois appliquer un traitement pour reconstituer des baselines ou des révisions de façon cohérente .
Sans ce traitement tu risques de te retrouver avec un repository incompréhensible car CC pratique le versionning au niveau des elts et SVN au niveau de l'arborescence entière. Un fichier ou répertoire regroupe tout son historique dans l'arbre de version de l'elt auquel il est associé alors qu'avec SVN modifier une version de fichier revient à créer une nouvelle configuration i.e une nouvelle révision de toute ton arborescence.
Il faut donc bien réfléchir à la stratégie d'import.
Par exemple regrouper toutes les versions d'arborescence qui ont tiré la branche v1.0 sous CC dans le répertoire /branches/v1.0/mon_projet/
et les baselines labelllisées sous /label/ (exemple /label/V1.0-r1/mon_projet/)
Sinon si tu remontes chronologiquement, tu va te retrouver avec des révisions qui ne seront pas logiquement liées entre elles (genre la révision 43 qui correspond à la release 2.3 sera suivie par la révision 44 qui correspond au dernier patch de la 1.5 avec des. On récupère 2 arboresence mon_projet mais pas moyen de voir à quoi elle corresponde.
Si tu remontes sans traitement préalable c'est encore pire, tu auras un historique du genre
rev 1:
/src
rev 2:
/src
/src/package1
rev 3:
/src
/src/package1
/src
/src/package2
rev 4:
/src
/src/package1/f1.java (version /main/1 de f1.java)
/src
/src/package2
rev 5:
/src
/src/package1/f1.java (version /main/v0.1/1 de f1.java)
/src
/src/package2
/src
/src/package1/f1.java (version /main/v0.1/1 de f1.java)
/src
/src/package2/f2.java (version /main/1 de f2.java qui n'a jamais été associé à f1.java/main/v0.1/1 dans aucune vue)
Bref tu auras l'historique des fichiers mais aucune baseline
[^] # Re: 2.0 ?
Posté par Bozo_le_clown . En réponse au journal Un jeu (?) marrant 2.0. Évalué à 7.
[^] # Re: Tros gros, passera pas
Posté par Bozo_le_clown . En réponse au journal 01 Informatique : est ce que cet hebdomadaire est de qualité ?. Évalué à 3.
http://linuxfr.org/~Sam_from_MS/20075.html
"Auteuil, Neuilly, Passy tel est notre ghetto"
http://www.youtube.com/watch?v=0uHikQqc4ik
Désolé pouf pouf pouf !
[^] # Re: Tros gros, passera pas
Posté par Bozo_le_clown . En réponse au journal 01 Informatique : est ce que cet hebdomadaire est de qualité ?. Évalué à 3.
http://linuxfr.org/~Sam_from_MS/24405.html
ou ça
http://linuxfr.org/~Sam_from_MS/23006.html
et on peut se demander si on n'a pas affaire à un troll de compétition
[^] # Re: Clearcase
Posté par Bozo_le_clown . En réponse à la dépêche Subversion 1.4.4. Évalué à 5.
vue dynamique:
SVN ne fournit que l'équivalent des vues snapshots et pas de vues dynamiques.
Avantage:
pas besoin de charger les données
Inconvénient:
Mode connecté => dépend du bon état du réseau, pas de possibilité de travailler hors ligne, simple point of failure si le serveur de registre ou de vob tombe
Vue snapshot,dynamique vs workspace SVN.:
Ne fonctionne que dans une architecture réseau commune (droits à allouer sur le postes, création d'un compte service dans le domaine.
Performance dégradées à distance au point que le multisite ou les clients Web deviennent incontournables.
Avec SVN derrière un frontend Apache pas de pb de performance
Solution IBM pour la 7.0 => CCRC qui revient à fournir le modèle SVN .
Obligation d'administrer les vues car lors des co le serveur de registres garde la trace des fichiers réservés.
Il faut purger régulièrement de registres les vues qui ne sont plus utilisées.
Avec SVN pas de trace. Si un fichier est locké par un utilisateur on peut forcer le unlock et on a pas de trace
Gestion des licences:
coût des licences et simple point of failure lorsque le serveur est out.
Modèle de concurrence:
obligation de réserver un fichier (même en unreserved ) avant de le modifier pour CC.
SVN : possibilité de choisir pour certain fichiers un fonctionnement avec un lock exclusif (fichier images par exemple) et modifiication sans réserver les fichiers pours les autres.
Gestion des droits administrateurs
Avec CC lié à l'OS => nécessite de contacter les admins pour créer un compte chaque fois qu'on veut ajouter un nouvel utilsateur (pour compliquer le tout obligation d'avoir le même compte sur tous les OS créer le compte dasn Active Dirctory et le recréer sur le serveurs Linux)
Multisite:
Mise en ouevre complexe et nécessaire à cause des perfs lorsque 2 réseaux d'entreprise sont différent et distants.
Avec SVN l'approche centarlisée convient et l'administation derrière Apache permet de ne pas être liée à l'archietcture du réseau (un login et un pw suffisent). IBM propose le CCRC pour contourne le pb dans la 7.0
Merge et intégration
Avantage à CC qui propose depuis tjs le merge tracking (hyperlien de merge), des assistants de merge pour une arborescence complètes et des interfaces de merges adaptés à des fichiers autres que seulement du texte (XML, modèles Rose, RSM, , word, ...)
Triggers
Placés du coté des clients avec CC suaf depuis la 7.0 avec le CCRC.
permet d'intrecepter plus d'opération mais necessite de les déployer sur chacun des clients et de les porter sur tous le OS.
Fabrication:
Cleamake permet le partage d'objets dérivés et l'audit de fabrication
Pb aujourd'hui ANT ou compil incrémentale pour Java
Gestion des changement
Clearcase de bas n'a pas de commit atomique (changeset)
=> obligation d'utiliser UCM pour s'interconnecter avec un outils de change/bug tracking.
Pas de gestion des composants à la UCM pour SVN
....
[^] # Re: Clearcase
Posté par Bozo_le_clown . En réponse à la dépêche Subversion 1.4.4. Évalué à 2.
A partir du moment où tu as toutes les versions de fichiers d'un projet tu peux tjs les récupérer par script une par une et alimenter un dépôt d'un autre gestionnaire de version
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Bozo_le_clown . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 1.
Tu attaques en disant les Web Services ca sert à rien et DBus fait déjà tout ça en mieux et plus simple.
On t'explique que les problématiques à résoudre ne sont pas les mêmes puisque pour l'un il s'agit de faire communiquer des architectures différentes et pour l'autre d'une architecture de communication particulière et que l'interêt réside dans cette différence et après tu débarques
C'est bien beau ce gros pâté, mais dbus, c'est de l'IPC, pas du web service :) (ne mélangeons pas les torchons et les serviettes). comme si tu allais nous l'apprendre.
Alors effectivement sa conception ne peut être que plus simple puisqu'il ne traite l'intéropérabilté qu'avec les composants d'une même architecture. Aucun mérite donc . Heureusement qu'il n'ont pas cheché la complication. Donc tes remarques du style
L'approche DBus, AMHA, est beaucoup plus saine: le protocole reste SIMPLE, il ne fait qu'UNE chose, et il le fait BIEN.
sont hors sujet
Alors là, faut que tu m'expliques comment les web services répondent mieux à cette problématique que dbus. Un protocole de web service est intéropérable avec... lui même. Comme dbus.
Non différentes architectures qu'elles soient à base de composants ou simplement RPC ou encore orientée services ou que sais-je encore peuvent commmuniquer grâce aux Web Services.
Si je veux communiquer entre du DCOM et du DBUS je devrai prévoir une passerelle particulière en se basant sur un pont) et pareil avec une impléméntation de CORBA sur un quelconque ORB ou encore du RMI ou même du simple RPC.
Je devrai attaquer des réferentiels d'objets qui n'utilisent pas les même façon d'exposer leur composant/services qui n'adoptent pas les mêmes conventions, les même structures ni protocoles d'échanges, ni les même paradigmes (procédural, SOA, architecture à base de composant)..... Bref dès qu'on souhaite communiquer en dehors de l'entreprise il faut tout remettre à plat avec chaque nouveau partenaire et redévelopper ou bien imposer à ses partenaires une migration.
Donc l'idée qui n'a rien de magique certes , c'est de se dire: Adoptons un standard de communication "inter" architecture commun. Ce standard c'est les Web Services. Tu aurais pu le comparer avec CORBA qui avait été une tentative de l'OMG de le réaliser. L'erreur qu'ils ont fait était de ne vouloir se limiter qu'a des architectures à base de composants en mode synchrone alors que si je veux m'interconnecter avec ton système d'information Je me fous de savoir quelle est ton architecture. Pour connaitre tous les comptes d'un client ca ne m'interesse pas de parcourir tous les comptes de ta banque en vérifiant qu'il appartiennent bien au client rechercher dans ta banque alors qu'un autre partenaire à décidé que ses objets clients référencaient directement leur compte ou encore que celui ci a implémenté une facade pour se faire.
Ce qui m'interesse c'est
"Quelle est la liste des RIBs du client "Duchmoll Jean Pierre" dans la banque.
J'attend qu'on renvoie un simple liste de RIB et je ne veux pas savoir comment c'est foutu dans DBUS, DCOM, CORBA ou chez toi avec ton protocole personnalisé au dessus de RPC.
Moi je comprend mais surtout mes AMOs comprenent et là ils se disent que cette requête peut servir dans des autres procesus métiers ou que ce processus peut être amélirié si je la place à un autre endoit . Il peuvent faire des simulation et moi en tant qu'architecte je peux enfin capitaliser sur un catalogue de services réutilsable sans m'arracher les cheveux à chaque evolution du besoin.
Et là on rentre dans le SOA.
http://en.wikipedia.org/wiki/Service-oriented_architecture
Et là on commence à comprendre l'intérêt de WCF puisqu'il unifie tout dans une approche orientée service que ce soit dans mon réseau d'entreprise ou sur internet.
Voilà lorsque tu auras déjà admis ca et la compléxité inhéhente qui en découle (y'a pas d'appproche saine ou pas saine à avoir) tu pourras te pencher sur l'implémentation et comprendre l'interêt de celle de M$ et comparer sa compléxité avec des autres approches du même type. Pas en comparant avec l'API de DBUS comme tu le fais.
Quand ca t'arrange la comparaison vaut le coup et quand ca ne t'arrange pas il faut pas mélanger les torchons et les serviettes.
[^] # Re: Grmbl..
Posté par Bozo_le_clown . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 2.
Mplayer (sans changer d'option ni rien) : 0%
Tu veux dire que t'as droit à un core dump :)
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Bozo_le_clown . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 6.
"Et comment fait on lorsqu'il n'y a pas qu'une seule technologie à interconnecter ?".
Tu nous cites l'exemple DCOP /DBUS mais comment font ils pour communiquer avec du pur CORBA ou encore du DCOM.
Doit-on développer des ponts dans tous les sens avec toutes les technos existantes ou définir un standard, une couche supplémentaire vers laquelle chacune des technologies pourra s'interconnecter ?
Ce modèle en couche que tu critiques a pourtant permis de belles avancées comme la venue de l'internet.
Tu te souviens, ce fameux modèle OSI en 7 couches qui à permis l'interconnexion des réseaux.
http://en.wikipedia.org/wiki/OSI_model
En cherchant un peu tu dois bien trouver une réflexion du même genre qui critique ce modèle et qui regrette que tout le monde ne soit pas en ATM.
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Bozo_le_clown . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 4.
http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29
[^] # Re: Mercurial/SVN
Posté par Bozo_le_clown . En réponse à la dépêche Subversion 1.4.4. Évalué à 2.
http://subversion.tigris.org/issues/show_bug.cgi?id=695
[^] # Re: Mercurial/SVN
Posté par Bozo_le_clown . En réponse à la dépêche Subversion 1.4.4. Évalué à 4.
http://subversion.tigris.org/merge-tracking/
Plus de détail sur la problématique dans les cas d'utilisation
http://subversion.tigris.org/merge-tracking/requirements.htm(...)
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Bozo_le_clown . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 3.
opensource
http://www.sun.com/software/javafx/index.jsp
https://openjfx.dev.java.net/
Sans oublier Flex3 qui sera sous GPL aux dernières nouvelles et qui te permet de ne plus faire joujou directement avec le Flash
http://labs.adobe.com/technologies/flex/