Le Wed, 17 Nov 2010 16:05:12 +0100,
Hugues écrivait :
JKB a suggéré :Le Wed, 17 Nov 2010 15:46:15 +0100,
Hugues écrivait :
Des plantages avec MySQL ?
Va falloir que je creuse la question !
En moyenne, j'en ai un tous les deux mois (hors réplication, parce
que là, c'est un poème). Ça arrive surtout avec les bases innodb
(c'est plus rigolo quand ça arrive :-) ) lorsqu'elles prennent de
l'ampleur.
Quel est le souci d'InnoDB ?
(Il me semble que c'est ce que j'utilise)
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_.
Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles. Et lorsque
le client veut MySQL, je lui fais signer une décharge dans laquelle
il assure faire lui-même ses sauvegardes, parce que mêmes les
répliques sont foutues de planter (le plus marrant, sur une requête
qui est passée sans problème sur la base maître et qui est
parfaitement conforme).
Le Wed, 17 Nov 2010 16:05:12 +0100,
Hugues <hugues@hiegel.fr> écrivait :
JKB <jkb@koenigsberg.invalid> a suggéré :
Le Wed, 17 Nov 2010 15:46:15 +0100,
Hugues <hugues@hiegel.fr> écrivait :
Des plantages avec MySQL ?
Va falloir que je creuse la question !
En moyenne, j'en ai un tous les deux mois (hors réplication, parce
que là, c'est un poème). Ça arrive surtout avec les bases innodb
(c'est plus rigolo quand ça arrive :-) ) lorsqu'elles prennent de
l'ampleur.
Quel est le souci d'InnoDB ?
(Il me semble que c'est ce que j'utilise)
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_.
Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles. Et lorsque
le client veut MySQL, je lui fais signer une décharge dans laquelle
il assure faire lui-même ses sauvegardes, parce que mêmes les
répliques sont foutues de planter (le plus marrant, sur une requête
qui est passée sans problème sur la base maître et qui est
parfaitement conforme).
Le Wed, 17 Nov 2010 16:05:12 +0100,
Hugues écrivait :
JKB a suggéré :Le Wed, 17 Nov 2010 15:46:15 +0100,
Hugues écrivait :
Des plantages avec MySQL ?
Va falloir que je creuse la question !
En moyenne, j'en ai un tous les deux mois (hors réplication, parce
que là, c'est un poème). Ça arrive surtout avec les bases innodb
(c'est plus rigolo quand ça arrive :-) ) lorsqu'elles prennent de
l'ampleur.
Quel est le souci d'InnoDB ?
(Il me semble que c'est ce que j'utilise)
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_.
Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles. Et lorsque
le client veut MySQL, je lui fais signer une décharge dans laquelle
il assure faire lui-même ses sauvegardes, parce que mêmes les
répliques sont foutues de planter (le plus marrant, sur une requête
qui est passée sans problème sur la base maître et qui est
parfaitement conforme).
Le Wed, 17 Nov 2010 16:05:12 +0100,
Hugues écrivait :
> JKB a suggéré :
>> Le Wed, 17 Nov 2010 15:46:15 +0100,
>> Hugues écrivait :
>>> JKB a suggéré :
>>>> Le Wed, 17 Nov 2010 13:06:01 +0100,
>>>> Hugues écrivait :
>>>>> Nicolas George <nicolas$ a suggéré :
>>>>>> [...]
>>> Tu pourrais répondre proprement stp ? J'ai cru que tu t'adressais à moi...
>> C'est difficile, NG est dans ma boitakhon.
> Mauvaise excuse : tu pouvais faire l'effort d'aller à la pêche à
> l'article parent. :)
>>> Des plantages avec MySQL ?
>>> Va falloir que je creuse la question !
>> En moyenne, j'en ai un tous les deux mois (hors répli cation, parce
>> que là, c'est un poème). Ça arrive surtout avec l es bases innodb
>> (c'est plus rigolo quand ça arrive :-) ) lorsqu'elles prennent de
>> l'ampleur.
> Quel est le souci d'InnoDB ?
> (Il me semble que c'est ce que j'utilise)
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque a rrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_ .
Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles. E t lorsque
le client veut MySQL, je lui fais signer une décharge d ans laquelle
il assure faire lui-même ses sauvegardes, parce que m êmes les
répliques sont foutues de planter (le plus marrant, sur une requête
qui est passée sans problème sur la base maître et qui est
parfaitement conforme).
JKB
Le Wed, 17 Nov 2010 16:05:12 +0100,
Hugues <hug...@hiegel.fr> écrivait :
> JKB <j...@koenigsberg.invalid> a suggéré :
>> Le Wed, 17 Nov 2010 15:46:15 +0100,
>> Hugues <hug...@hiegel.fr> écrivait :
>>> JKB <j...@koenigsberg.invalid> a suggéré :
>>>> Le Wed, 17 Nov 2010 13:06:01 +0100,
>>>> Hugues <hug...@hiegel.fr> écrivait :
>>>>> Nicolas George <nicolas$geo...@salle-s.org> a suggéré :
>>>>>> [...]
>>> Tu pourrais répondre proprement stp ? J'ai cru que tu t'adressais à moi...
>> C'est difficile, NG est dans ma boitakhon.
> Mauvaise excuse : tu pouvais faire l'effort d'aller à la pêche à
> l'article parent. :)
>>> Des plantages avec MySQL ?
>>> Va falloir que je creuse la question !
>> En moyenne, j'en ai un tous les deux mois (hors répli cation, parce
>> que là, c'est un poème). Ça arrive surtout avec l es bases innodb
>> (c'est plus rigolo quand ça arrive :-) ) lorsqu'elles prennent de
>> l'ampleur.
> Quel est le souci d'InnoDB ?
> (Il me semble que c'est ce que j'utilise)
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque a rrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_ .
Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles. E t lorsque
le client veut MySQL, je lui fais signer une décharge d ans laquelle
il assure faire lui-même ses sauvegardes, parce que m êmes les
répliques sont foutues de planter (le plus marrant, sur une requête
qui est passée sans problème sur la base maître et qui est
parfaitement conforme).
JKB
Le Wed, 17 Nov 2010 16:05:12 +0100,
Hugues écrivait :
> JKB a suggéré :
>> Le Wed, 17 Nov 2010 15:46:15 +0100,
>> Hugues écrivait :
>>> JKB a suggéré :
>>>> Le Wed, 17 Nov 2010 13:06:01 +0100,
>>>> Hugues écrivait :
>>>>> Nicolas George <nicolas$ a suggéré :
>>>>>> [...]
>>> Tu pourrais répondre proprement stp ? J'ai cru que tu t'adressais à moi...
>> C'est difficile, NG est dans ma boitakhon.
> Mauvaise excuse : tu pouvais faire l'effort d'aller à la pêche à
> l'article parent. :)
>>> Des plantages avec MySQL ?
>>> Va falloir que je creuse la question !
>> En moyenne, j'en ai un tous les deux mois (hors répli cation, parce
>> que là, c'est un poème). Ça arrive surtout avec l es bases innodb
>> (c'est plus rigolo quand ça arrive :-) ) lorsqu'elles prennent de
>> l'ampleur.
> Quel est le souci d'InnoDB ?
> (Il me semble que c'est ce que j'utilise)
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque a rrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_ .
Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles. E t lorsque
le client veut MySQL, je lui fais signer une décharge d ans laquelle
il assure faire lui-même ses sauvegardes, parce que m êmes les
répliques sont foutues de planter (le plus marrant, sur une requête
qui est passée sans problème sur la base maître et qui est
parfaitement conforme).
JKB
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_.
Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles. Et lorsque
le client veut MySQL, je lui fais signer une décharge dans laquelle
il assure faire lui-même ses sauvegardes, parce que mêmes les
répliques sont foutues de planter (le plus marrant, sur une requête
qui est passée sans problème sur la base maître et qui est
parfaitement conforme).
JKB
Tiens du jour au lendemain MYSQL c'est de la merde, et avant c'était
recommander, Monsieur neuneu et madame Michu vont surement
comprendre !
Deux question viennent à l'esprit :
Cas fait oracle contre le Libre ?
Pourquoi Oracle ne croit pas dans le Libre ?
( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_.
Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles. Et lorsque
le client veut MySQL, je lui fais signer une décharge dans laquelle
il assure faire lui-même ses sauvegardes, parce que mêmes les
répliques sont foutues de planter (le plus marrant, sur une requête
qui est passée sans problème sur la base maître et qui est
parfaitement conforme).
JKB
Tiens du jour au lendemain MYSQL c'est de la merde, et avant c'était
recommander, Monsieur neuneu et madame Michu vont surement
comprendre !
Deux question viennent à l'esprit :
Cas fait oracle contre le Libre ?
Pourquoi Oracle ne croit pas dans le Libre ?
( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_.
Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles. Et lorsque
le client veut MySQL, je lui fais signer une décharge dans laquelle
il assure faire lui-même ses sauvegardes, parce que mêmes les
répliques sont foutues de planter (le plus marrant, sur une requête
qui est passée sans problème sur la base maître et qui est
parfaitement conforme).
JKB
Tiens du jour au lendemain MYSQL c'est de la merde, et avant c'était
recommander, Monsieur neuneu et madame Michu vont surement
comprendre !
Deux question viennent à l'esprit :
Cas fait oracle contre le Libre ?
Pourquoi Oracle ne croit pas dans le Libre ?
( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
On 11/18/2010 10:10 AM, ptilou wrote:( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Non. Je pense que Sun a sombrer parce que le service marketing
a arreté de croire aux produits que fabriquait Sun, et a voulu
viser un marché sur lequel ils n'avaient finalement pas (ou plus)
les compétences.
On 11/18/2010 10:10 AM, ptilou wrote:
( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Non. Je pense que Sun a sombrer parce que le service marketing
a arreté de croire aux produits que fabriquait Sun, et a voulu
viser un marché sur lequel ils n'avaient finalement pas (ou plus)
les compétences.
On 11/18/2010 10:10 AM, ptilou wrote:( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Non. Je pense que Sun a sombrer parce que le service marketing
a arreté de croire aux produits que fabriquait Sun, et a voulu
viser un marché sur lequel ils n'avaient finalement pas (ou plus)
les compétences.
Le Thu, 18 Nov 2010 10:49:59 +0100,
Tonton Th écrivait :On 11/18/2010 10:10 AM, ptilou wrote:( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Non. Je pense que Sun a sombrer parce que le service marketing
a arreté de croire aux produits que fabriquait Sun, et a voulu
viser un marché sur lequel ils n'avaient finalement pas (ou plus)
les compétences.
J'ai été très surpris de voir au tournant du siècle des boîtes
voulant acheter du matériel Sun pour remplacer des SS ou les
premières U. C'était _impossible_. Le matériel était bon mais vendu
largement trop cher. Et ce n'était pas une question de prix de
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable. Ils se sont tirés eux-même une balle dans le pied et se
sont cantonnés au marché du serveur sur lequel ils concurrençaient
IBM, HP, Bull et quelques autres. Le coût de grâce a été donné
lorsque des gens comme Dell ont cassé les prix.
Et Oracle suit la même ligne : le prix de l'entrée de gamme Sparc a
été multiplié par 3,5 le jour du rachat !
Le Thu, 18 Nov 2010 10:49:59 +0100,
Tonton Th<tth@la.bas.invalid> écrivait :
On 11/18/2010 10:10 AM, ptilou wrote:
( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Non. Je pense que Sun a sombrer parce que le service marketing
a arreté de croire aux produits que fabriquait Sun, et a voulu
viser un marché sur lequel ils n'avaient finalement pas (ou plus)
les compétences.
J'ai été très surpris de voir au tournant du siècle des boîtes
voulant acheter du matériel Sun pour remplacer des SS ou les
premières U. C'était _impossible_. Le matériel était bon mais vendu
largement trop cher. Et ce n'était pas une question de prix de
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable. Ils se sont tirés eux-même une balle dans le pied et se
sont cantonnés au marché du serveur sur lequel ils concurrençaient
IBM, HP, Bull et quelques autres. Le coût de grâce a été donné
lorsque des gens comme Dell ont cassé les prix.
Et Oracle suit la même ligne : le prix de l'entrée de gamme Sparc a
été multiplié par 3,5 le jour du rachat !
Le Thu, 18 Nov 2010 10:49:59 +0100,
Tonton Th écrivait :On 11/18/2010 10:10 AM, ptilou wrote:( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Non. Je pense que Sun a sombrer parce que le service marketing
a arreté de croire aux produits que fabriquait Sun, et a voulu
viser un marché sur lequel ils n'avaient finalement pas (ou plus)
les compétences.
J'ai été très surpris de voir au tournant du siècle des boîtes
voulant acheter du matériel Sun pour remplacer des SS ou les
premières U. C'était _impossible_. Le matériel était bon mais vendu
largement trop cher. Et ce n'était pas une question de prix de
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable. Ils se sont tirés eux-même une balle dans le pied et se
sont cantonnés au marché du serveur sur lequel ils concurrençaient
IBM, HP, Bull et quelques autres. Le coût de grâce a été donné
lorsque des gens comme Dell ont cassé les prix.
Et Oracle suit la même ligne : le prix de l'entrée de gamme Sparc a
été multiplié par 3,5 le jour du rachat !
Le 18/11/2010 11:02, JKB a écrit :Le Thu, 18 Nov 2010 10:49:59 +0100,
Tonton Th écrivait :On 11/18/2010 10:10 AM, ptilou wrote:( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Non. Je pense que Sun a sombrer parce que le service marketing
a arreté de croire aux produits que fabriquait Sun, et a voulu
viser un marché sur lequel ils n'avaient finalement pas (ou plus)
les compétences.
J'ai été très surpris de voir au tournant du siècle des boîtes
voulant acheter du matériel Sun pour remplacer des SS ou les
premières U. C'était _impossible_. Le matériel était bon mais vendu
largement trop cher. Et ce n'était pas une question de prix de
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable. Ils se sont tirés eux-même une balle dans le pied et se
sont cantonnés au marché du serveur sur lequel ils concurrençaient
IBM, HP, Bull et quelques autres. Le coût de grâce a été donné
lorsque des gens comme Dell ont cassé les prix.
Et Oracle suit la même ligne : le prix de l'entrée de gamme Sparc a
été multiplié par 3,5 le jour du rachat !
Les quelques supercalculateurs à base de SPARC vont donc disparaitre du
TOP500 ?
Le 18/11/2010 11:02, JKB a écrit :
Le Thu, 18 Nov 2010 10:49:59 +0100,
Tonton Th<tth@la.bas.invalid> écrivait :
On 11/18/2010 10:10 AM, ptilou wrote:
( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Non. Je pense que Sun a sombrer parce que le service marketing
a arreté de croire aux produits que fabriquait Sun, et a voulu
viser un marché sur lequel ils n'avaient finalement pas (ou plus)
les compétences.
J'ai été très surpris de voir au tournant du siècle des boîtes
voulant acheter du matériel Sun pour remplacer des SS ou les
premières U. C'était _impossible_. Le matériel était bon mais vendu
largement trop cher. Et ce n'était pas une question de prix de
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable. Ils se sont tirés eux-même une balle dans le pied et se
sont cantonnés au marché du serveur sur lequel ils concurrençaient
IBM, HP, Bull et quelques autres. Le coût de grâce a été donné
lorsque des gens comme Dell ont cassé les prix.
Et Oracle suit la même ligne : le prix de l'entrée de gamme Sparc a
été multiplié par 3,5 le jour du rachat !
Les quelques supercalculateurs à base de SPARC vont donc disparaitre du
TOP500 ?
Le 18/11/2010 11:02, JKB a écrit :Le Thu, 18 Nov 2010 10:49:59 +0100,
Tonton Th écrivait :On 11/18/2010 10:10 AM, ptilou wrote:( C'est peu-être parce que Sun a crue dans le Libre qu'il c'est fait
bouffer par Oracle )
Non. Je pense que Sun a sombrer parce que le service marketing
a arreté de croire aux produits que fabriquait Sun, et a voulu
viser un marché sur lequel ils n'avaient finalement pas (ou plus)
les compétences.
J'ai été très surpris de voir au tournant du siècle des boîtes
voulant acheter du matériel Sun pour remplacer des SS ou les
premières U. C'était _impossible_. Le matériel était bon mais vendu
largement trop cher. Et ce n'était pas une question de prix de
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable. Ils se sont tirés eux-même une balle dans le pied et se
sont cantonnés au marché du serveur sur lequel ils concurrençaient
IBM, HP, Bull et quelques autres. Le coût de grâce a été donné
lorsque des gens comme Dell ont cassé les prix.
Et Oracle suit la même ligne : le prix de l'entrée de gamme Sparc a
été multiplié par 3,5 le jour du rachat !
Les quelques supercalculateurs à base de SPARC vont donc disparaitre du
TOP500 ?
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable.
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable.
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable.
On 11/18/2010 11:02 AM, JKB wrote:revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable.
C'est une peu à ça que je pensais, oui. Quatre sparc64 dans une
petite machine simple, capable de faire aussi bien un serveur
correct qu'une station puissante, le tout à un prix abordable
(dans les années 2003-2005) aurait permis à Sun de déboucher
sur un nouveau marché. Surtout si la machine était fournie avec
les documents permettant de bien porter des OS libres.
Quand au boitier SS20, juste une petite réserve (j'ai pas la
mienne sous les yeux ?), mais le cdrom sur le coté, c'est pas
très pratique sur un petit bureau.
On 11/18/2010 11:02 AM, JKB wrote:
revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable.
C'est une peu à ça que je pensais, oui. Quatre sparc64 dans une
petite machine simple, capable de faire aussi bien un serveur
correct qu'une station puissante, le tout à un prix abordable
(dans les années 2003-2005) aurait permis à Sun de déboucher
sur un nouveau marché. Surtout si la machine était fournie avec
les documents permettant de bien porter des OS libres.
Quand au boitier SS20, juste une petite réserve (j'ai pas la
mienne sous les yeux ?), mais le cdrom sur le coté, c'est pas
très pratique sur un petit bureau.
On 11/18/2010 11:02 AM, JKB wrote:revient, mais de politique tarifaire démentielle. Sun aurait très
bien pu fabriquer une machine intéressante dans un boîtier de SS20
avec des processeurs puissants (qu'il s'agisse de sparc ou de x86 ou
autre), avec la qualité d'une SS20, mais il fallait que le prix soit
raisonnable.
C'est une peu à ça que je pensais, oui. Quatre sparc64 dans une
petite machine simple, capable de faire aussi bien un serveur
correct qu'une station puissante, le tout à un prix abordable
(dans les années 2003-2005) aurait permis à Sun de déboucher
sur un nouveau marché. Surtout si la machine était fournie avec
les documents permettant de bien porter des OS libres.
Quand au boitier SS20, juste une petite réserve (j'ai pas la
mienne sous les yeux ?), mais le cdrom sur le coté, c'est pas
très pratique sur un petit bureau.
Moi, j'applaudis des deux mains. C'est la meilleure chose qui puisse
arriver puisqu'au final, on remplacera MySQL par MariaDB (il faut
lire la genèse de MariaDB et pourquoi le développeur principal de
MySQL a décidé de 'forker' son projet, entre autres en raison des
bugs de l'engin...) et qu'on verra peut-être enfin quelque chose de
meilleur que Java arriver.
Moi, j'applaudis des deux mains. C'est la meilleure chose qui puisse
arriver puisqu'au final, on remplacera MySQL par MariaDB (il faut
lire la genèse de MariaDB et pourquoi le développeur principal de
MySQL a décidé de 'forker' son projet, entre autres en raison des
bugs de l'engin...) et qu'on verra peut-être enfin quelque chose de
meilleur que Java arriver.
Moi, j'applaudis des deux mains. C'est la meilleure chose qui puisse
arriver puisqu'au final, on remplacera MySQL par MariaDB (il faut
lire la genèse de MariaDB et pourquoi le développeur principal de
MySQL a décidé de 'forker' son projet, entre autres en raison des
bugs de l'engin...) et qu'on verra peut-être enfin quelque chose de
meilleur que Java arriver.
