Parts de marché : OS X en hausse, Windows en baisse

wildpeaks a écrit:
Euh question bête, pourquoi on nous parle d'une augmentation de 21% puisque l'augmentation est de 0.03% (7,31% à 7,57%) ??

soit 7 = 70% de PdM 100% = 10... si demain on passe de 10 utilisateurs d'OS dans le monde à 16 alors en passent de 7 à 8 tu passes gagne pas 10% (7=70% donc 8=80%) mais tu baisses au contraire de 20% (en passant de 70% à 50%)

Enfin c'est l'idée :paf:

Bref un joli traficage de chiffres pour essayer de nous faire gober une augmentation plus grande qu'elle n'est :pfff:

wildpeaks a écrit:
Bref un joli traficage de chiffres pour essayer de nous faire gober une augmentation plus grande qu'elle n'est :pfff:

pro-MS spotted :o T'as de la chance j'ai pas de caillou sous la main :paf:
Edité le 06/02/2008 à 16:20

megadub a écrit:

taigaIV a écrit:
Tu auras un probleme de replication au niveau de la base lorsque tu tenterras de faire quelque chose d'incoherent (faire un insert en specifiant une clef primaire qui existe deja par exemple) pour ce qui est des update le probleme n'a rien a voir.

Bon... maintenant qu'on est d'accord, je te dis qu'Oracle peut gérer ce type de problème automatiquement MEME sur les updates :)

taigaIV a écrit:
Pour ce qui est du partitionnement en ce debrouillant autrement tu auras quelque chose de moins fin qu'Oracle (encore faut il que ce soit veritablement necessaire ce qui n'est pas le cas general).

on est d'accord, c'est dans des cas bien particuliers mais ça n'avait pour autre objet de mettre en avant les manques de MySQL ou plutôt les atouts d'Oracle si tu préfères.

:non: une fois de plus nous ne sommes pas d accord. Le fait de gerer automatiquement ce genre de probleme implique simplement que ta base va prendre une decision a ta place tu dois donc le prendre en compte dans ton dev, rien de miraculeux la dedans.
Sur les update il n'y a pas veritablement de probleme il faut savoir comment la base ce comporte.

megadub a écrit:

wildpeaks a écrit:
Bref un joli traficage de chiffres pour essayer de nous faire gober une augmentation plus grande qu'elle n'est :pfff:

pro-MS spotted :o T'as de la chance j'ai pas de caillou sous la main :paf:

La dernière fois on m'a traité de troll anti-MS, çà change :p

taigaIV a écrit:

:non: une fois de plus nous ne sommes pas d accord. Le fait de gerer automatiquement ce genre de probleme implique simplement que ta base va prendre une decision a ta place tu dois donc le prendre en compte dans ton dev, rien de miraculeux la dedans.
Sur les update il n'y a pas veritablement de probleme il faut savoir comment la base ce comporte.

:lol: c'est paramètrable évidemment ;) Si t'as envie que ça se vautre comme une @!#$?* c'est possible ;)

Pour les updates le problème est le suivant. Imagine la description d'une voiture : 4 portes, bleue, diesel, HDI 110

Le 1° change le moteur et le carburant : essence, 90i
Le 2° ne change que le moteur : HDI 90

Tu fais quoi ? essence et HDI 90 alors que le moteur HDI est forcément diesel ? Voila un exemple de conflit et c'est un problème technique qui peut être régler en connaissant le fonctionnel et en gérant un conflit (sachant qu'Oracle permet de déclencher l'exécution d'une procédure stockée en cas de conflit).

Enfin, voila, c'est juste pour info :jap:

---

wildpeaks a écrit:

La dernière fois on m'a traité de troll anti-MS, çà change :p

pas tant que ça... t'es un troll, tout le monde est d'accord là-dessus :ane:
Edité le 06/02/2008 à 16:27

wildpeaks a écrit:
Bref un joli traficage de chiffres pour essayer de nous faire gober une augmentation plus grande qu'elle n'est :pfff:

Tu parles de vos calculs ?

de 7,31 a 7,57 il y a environ 3,55% d augmentation.

