L'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.
Je ne suis pas certain que la puissance des merges découle de la nature centralisée ou non des VCS.
SVN ne gère pas les merges correctement simplement parce qu'il ne sait pas faire la différence entre une branche et une recopie ce qui mène à plein de cas tordus.
Ajoute à ca que le stockage correspond à une séquence linéaire de révisions. Pour un merge, ceci oblige à parcourir toutes les révisions une par une même celles qui ne concernent pas les fichiers des arbos à merger.
Clearcase ou Perforce, bien que centralisés, prennent très bien en charge les merges même si le stockage s'effectue au niveau des répertoires et des fichiers. Ce sont des objets avec un identifiant et un historique unique. Les merge 3 ways sont sûrs et les merge d'arborescences sont relativement aussi même s'ils sont bien plus lents car il necessite de descndre recursivement dans l'arboresence et de traiter les fichiers/répertoires un par un.
La puissance des DVCS type git, hg ou monotone vient du fait qu'ils stockent les révisions qui se succèdent ou qui forkent sous forme de graphes (DAGs) et que les branches sont des objets de première classe. Il est donc aisé de déterminer quelles révisions sont concernées par un merge.
Cette évolution est intervenue plus tard dans l'histoire des VCS, mais on pourrait très bien imaginer qu'un nouvel outil centralisé adopte une architecture identique. Seulement, à quoi servirait de créer un nouveau VCS centralisé sur cette base alors que les DVCS sont supérieurs sur tant d'autres aspects et qu'ils proposent toutes les fonctionnalités des VCS (à l'exception du verrou pessimiste).
Etant donné que SVN utilise svn cp pour brancher et ne fait sémantiquement pas la différence entre une branche et une simple copie d'arbo ce problème n'est pas près d'être résolu. Les branches sont des objets à part entières dans Git
Quelque commentaires:
"""
Moving to 1.4, since, while cmpilato has started this work on the fs-atomic-
renames branch, it won't be merged before 1.3.
...
Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release, move to 1.8-consider.
...
Seems like this thing is going to be pushed out indefinitely.
"""
Ce bug a été ouvert en 2002 et il est reporté aux calendes grecques.
Nous en sommes à la 1.6.12.
Bonne chance les gars
Ceci permet de regrouper les changements à commiter.
Le mécanisme n'est pas aussi puissant que la mise en place de branches dédiées (inhérent aux DVCS) qui permet de commiter les changements de manière unitaire puis de reporter ceux que l'on souhaite sur le tronc (cherry-picking). D'ailleurs, si quelqu'un a déjà pu utiliser le cherry-picking correctement avec SVN, je suis preneur pour un retour d'expérience.
J'ai l'impression que votre différence d'appréciation provient de votre perspective.
Celle de rewind est technique alors que la tienne est plus d'ordre organisationnel.
Je m'explique:
Avec SVN, l'approche basique consiste à travailler dans une branche unique partagée.
Comme il n'y a a pas de clone du dépôt, chaque développeur prend en charge une demande de changement, la réalise et la remet dès qu'elle est traitée.
Au pire, il doit effectuer un merge avant de remettre mais il reste proche du développement principal.
Avec un DVCS (Bazaar et svk exceptés car il supportent les 2 modes), chaque développeur dispose de sa propre branche et il n'est pas possible de bosser sur une branche partagée (Avec Git et Hg, il me semble qu'il existe des mécanismes qui permettent de commiter et pusher dans la même transaction en contactant le dépôt principal mais ce n'est pas le workflow de base).
En revanche, il est naturel de prendre en charge plusieurs demandes à la suite et de le commiter dans sa propre branche en local sans être obligé de les reporter directement sur la branche principale.
De ce fait, puisque plusieurs changesets peuvent s'enchaîner sans réel besoin de les reporter sur le tronc, le développeur peut être tenté de s'isoler, ce qui occasionnera inévitablement un travail plus important à moment de l'intégration.
Pour appliquer cette stratégie avec SVN, il est nécessaire de créer explicitement une branche par développeur. Mais ceci n'est pas automatique et surtout, le fait que SVN ne supporte pas le rename tracking décourage fortement cette pratique dès qu'on fait un peu de refactoring (renommage de package par exemple). Le merge n'est pas automatique et il faut relancer le refactoring à la main dans la branche principale.
En revanche, d'un point de vue organisationnel les DVCS sont plus ouverts aux contributions en ce sens qu'ils n'obligent pas à se faire reconnaitre pour participer sur un projet.
Avec SVN, il faut accorder des droits en écriture sur le repository pour accueillir de nouveaux participants (hormis l'échange de diff/patch qui contourne le VCS) . Cet accès permet au contributeur d'accéder directement à la branche principale avec les risques qui s'ensuivent et un accès limité à une branche dédiée est plus complexe à mettre en oeuvre.
Avec un DVCS il suffit de cloner le repository et on peut commencer à bosser dans sa propre branche. Les développeurs du projet n'ont qu'à puller les changements dans leur propre dépôt local, merger les patchs qui les intéressent et remonter dans le dépôt principal sans besoin d'octroyer de droits sur ce dépôt. Ce n'est que lorsque le contributeur a fait ses preuves qu'il obtient ce privilège de pusher directement sur le dépôt central.
Ce workflow est plus complexe mais plus souple.
C'est la raison pour laquelle je considère que les DVCS se prêtent mieux aux projets communautaires alors que SVN de par sa simplicité et sa gestion centralisée des droits se prête mieux au monde l'entreprise.
Ça permet de savoir qui fait quoi, qui bosse sur quoi, qui va faire de grosses modifs, etc.
Ce n'est pas le rôle du VCS mais du bugtracker ou de la forge de faciliter cette communication.
S'il est centralisé, on sait qui a pris quoi, à quoi est dédiée telle branche.
J'entends souvent l'objection que tu évoques à savoir ce risque d'isolation qui fait que SVN colle si bien à l'intégration continue i.e à l'usage d'un branche unique.
En revanche, ce qui est sûr c'est qu'un outil comme SVN qui est incapable de supporter le "rename tracking" correctement (renommer un fichier différemment entre 2 branches perd l'historique de ce fichier lors du prochain merge entre ces 2 branches) ne peut supporter que l'integration continue et les branching par patch (une branche par patch que l'on tue une foi integrée).
Pas de salut pour les autres branching patterns (1 branche par developpeur , une par lot de fonctionnalité en vue d'un développement parallèle de plusieurs équipes avec une phase d'intégration avant la livraison, ...)
De là à dire que la mode de la CI n'existe que parce que SVN est déficient à la base, il n'y a qu'un pas.
Il semblerait qu'ils jouent à fond le jeu de l'open source car ils ont publié leur style de rendu et on peut voir un peu partout des références et liens vers OSM.
Où peut-on récupérer les sources de leur outil de calcul d'itinéraire ?
Savez-vous s'il existe de tels services en ligne libres au dessus d'OSM ?
Quelle est la différence si tu prêtes ta voiture et que tu reçois un PV. Tu es considéré comme responsable tant que tu ne dénonces pas le coupable.
Si tu te l'ai fait piquée tu dois le déclarer.
Si t'es parti en vacances et que tu n'étais pas au courant tu devras prouver tes dires.
Avec HADOPI c'est le même principe sauf qu'il est très difficile de savoir quand ta voiture a été piquée à l'insu de ton plein gré. Mais si tu as installé OpenOffice sur une machine qui ne fait rien, tu as prouvé ta bonne foi.
Que demander de plus ?
Qu'est-ce qu'on va rire !
L'idée de fumoir n'est pas conne du tout (pis on a pris l'habitude de se déplacer avant d'aller fumer).
Je ne suis pas certain que ca soit proscrit par la loi et après tout les fumeurs militants il y en a peuvent prendre des initiatives pou que ces locaux soit créés.
Ma seule exigence est que cet amnagement ne se répercute pas sur le prix du billet et donc que l'accès soit payant.
Après tout c'est un service.
Enfin, je bien veux bien m'amender tant que la SNCF est en situation de monopole, ce qui n'aide pas a obtenir le meilleur coût pour le service.
Mais c'est un autre débat.
Et sinon oui, la grande majorité des fumeurs sont des gros cons. J'en fait partie. Ça tient probablement au fait que la cloppe fait quand même complètement partie de notre vie, et que de là, on n'a un peu du mal à comprendre pourquoi les autres en font tout un plat.
Je ne pense pas, beaucoup en ont conscience et s'abstiennent lorsqu'il sont en minorité dans un endroit mais pour peu que l'un commence à dégainer, qu'ils soient majoritaires, tous se désinhibent et le gazage est assuré.
Oui sauf que ce compromis, certains n'en veulent pas, ils veulent des établissements entiers rien qu'à eux et qu'on appelle ca des bars.
Le compromis s'est donc transformé en rapport de force.
Et puisque tu parles de dictature de la majorité, si on regroupe les fumeurs qui tolèrent la fumée des autres par solidarité, les non-fumeurs qui font contre mauvaise fortune bon coeur et qu'on les met en face des asthmatiques des employés de bars non-fumeurs dont la santé est affectée et ceux à qui l'accès à certains bars était proscrit tellement la fumée brulait les yeux, je ne suis pas certains que la majorité soit du coté que tu penses. Et la loi est là pour protéger les minorités justement.
Mais je reprécise que depuis le début je suis favorable à ce compromis avec un aménagement.
Puisqu'on peut présumer que tu es de bonne foi, est-ce que le fait de t'isoler 5 mns dans un local avec un extracteur pour en griller une petite plutôt que de te geler les coucougnettes dehors te parait si gênant ?
Le prof de sport glandu qui se débarasse des morveux de 3e en les faisant galoper un 10000 m tous les mercredis pendant qu'il bombe le torse devant les gamines en terminale éco.
Je ne connais pas assez Mandriva pour émettre un avis sur les autres questions mais cette volonté de se concentrer en priorité (voir exclusivement pour l'entreprise) sur KDE me semble une bonne chose.
On ne peut pas courir plusieurs lièvres à la fois avec des moyens réduits et il reste un espace à occuper sur ce créneau.
Cette hésitation entre les 2 et la volonté de couvrir ces 2 bureaux a toujours été selon moi (Drakeconf, choix des applis, ...) le principal pb qui laissait un arrière goût de mauvaise finition (mais bon mes derniers tests avec Mandriva datent un peu, je le reconnais)
Canonical a joué cette stratégie avec Gnome et ca ne lui réussit pas trop mal (en terme d'occupation de l'espace, j'entends, pas forcement en terme de rentabilité économique)
Kubuntu est laissé aux soins de la communauté et on ne peut pas dire que ce soit un franc succès.
Redhat se concentre sur les serveurs.
Il reste Novell comme concurrent, mais on ne peut pas dire qu'il soit au même niveau de finition que ce qu'à réussi Canonical avec Ubuntu. Ils ont donc un créneau à prendre.
J'entends bien, mais on ne peut matériellement pas se battre en permanence sur tous les sujets.
Le "consumérisme" de la démocratie découle de ce qu'elle est représentative et non directe ou semi-directe.
Elle a ses travers (l'implication, le menu n'est jamais 100% celui qu'on voudrait) mais aussi ses avantages (la délégation).
Je note toutefois volonté d'apiasemnt en ce que ta réponse ne consiste pas simplement à m'assimiler à un "nazilllon" liberticide.
Ouaiche, l'objectif était surtout de montrer qu'il est parfois difficile de corriger un déséquilibre sans le coup de pouce de la loi.
Mais plus j'y pense et plus je trouve que l'analogie tient la route.
L'omniprésence des établissement fumeurs n'est pas étrangère à la notoriété ausi. Le tabagisme a pris de l'ampleur par effet de mode alors qu'on ignorait ou taisait ses effets néfastes.
Les brevets logiciels sont au proprio ce que la fumée est au tabac: une pollution nuisible pour ceux qui veulent fréquenter le marché informatique sans fumée.
[^] # Re: Les DVCS encouragent le travail collaboratif
Posté par El Titi . En réponse au journal Git malgré moi. Évalué à 3.
L'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.
Je ne suis pas certain que la puissance des merges découle de la nature centralisée ou non des VCS.
SVN ne gère pas les merges correctement simplement parce qu'il ne sait pas faire la différence entre une branche et une recopie ce qui mène à plein de cas tordus.
Ajoute à ca que le stockage correspond à une séquence linéaire de révisions. Pour un merge, ceci oblige à parcourir toutes les révisions une par une même celles qui ne concernent pas les fichiers des arbos à merger.
Clearcase ou Perforce, bien que centralisés, prennent très bien en charge les merges même si le stockage s'effectue au niveau des répertoires et des fichiers. Ce sont des objets avec un identifiant et un historique unique. Les merge 3 ways sont sûrs et les merge d'arborescences sont relativement aussi même s'ils sont bien plus lents car il necessite de descndre recursivement dans l'arboresence et de traiter les fichiers/répertoires un par un.
La puissance des DVCS type git, hg ou monotone vient du fait qu'ils stockent les révisions qui se succèdent ou qui forkent sous forme de graphes (DAGs) et que les branches sont des objets de première classe. Il est donc aisé de déterminer quelles révisions sont concernées par un merge.
Cette évolution est intervenue plus tard dans l'histoire des VCS, mais on pourrait très bien imaginer qu'un nouvel outil centralisé adopte une architecture identique. Seulement, à quoi servirait de créer un nouveau VCS centralisé sur cette base alors que les DVCS sont supérieurs sur tant d'autres aspects et qu'ils proposent toutes les fonctionnalités des VCS (à l'exception du verrou pessimiste).
[^] # Re: Git malgré moi
Posté par El Titi . En réponse au journal Git malgré moi. Évalué à 1.
du problème:
http://subversion.tigris.org/issues/show_bug.cgi?id=898
Etant donné que SVN utilise svn cp pour brancher et ne fait sémantiquement pas la différence entre une branche et une simple copie d'arbo ce problème n'est pas près d'être résolu. Les branches sont des objets à part entières dans Git
Quelque commentaires:
"""
Moving to 1.4, since, while cmpilato has started this work on the fs-atomic-
renames branch, it won't be merged before 1.3.
...
Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release,
move to 1.8-consider.
...
Seems like this thing is going to be pushed out indefinitely.
"""
Ce bug a été ouvert en 2002 et il est reporté aux calendes grecques.
Nous en sommes à la 1.6.12.
Bonne chance les gars
[^] # Re: staging area
Posté par El Titi . En réponse au journal Git malgré moi. Évalué à 2.
http://svnbook.red-bean.com/en/1.5/svn.advanced.changelists.(...)
Ceci permet de regrouper les changements à commiter.
Le mécanisme n'est pas aussi puissant que la mise en place de branches dédiées (inhérent aux DVCS) qui permet de commiter les changements de manière unitaire puis de reporter ceux que l'on souhaite sur le tronc (cherry-picking). D'ailleurs, si quelqu'un a déjà pu utiliser le cherry-picking correctement avec SVN, je suis preneur pour un retour d'expérience.
[^] # Re: Git malgré moi
Posté par El Titi . En réponse au journal Git malgré moi. Évalué à 3.
Celle de rewind est technique alors que la tienne est plus d'ordre organisationnel.
Je m'explique:
Avec SVN, l'approche basique consiste à travailler dans une branche unique partagée.
Comme il n'y a a pas de clone du dépôt, chaque développeur prend en charge une demande de changement, la réalise et la remet dès qu'elle est traitée.
Au pire, il doit effectuer un merge avant de remettre mais il reste proche du développement principal.
Avec un DVCS (Bazaar et svk exceptés car il supportent les 2 modes), chaque développeur dispose de sa propre branche et il n'est pas possible de bosser sur une branche partagée (Avec Git et Hg, il me semble qu'il existe des mécanismes qui permettent de commiter et pusher dans la même transaction en contactant le dépôt principal mais ce n'est pas le workflow de base).
En revanche, il est naturel de prendre en charge plusieurs demandes à la suite et de le commiter dans sa propre branche en local sans être obligé de les reporter directement sur la branche principale.
De ce fait, puisque plusieurs changesets peuvent s'enchaîner sans réel besoin de les reporter sur le tronc, le développeur peut être tenté de s'isoler, ce qui occasionnera inévitablement un travail plus important à moment de l'intégration.
Pour appliquer cette stratégie avec SVN, il est nécessaire de créer explicitement une branche par développeur. Mais ceci n'est pas automatique et surtout, le fait que SVN ne supporte pas le rename tracking décourage fortement cette pratique dès qu'on fait un peu de refactoring (renommage de package par exemple). Le merge n'est pas automatique et il faut relancer le refactoring à la main dans la branche principale.
En revanche, d'un point de vue organisationnel les DVCS sont plus ouverts aux contributions en ce sens qu'ils n'obligent pas à se faire reconnaitre pour participer sur un projet.
Avec SVN, il faut accorder des droits en écriture sur le repository pour accueillir de nouveaux participants (hormis l'échange de diff/patch qui contourne le VCS) . Cet accès permet au contributeur d'accéder directement à la branche principale avec les risques qui s'ensuivent et un accès limité à une branche dédiée est plus complexe à mettre en oeuvre.
Avec un DVCS il suffit de cloner le repository et on peut commencer à bosser dans sa propre branche. Les développeurs du projet n'ont qu'à puller les changements dans leur propre dépôt local, merger les patchs qui les intéressent et remonter dans le dépôt principal sans besoin d'octroyer de droits sur ce dépôt. Ce n'est que lorsque le contributeur a fait ses preuves qu'il obtient ce privilège de pusher directement sur le dépôt central.
Ce workflow est plus complexe mais plus souple.
C'est la raison pour laquelle je considère que les DVCS se prêtent mieux aux projets communautaires alors que SVN de par sa simplicité et sa gestion centralisée des droits se prête mieux au monde l'entreprise.
Voilà je crains avoir encore plus délayé que toi.
[^] # Re: Mon ressentit
Posté par El Titi . En réponse au journal Git malgré moi. Évalué à 4.
Ça permet de savoir qui fait quoi, qui bosse sur quoi, qui va faire de grosses modifs, etc.
Ce n'est pas le rôle du VCS mais du bugtracker ou de la forge de faciliter cette communication.
S'il est centralisé, on sait qui a pris quoi, à quoi est dédiée telle branche.
J'entends souvent l'objection que tu évoques à savoir ce risque d'isolation qui fait que SVN colle si bien à l'intégration continue i.e à l'usage d'un branche unique.
Et pourtant la CI n'est pas l'apanage des outils centralisés.
Je te conseille cet excellent papier de Martin Fowler sur le sujet
http://martinfowler.com/bliki/FeatureBranch.html
En revanche, ce qui est sûr c'est qu'un outil comme SVN qui est incapable de supporter le "rename tracking" correctement (renommer un fichier différemment entre 2 branches perd l'historique de ce fichier lors du prochain merge entre ces 2 branches) ne peut supporter que l'integration continue et les branching par patch (une branche par patch que l'on tue une foi integrée).
Pas de salut pour les autres branching patterns (1 branche par developpeur , une par lot de fonctionnalité en vue d'un développement parallèle de plusieurs équipes avec une phase d'intégration avant la livraison, ...)
De là à dire que la mode de la CI n'existe que parce que SVN est déficient à la base, il n'y a qu'un pas.
[^] # Re: Clé WEP...
Posté par El Titi . En réponse au journal Je suis plein de bonne volontés. Évalué à 2.
# Libre
Posté par El Titi . En réponse au journal MapQuest se met à OpenStreetMap. Évalué à 5.
Il semblerait qu'ils jouent à fond le jeu de l'open source car ils ont publié leur style de rendu et on peut voir un peu partout des références et liens vers OSM.
Où peut-on récupérer les sources de leur outil de calcul d'itinéraire ?
Savez-vous s'il existe de tels services en ligne libres au dessus d'OSM ?
[^] # Re: Pas qu'au Brésil
Posté par El Titi . En réponse au journal “Le Brésil est un vrai marché pour le desktop Linux, justifie Arnaud Laprévote, la moitié des PC sont sous Linux”.. Évalué à 3.
[^] # Re: Chiffrement des données
Posté par El Titi . En réponse à la dépêche Le Parlement Européen adopte le rapport Gallo pro-ACTA. Évalué à 3.
[^] # Re: Et encore...
Posté par El Titi . En réponse à la dépêche Le Parlement Européen adopte le rapport Gallo pro-ACTA. Évalué à 6.
http://fr.wikipedia.org/wiki/Croix_gamm%C3%A9e
[^] # Re: Vendredi
Posté par El Titi . En réponse au journal Marre du dévelopement bloatware moderne ! Appel aux armes !. Évalué à 3.
[^] # Re: Clé WEP...
Posté par El Titi . En réponse au journal Je suis plein de bonne volontés. Évalué à 5.
Si tu te l'ai fait piquée tu dois le déclarer.
Si t'es parti en vacances et que tu n'étais pas au courant tu devras prouver tes dires.
Avec HADOPI c'est le même principe sauf qu'il est très difficile de savoir quand ta voiture a été piquée à l'insu de ton plein gré. Mais si tu as installé OpenOffice sur une machine qui ne fait rien, tu as prouvé ta bonne foi.
Que demander de plus ?
Qu'est-ce qu'on va rire !
[^] # Re: Clé WEP...
Posté par El Titi . En réponse au journal Je suis plein de bonne volontés. Évalué à 10.
Aujourd'hui, si tu ne sécurises pas ta piscine et qu'un cambrioleur se noie dedans, tu risques des ennuis.
# Hypocrite !
Posté par El Titi . En réponse au journal Je suis plein de bonne volontés. Évalué à 4.
http://www.pcinpact.com/actu/news/59542-hadopi-victime-attaq(...)
Comment-ca tu n'es pas sous Windows ?
[^] # Re: Trop gentil
Posté par El Titi . En réponse au journal Meilleures marques 2010.... Évalué à 2.
L'idée de fumoir n'est pas conne du tout (pis on a pris l'habitude de se déplacer avant d'aller fumer).
Je ne suis pas certain que ca soit proscrit par la loi et après tout les fumeurs militants il y en a peuvent prendre des initiatives pou que ces locaux soit créés.
Ma seule exigence est que cet amnagement ne se répercute pas sur le prix du billet et donc que l'accès soit payant.
Après tout c'est un service.
Enfin, je bien veux bien m'amender tant que la SNCF est en situation de monopole, ce qui n'aide pas a obtenir le meilleur coût pour le service.
Mais c'est un autre débat.
Et sinon oui, la grande majorité des fumeurs sont des gros cons. J'en fait partie. Ça tient probablement au fait que la cloppe fait quand même complètement partie de notre vie, et que de là, on n'a un peu du mal à comprendre pourquoi les autres en font tout un plat.
Je ne pense pas, beaucoup en ont conscience et s'abstiennent lorsqu'il sont en minorité dans un endroit mais pour peu que l'un commence à dégainer, qu'ils soient majoritaires, tous se désinhibent et le gazage est assuré.
[^] # Re: Trop gentil
Posté par El Titi . En réponse au journal Meilleures marques 2010.... Évalué à 2.
Le compromis s'est donc transformé en rapport de force.
Et puisque tu parles de dictature de la majorité, si on regroupe les fumeurs qui tolèrent la fumée des autres par solidarité, les non-fumeurs qui font contre mauvaise fortune bon coeur et qu'on les met en face des asthmatiques des employés de bars non-fumeurs dont la santé est affectée et ceux à qui l'accès à certains bars était proscrit tellement la fumée brulait les yeux, je ne suis pas certains que la majorité soit du coté que tu penses. Et la loi est là pour protéger les minorités justement.
Mais je reprécise que depuis le début je suis favorable à ce compromis avec un aménagement.
[^] # Re: Trop gentil
Posté par El Titi . En réponse au journal Meilleures marques 2010.... Évalué à 3.
Puisqu'on peut présumer que tu es de bonne foi, est-ce que le fait de t'isoler 5 mns dans un local avec un extracteur pour en griller une petite plutôt que de te geler les coucougnettes dehors te parait si gênant ?
Le taliban
[^] # Re: à voter
Posté par El Titi . En réponse au journal Sondage pour les utilisateurs de Git. Évalué à 4.
Le prof de sport glandu qui se débarasse des morveux de 3e en les faisant galoper un 10000 m tous les mercredis pendant qu'il bombe le torse devant les gamines en terminale éco.
[^] # Re: à voter
Posté par El Titi . En réponse au journal Sondage pour les utilisateurs de Git. Évalué à 3.
Le prof de math
[^] # Re: Pas qu'au Brésil
Posté par El Titi . En réponse au journal “Le Brésil est un vrai marché pour le desktop Linux, justifie Arnaud Laprévote, la moitié des PC sont sous Linux”.. Évalué à 4.
je tombe des nues.
[^] # Re: recentrage KDE
Posté par El Titi . En réponse à la dépêche Mandriva se rebiffe. Évalué à 9.
======> []
# recentrage KDE
Posté par El Titi . En réponse à la dépêche Mandriva se rebiffe. Évalué à 8.
On ne peut pas courir plusieurs lièvres à la fois avec des moyens réduits et il reste un espace à occuper sur ce créneau.
Cette hésitation entre les 2 et la volonté de couvrir ces 2 bureaux a toujours été selon moi (Drakeconf, choix des applis, ...) le principal pb qui laissait un arrière goût de mauvaise finition (mais bon mes derniers tests avec Mandriva datent un peu, je le reconnais)
Canonical a joué cette stratégie avec Gnome et ca ne lui réussit pas trop mal (en terme d'occupation de l'espace, j'entends, pas forcement en terme de rentabilité économique)
Kubuntu est laissé aux soins de la communauté et on ne peut pas dire que ce soit un franc succès.
Redhat se concentre sur les serveurs.
Il reste Novell comme concurrent, mais on ne peut pas dire qu'il soit au même niveau de finition que ce qu'à réussi Canonical avec Ubuntu. Ils ont donc un créneau à prendre.
Etant KDiste par inclination, je m'en réjouis.
Bonne chance !
[^] # Re: Trop gentil
Posté par El Titi . En réponse au journal Meilleures marques 2010.... Évalué à 2.
Le "consumérisme" de la démocratie découle de ce qu'elle est représentative et non directe ou semi-directe.
Elle a ses travers (l'implication, le menu n'est jamais 100% celui qu'on voudrait) mais aussi ses avantages (la délégation).
Je note toutefois volonté d'apiasemnt en ce que ta réponse ne consiste pas simplement à m'assimiler à un "nazilllon" liberticide.
[^] # Re: Trop gentil
Posté par El Titi . En réponse au journal Meilleures marques 2010.... Évalué à 3.
Mais plus j'y pense et plus je trouve que l'analogie tient la route.
L'omniprésence des établissement fumeurs n'est pas étrangère à la notoriété ausi. Le tabagisme a pris de l'ampleur par effet de mode alors qu'on ignorait ou taisait ses effets néfastes.
Les brevets logiciels sont au proprio ce que la fumée est au tabac: une pollution nuisible pour ceux qui veulent fréquenter le marché informatique sans fumée.
[^] # Re: Trop gentil
Posté par El Titi . En réponse au journal Meilleures marques 2010.... Évalué à 2.
La loi Evin aurait pu être corrigée pour prévenir certaines dérives.