megadub a écrit:
pas tant que ça... t'es un troll, tout le monde est d'accord là-dessus :ane:

Sarkopathe n'est pas d'accord :o

---

taigaIV a écrit:
Tu parles de vos calculs ?

de 7,31 a 7,57 il y a environ 3,55% d augmentation.

Tout dépend de la façon dont on calcule (7.57 = 1.03 * 7.31, d'où mon chiffre d'une augmentation de 0.03 que j'ai n00bingment oublié de multiplier par 100 ce qui fait 3% en effet), mais même 3.55% ne fait pas 21%. En prenant exprès le calcul pour lequel le chiffre est le plus grand (et encore, je ne suis pas sûre par quel chapeau ils ont fait sortir ce lapin), c'est pour faire paraître une grosse progression alors qu'en fait non :neutre:
Edité le 06/02/2008 à 16:34

taigaIV a écrit:

wildpeaks a écrit:
Bref un joli traficage de chiffres pour essayer de nous faire gober une augmentation plus grande qu'elle n'est :pfff:

Tu parles de vos calculs ?

de 7,31 a 7,57 il y a environ 3,55% d augmentation.

d'augmentation sur le marché global pas en nombre d'utilisateurs... -_-;;

tampigns a écrit:

taigaIV a écrit:

wildpeaks a écrit:
Bref un joli traficage de chiffres pour essayer de nous faire gober une augmentation plus grande qu'elle n'est :pfff:

Tu parles de vos calculs ?

de 7,31 a 7,57 il y a environ 3,55% d augmentation.

d'augmentation sur le marché global pas en nombre d'utilisateurs... -_-;;

Et le marché total c'est censé être quoi si pas les utilisateurs ? :heink:

J'ai mieux sur linux :

((0.67/0.63)^12mois*6ans)*0.63=53% // 6 ans pour que linux atteigne une pdm acceptable

Bon megadub et taigaIV faites un concours de requete* pour savoir qui a raison et qui sait ce qui dit

*faire attention de pas faire une faute de typo

wildpeaks a écrit:

tampigns a écrit:

taigaIV a écrit:

wildpeaks a écrit:
Bref un joli traficage de chiffres pour essayer de nous faire gober une augmentation plus grande qu'elle n'est :pfff:

Tu parles de vos calculs ?

de 7,31 a 7,57 il y a environ 3,55% d augmentation.

d'augmentation sur le marché global pas en nombre d'utilisateurs... -_-;;

Et le marché total c'est censé être quoi si pas les utilisateurs ? :heink:

Le marché peut baisser par exemple et dans ce cas même si tes parts de marché augmentent alors tu peux avoir perdu des clients

Et ma phrase = 3.55% d'augmetation sur le marché global mais pas d'augmentation par rapport à mon nombre d'utilisateurs
qui dans ce cas représente +21%

megadub a écrit:

taigaIV a écrit:

:non: une fois de plus nous ne sommes pas d accord. Le fait de gerer automatiquement ce genre de probleme implique simplement que ta base va prendre une decision a ta place tu dois donc le prendre en compte dans ton dev, rien de miraculeux la dedans.
Sur les update il n'y a pas veritablement de probleme il faut savoir comment la base ce comporte.

:lol: c'est paramètrable évidemment ;) Si t'as envie que ça se vautre comme une @!#$?* c'est possible ;)

Pour les updates le problème est le suivant. Imagine la description d'une voiture : 4 portes, bleue, diesel, HDI 110

Le 1° change le moteur et le carburant : essence, 90i
Le 2° ne change que le moteur : HDI 90

Tu fais quoi ? essence et HDI 90 alors que le moteur HDI est forcément diesel ? Voila un exemple de conflit et c'est un problème technique qui peut être régler en connaissant le fonctionnel et en gérant un conflit (sachant qu'Oracle permet de déclencher l'exécution d'une procédure stockée en cas de conflit).

Enfin, voila, c'est juste pour info :jap:

Donc tu as une base de donnees qui connait l essence utilisee par les differents type de moteur, bien.
Trouves un exemple qui tient la route, la ce n'est pas franchement un probleme de conflit (et si c etait le cas aucune des mises a jour n auraient du passer), peut etre un probleme de coherence (encore faut il que tu es mis des contraintes serieuses pour que la db s en occupe).
Si j ai besoins d'info je vais lire des docs et avoir des infos completes, ton truc est un peu trop court pour etre utile.

---

gentoux a écrit:
J'ai mieux sur linux :

((0.67/0.63)^12mois*6ans)*0.63=53% // 6 ans pour que linux atteigne une pdm acceptable

Bon megadub et taigaIV faites un concours de requete* pour savoir qui a raison et qui sait ce qui dit

*faire attention de pas faire une faute de typo

J ai bien explicite que j avais quitter la maternelle et que je ne voulais pas y retourner. Mais si tu veux ma place je te la laisse volontier ;)

tampigns a écrit:

wildpeaks a écrit:

tampigns a écrit:

taigaIV a écrit:

wildpeaks a écrit:
Bref un joli traficage de chiffres pour essayer de nous faire gober une augmentation plus grande qu'elle n'est :pfff:

Tu parles de vos calculs ?

de 7,31 a 7,57 il y a environ 3,55% d augmentation.

d'augmentation sur le marché global pas en nombre d'utilisateurs... -_-;;

Et le marché total c'est censé être quoi si pas les utilisateurs ? :heink:

Le marché peut baisser par exemple et dans ce cas même si tes parts de marché augmentent alors tu peux avoir perdu des clients

Et ma phrase = 3.55% d'augmetation sur le marché global mais pas d'augmentation par rapport à mon nombre d'utilisateurs
qui dans ce cas représente +21%

Mouais, un peu foireux comme pourcentage s'ils ont pris çà, à ce compte-là tous les OS augmentent vu que la population terrestre augmente :/
Edité le 06/02/2008 à 16:49

wildpeaks a écrit:

tampigns a écrit:

wildpeaks a écrit:

tampigns a écrit:

taigaIV a écrit:

wildpeaks a écrit:
Bref un joli traficage de chiffres pour essayer de nous faire gober une augmentation plus grande qu'elle n'est :pfff:

Tu parles de vos calculs ?

de 7,31 a 7,57 il y a environ 3,55% d augmentation.

d'augmentation sur le marché global pas en nombre d'utilisateurs... -_-;;

Et le marché total c'est censé être quoi si pas les utilisateurs ? :heink:

Le marché peut baisser par exemple et dans ce cas même si tes parts de marché augmentent alors tu peux avoir perdu des clients

Et ma phrase = 3.55% d'augmetation sur le marché global mais pas d'augmentation par rapport à mon nombre d'utilisateurs
qui dans ce cas représente +21%

Mouais, un peu foireux comme pourcentage s'ils ont pris çà, à ce compte-là tous les OS augmentent vu que la population terrestre augmente :/

exactement ;)

taigaIV a écrit:

Donc tu as une base de donnees qui connait l essence utilisee par les differents type de moteur, bien.

L'exemple est tout à fait valable et non la base ne connait pas forcément la correspondance moteur/carburant :neutre:

Visiblement tu n'as pas compris... techniquement ça ne marche pas parce que le mécanisme de réplication vérifie chacune des colonnes avant de les mettre à jour. Ainsi, si tu modifies une valeur avant la réplication, lors de la réplication il y aura un conflit parce qu'il détecte que tu essayes de répliquer une ligne déjà modifiée. C'est le principe de la répli et pourquoi tu as des conflits :)

taigaIV a écrit:

Trouves un exemple qui tient la route, la ce n'est pas franchement un probleme de conflit (et si c etait le cas aucune des mises a jour n auraient du passer), peut etre un probleme de coherence (encore faut il que tu es mis des contraintes serieuses pour que la db s en occupe).

Bah si tu ne connais pas la répli n'en parle pas :neutre: Lorsque tu montes une réplication il est important de gérer ces contraintes dans l'appli. Par exemple par des habilitations sur les users pour garantir qu'ils travaillent sur des ensembles différents. Ou alors, tu fais une gestion automatique de conflits (ce que permet Oracle). Par exemple tu peux décider que si seule la date de dernière modif change on garde la plus grande valeur sans générer de conflit.

Evidemment, si tu fais une répli et que tu laisses n'importe qui faire n'importe quoi ta répli ne marchera jamais... ou alors il faut désigner un master qui sera toujours plus fort :neutre:

taigaIV a écrit:
Si j ai besoins d'info je vais lire des docs et avoir des infos completes, ton truc est un peu trop court pour etre utile.

j'suis sympa j'te fais gagner du temps :D Si tu t'en fous bah on en reste là au risque de sortir des grosses conneries en parlant de réplication :neutre:

Plutôt que d'envoyer des infos comme si c'était l'évangile je préfère expliquer :neutre:
Edité le 06/02/2008 à 17:21

megadub a écrit:

taigaIV a écrit:

Donc tu as une base de donnees qui connait l essence utilisee par les differents type de moteur, bien.

L'exemple est tout à fait valable et non la base ne connait pas forcément la correspondance moteur/carburant :neutre:

Visiblement tu n'as pas compris... techniquement ça ne marche pas parce que le mécanisme de réplication vérifie chacune des colonnes avant de les mettre à jour. Ainsi, si tu modifies une valeur avant la réplication, lors de la réplication il y aura un conflit parce qu'il détecte que tu essayes de répliquer une ligne déjà modifiée. C'est le principe de la répli et pourquoi tu as des conflits :)

taigaIV a écrit:

Trouves un exemple qui tient la route, la ce n'est pas franchement un probleme de conflit (et si c etait le cas aucune des mises a jour n auraient du passer), peut etre un probleme de coherence (encore faut il que tu es mis des contraintes serieuses pour que la db s en occupe).

Bah si tu ne connais pas la répli n'en parle pas :neutre: Lorsque tu montes une réplication il est important de gérer ces contraintes dans l'appli. Par exemple par des habilitations sur les users pour garantir qu'ils travaillent sur des ensembles différents. Ou alors, tu fais une gestion automatique de conflits (ce que permet Oracle). Par exemple tu peux décider que si seule la date de dernière modif change on garde la plus grande valeur sans générer de conflit.

Evidemment, si tu fais une répli et que tu laisses n'importe qui faire n'importe quoi ta répli ne marchera jamais... ou alors il faut désigner un master qui sera toujours plus fort :neutre:

taigaIV a écrit:
Si j ai besoins d'info je vais lire des docs et avoir des infos completes, ton truc est un peu trop court pour etre utile.

j'suis sympa j'te fais gagner du temps :D Si tu t'en fous bahon en reste là au risque de sortir des grosses conneries en parlant de réplication :neutre:

Je ne vais pas faire de mal a tes illusions, je vais te laisser tranquillement penser qu'il n y a que ton petit monde qui existe et qu'il n'y a pas d'autres niveaux. Les problematique que tu as avec Oracle ne sont pas automatiquement generique, perso j utilises MySQL, je fais de la replication circulaire et ca marche tres bien.

taigaIV a écrit:

Je ne vais pas faire de mal a tes illusions, je vais te laisser tranquillement penser qu'il n y a que ton petit monde qui existe et qu'il n'y a pas d'autres niveaux. Les problematique que tu as avec Oracle ne sont pas automatiquement generique, perso j utilises MySQL, je fais de la replication circulaire et ca marche tres bien.

Plutôt que de buter bêtement c'est pas plus intéressant de discuter ? :heink:

Tu la fais comment ta répli circulaire ? maitre - esclave, maitre - maitre, autre ? J'aimerai comprendre si c'est pas trop demander ? Si tu veux juste troller et asséner TES vérités, effectivement ça sert à rien de répondre...

Sinon, la problématique de conflit c'est pas propre à Oracle :neutre:
Edité le 06/02/2008 à 17:27

---

Pour rappel :

taigaIV a écrit:

megadub a écrit:

Pour moi, ce qui fait la différence c'est :
- gestion du partitionnement et sous-partitionnement avec un parallélisme adapté
- clusterisation et haute-dispo
- gestionnaire de sauvegarde qui ne sauve que les blocs de données modifiés
- console d'administration centralisée
- robustesse de la base de données
- compatibilité SQL-92
- présence d'ordonnanceur et gestion des triggers avancé

Des conflits ?

Si tu t'en tapes pourquoi tu poses la question :fou:

megadub a écrit:

taigaIV a écrit:

Je ne vais pas faire de mal a tes illusions, je vais te laisser tranquillement penser qu'il n y a que ton petit monde qui existe et qu'il n'y a pas d'autres niveaux. Les problematique que tu as avec Oracle ne sont pas automatiquement generique, perso j utilises MySQL, je fais de la replication circulaire et ca marche tres bien.

Plutôt que de buter bêtement c'est pas plus intéressant de discuter ? :heink:

Tu la fais comment ta répli circulaire ? maitre - esclave, maitre - maitre, autre ? J'aimerai comprendre si c'est pas trop demander ? Si tu veux juste troller et asséner TES vérités, effectivement ça sert à rien de répondre...

Sinon, la problématique de conflit c'est pas propre à Oracle :neutre:

---

Pour rappel :

taigaIV a écrit:

megadub a écrit:

Pour moi, ce qui fait la différence c'est :
- gestion du partitionnement et sous-partitionnement avec un parallélisme adapté
- clusterisation et haute-dispo
- gestionnaire de sauvegarde qui ne sauve que les blocs de données modifiés
- console d'administration centralisée
- robustesse de la base de données
- compatibilité SQL-92
- présence d'ordonnanceur et gestion des triggers avancé

Des conflits ?

Si tu t'en tapes pourquoi tu poses la question :fou:

Il y a un moment ou discuter devient passablement penible, surtout avec le concours de qui a la plus grosses et un paquet de troll qui trainnent dans le coins.
Dans le cadre de le replication circulaire tu n as pas franchement de notion de maitre et d esclave (disons qu ils sont tous maitre/escalve les uns pour les autres).
Il n y a pas de notion de conflit avec My, tu auras une erreur de replication lorsqu'il ce retrouve dans une situation incoherente. La replication MySQL est tres simple, tu rejous tes requetes des maitres sur les esclaves une fois que tu le sais tu gere les problemes au niveau applicatif.

taigaIV a écrit:

megadub a écrit:

taigaIV a écrit:

Je ne vais pas faire de mal a tes illusions, je vais te laisser tranquillement penser qu'il n y a que ton petit monde qui existe et qu'il n'y a pas d'autres niveaux. Les problematique que tu as avec Oracle ne sont pas automatiquement generique, perso j utilises MySQL, je fais de la replication circulaire et ca marche tres bien.

Plutôt que de buter bêtement c'est pas plus intéressant de discuter ? :heink:

Tu la fais comment ta répli circulaire ? maitre - esclave, maitre - maitre, autre ? J'aimerai comprendre si c'est pas trop demander ? Si tu veux juste troller et asséner TES vérités, effectivement ça sert à rien de répondre...

Sinon, la problématique de conflit c'est pas propre à Oracle :neutre:

---

Pour rappel :

taigaIV a écrit:

megadub a écrit:

Pour moi, ce qui fait la différence c'est :
- gestion du partitionnement et sous-partitionnement avec un parallélisme adapté
- clusterisation et haute-dispo
- gestionnaire de sauvegarde qui ne sauve que les blocs de données modifiés
- console d'administration centralisée
- robustesse de la base de données
- compatibilité SQL-92
- présence d'ordonnanceur et gestion des triggers avancé

Des conflits ?

Si tu t'en tapes pourquoi tu poses la question :fou:

Il y a un moment ou discuter devient passablement penible, surtout avec le concours de qui a la plus grosses et un paquet de troll qui trainnent dans le coins.
Dans le cadre de le replication circulaire tu n as pas franchement de notion de maitre et d esclave (disons qu ils sont tous maitre/escalve les uns pour les autres).
Il n y a pas de notion de conflit avec My, tu auras une erreur de replication lorsqu'il ce retrouve dans une situation incoherente. La replication MySQL est tres simple, tu rejous tes requetes des maitres sur les esclaves une fois que tu le sais tu gere les problemes au niveau applicatif.

Donc à chaque fois tu réinventes la roue?
(encore que j'imagine que vous avez une classe de gestion de données.)