Pour clarifier, un simple `(f)sync` permet de prendre un snapshot. Il faut ensuite le symlinker pour le rendre persistant (`ln -s entry@@id snapshot`). C'est ce que l'outil hammer permet d'automatiser avec sa commande snapshot.
En fait les snapshot sont pris au moment d'un sync. Comme le kernel fait un sync toutes les 30 sec, on a des snapshots implicites toutes les 30 sec. Mais il est tout à fait possible de prendre un snapshot à l'aide de la commande hammer (et le symlinker).
Vu l'intéret que procure cette nouvelle, j'imagine qu'un tit lien vers une interview de Matt Dillon dans laquelle il parle de hammer* sera le bien venu :-P
Il y a quand même les xfsprogs. Quand xfs ne sait pas récupérer un montage, on n'est pas livré à soit-même; xfs_check et xfs_repair existent bel et bien. J'ai déja eu une petite corruption en essayant de monter un volume xfs sur un arm*, ces outils m'ont été d'un grand secours.
*: à ne pas essayer ! xfs ne fonctionne pas sur arm.
Ben non c'est un peu normal qu'il n'en fait pas mention. On écrit pas sur une liste de devel pour dire "eh oh venez vous joindre à moi pour faire le système ultime de clustering", il faut du concret ! Il explique que, selon lui, la directetion que prend freebsd en matière de smp n'est pas digne d'une conception "moderne". Il montre que son modèle fonctionne (I have both UP and SMP builds working in the current codebase. I believe it proves out the core concepts quite nicely and there is much more work coming down the pipeline.) et invite ses pairs à y jetter un oeil. Ensuite il évoque ses priorités à court/moyen terme qu'il a effectivement (on peut facilement le vérifier) résolues.
Ça c'est pour l'annonce officielle. Ensuite (ou p-ê avant de manière plus confidentielle) il a quand même très vite fait part de ses préoccupation de "clustering" dans ses mails sur la ML. Aussi sur la page de garde du projet (http://web.archive.org/web/20030801133333/www.dragonflybsd.o(...) ) on peut lire: It is our belief that the correct choice of features and algorithms can yield the potential for excellent scaleability, robustness, and debuggability in a number of broad system categories. Not just for SMP or NUMA, but for everything from a single-node UP system to a massively clustered system. It is the our belief that a fairly simple but wide-ranging set of goals will lay the groundwork for future growth. The existing BSD cores, including FreeBSD-5, are still primarily based on models which could at best be called 'strained' as they are applied to modern systems. The true innovation has given way to basically just laying on hacks to add features such as encrypted disks and security layering that in a better environment could be developed at far less cost and with far greater flexibility.
Donc venir dire qu'il a retourné sa veste ou qu'il a réorienté son projet vers le clustering parce qu'il n'avait pas aboutis dans son projet de smp-isation est totalement faut et fait preuve d'un parti prit évident (fanboy-isme) !
Il faut quand même reconnaître qu'il est déja plus smp-performant que FreeBSD 4 ;) L'objectif de Dillon était de faire un système orienté clustering tout en maintenant un niveau de performance équivalent à FreeBSD 4 (du moins aussi longtemps que le GKL demeure).
Ceci dit, l'argument de base de M. Dillon n'était pas tant d'avoir un smp performant, mais aussi d'avoir une implémentation "saine", c.-à-d. éviter la sur-complication des sous-systèmes du noyaux due à des mécanismes de verroux fins (fine-grained locks), en se basant sur d'autres sémantiques de verrouillages (cf. lwt ). Une fois qu'il a estimmé son travail sur les lwt suffisants, il a délaissé le travail d'élimination du GKL à d'autres contributeurs pour se re-concentrer sur l'aspect clustering en travaillant sur HAMMER.
Rétrospectivement, en comparant l'évolution des deux OS tout en tennant compte du nombre de contributeurs, je pense que Dragonfly a beaucoup progressé.
Certes, Matt n'a que deux bras et un seul cerveaux, et le GKL est toujours là mais du côté de FreeBSD on a eu des releases aux réputations douteuses (la branche 5 en a déçu plus d'un), on a eu un nouveaux scheduleurs tué dans l'oeuf, remplacé, puis réçussité pour de nouveau être remplacé (où était-ce dans l'autre sens ?); bref un peu de gachis quand même.
J'ai testé OpenBSD 4.(1 ou 2) sur un ibook g4. Cela marchait pas trop mal à ce que je me rappelle mais je n'ai pas tout essayé. Par contre, pas de 3D. Il me semble avoir vu passer récemment sur undeadly la trace d'amélioration du support macppc (histoire de clavier adb) donc c'est que ça reste utilisé.
Heuu ... si justement, GLX a été fait pour ça et il est possible d'utiliser de l'OpenGL "déporté".
Ah c'est sympa ça ! merci pour l'info, cela m'apprendra à raconter n'importe quoi.
Sinon je trouvais cela aberrant dans le cadre d'une utilisation "temps-réel" (jeux) où la latence du réseau doit quand même se faire sentir. Plus les problèmes de chargement de textures évoqués par Thomas D.
Concercant cairo, celui-ci utilise l'extension Xrender mais rien ne l'empêcherait d'utiliser opengl (evas et qt possèdent ce genre de backend).
Oui cela marche quand tu utilise un système qui reste figé pendant 10 ans (suivez mon regard). Mais le libre ça marche pas comme ça; et quand il faut attendre 6 mois pour que ton constructeur mette à jour ton drivers pour qu'il fonctionne sur la dernière version de Xorg, tu apprécie ton pilote libre.
Aucun moyen dans l'implementation actuelle, pas dans l'absolu:
-le client pourrait utiliser sa carte graphique pour accelerer un rendu sans l'afficher, recopier l'image en mémoire principale (raisonnable depuis PCI Express pour des rendus complexes) puis l'envoyer au serveur
-si le client envoyait des vecteurs ou des commandes OpenGL au serveur, le rendu serait fait par le serveur: j'ai bien compris que ce n'est pas le cas a l'heure actuelle, mais 'aucun moyen' n'est pas correcte.
Merci de me lire correctement, tout est toujours possible mais cela vaut -il réellement la peine ? ;)
Je te ferais remarquer aussi que la BP des cartes graphiques ne fait qu'augmenter. On ne fait pas qu'envoyer des "commandes vectorielles" à un CG, on y copie aussi des structures et des textures. Si tu parcours les liens donnés dans cet articles, tu te rendras compte que le problème de copier des données dans la cg de manière efficace est primordial. Ajoute y l'over-overheard d'un réseau et c'est à peine si tu peux encore jouer à pong.
Dans ton idée (rappel, opengl permet de faire du rendu temps-réel, ie affichier le plus d'images possibles par secondes), ce qu'il te faut c'est pas le protocole X mais un protocole de streaming vidéo + un mesa qui permet au client d'utilise une carte graphique.
Note: le fait d'utiliser un client déporté n'empêche pas le serveur X de faire du composing accéléré (cf. compiz).
Certes mais si la composition decale l'image d'une quantité non-entiere, le mapping des pixels n'est plus valable non?
gni !? Comment fais-tu pour décaller une image d'un demi-pixel ? (hint: dépose un brevet, ça a l'air intéressant... (o: )
mais ça veut dire que cairo ne peut pas utiliser l'acceleration materielle alors???
Il peut faire comme tout le monde et utiliser OpenGL (comme QT le peut, je pense).
Bof, le serveur pourrait cacher le rendu je ne vois pas ou est le probleme.
Oui mais pour des raisons qui me sont inconnues, il ne le fait pas; Compiz le fait. Par contre, X peut cacher des pixmaps à la demande de l'application.
[...] il faudrait que le programme client puisse faire le rendu en utilisant l'acceleration materielle (et idealement directement dans la mémoire de la carte graphique si l'affichage est local)
Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !
Maintenant, lorsqu'une application (ou un toolkit graphique) veut utiliser l'accélération matérielle, elle utilise l'api OpenGL en court-circuitant le serveur X. Donc il est impossible d'utiliser openGL en affichage déporté (sauf bidouille, mais cela n'aurait aucun intéret de tt façon).
et ensuite passe une reference vers l'image au serveur X qui idéalement utiliserait aussi l'acceleration materielle pour composer ces image dans le rendu final
C'est à peu de choses près ce qu'il se passe actuellement. Lorsque le serveur X est en mode RenderAccel (EXA, XAA,...), il utilse des optimisations implémentées par le pilotes de la CG. On peut aussi utiliser un composeur (?) style compiz qui utilise le contexte OpenGL de la cg.
1) tous les clients et le serveur partageant la carte graphique: ça ne pose pas un probleme? Au départ, les cartes graphique avaient 'un seul maitre' pour l'acceleration 3D il me semble.
C'est toujours le cas et ce n'est pas près de changer. C'est la même chose que faire du multi-tâche alors qu'on a qu'un seul CPU: il faut le partager entre les applications en sauvegardant/restaurant leur contexte respectif.
j'ai l'impression que si le serveur X compose des 'images' fourni par le client, au niveau rendu des fontes ça risque d'être l'horreur: pas de possibilité de faire de l'anti-aliasing propre tant que tu ne connais pas ton positionement par rapport aux pixels (tant que le DPI des écrans reste assez faible :-( ).
Étant donné que l'on n'a pas encore inventé les pixels quantiques, l'image envoyée par le client sera toujours alignée sur un pixel (logique, non ?). L'AA est fait par le client, s'il veut que sont image puisse être composée, il n'a qu'à y avoir des pixels (semi-)transparents...
Je ne comprends pas bien pourquoi on parle d'image fourni par le client: si le client fournissait des vecteur et du texte a la place d'image
Le protocol X permet cela mais ces instructions restent basiques.
(ce que fait Cairo il me semble non?),
Non, justement c'est à cairo que l'on demande de dessiner des formes vectorielles dans un pixmap, que l'on envoit ensuite au serveur X. Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire. Ce serait aussi la voie vers une explosion de la complexité du protocol X (il faudra une nouvelle version du protocole à chaque fois que tu voudrais utiliser un nouveau type de flou ?!).
le rendu et la composition étant fait par le serveur, ces problemes la disparaitraient non?
À quels problèmes fait tu références ?
L'avantage de cette architecture c'est que le rendu et la composition sont effectués par ceux qui sont le mieux disposés à le faire. Et avec un compositeur style compiz, on arrive même à masquer la latence engendrée lorque le serveur X demande à une fenêtre de se redessiner.
Préinstallation dy système de son choix : parmi quelle liste ?
Et la couleur de ta voiture ? Et le parfum de ta lessive ? C'est justement un critère de marketing qui permet de différencier les vendeurs. Dans la pratique, les quelques distributions mainstream suffiront pour madame michu.
Un choix entre nu ou préinstallé : le bordel en magasin…
C'est exactement les arguments que les revendeurs utilisent pour justifier le status quo actuel.
son coût marginal est nul
La préinstallation est un service donc le coût marginal tend à diminuer, quelque soit l'OS proposé. Le compter comme nul entre en contradiction avec ton désir d'éliminer la confusion entre le prix d'une license et la préinstallation. Bref, le coût de proposer un os par défaut est finalement répercuté sur l'acheteur (sauf magouille/dédommagement du fournisseur de l'os qui paye le constructeur pour que son produit soit préinstallé, on en revient à la situation actuelle).
- On ne peut pas négliger le coût d'une préinstallation. Il y aura toujours de la manipulation supplémentaire, de la QA, par rapport à un produit nu. Ce coût doit forcément être pris en charge par quelqu'un: le client, le vendeur de l'os ou le constructeur/assembleur. Ce que tu propose permet à ms, une fois de plus, de masquer ce coût de l'étiquette cliente puisqu'il y a tout à parier qu'ils vont subsidier les constructeurs pour effectuer la préinstallation de leur système*.
- Priviligier la préinstallation d'un os particulier (qui plus est, un logiciel privateur) au nom de la simplicité ne me semble pas être une avancée.
- Je maintiens qu'il faudrait que le client puisse choisir l'os préinstallé ou pas d'os. Le constructeur doit pouvoir lui offrir(ou vendre) ce service. C'est un argument qui peut le départager de l'offre concurrente. Dans tous les cas, le coût de cette préinstallation et, éventuellement, le coût de la license doit être bien spécifié.
*: pour être réllement transparent dans ton système, il faudrait 3 prix: nu, préinstallé, préinstallé+le code ce qui est ridicule et complique inutilement les choses.
Bof si le code est remis à l'achat d'un ordi, cela ne va pas changer grand chose à la choucroutte...
J'aurais tendance à penser que c'est à microsoft de faire des promotions "oem" __au client__ pour vendre sa ***** à l'achat d'un nouvel ordi (et payer le distributeur pour qu'il réalise l'installation).
[^] # Re: rss
Posté par benja . En réponse au journal La Chine aime Windows. Évalué à 5.
[^] # Re: Ah, les beaux trolls !
Posté par benja . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 3.
[^] # Re: Ah, les beaux trolls !
Posté par benja . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 3.
# Blahblah
Posté par benja . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 8.
http://bsdtalk.blogspot.com/2008/07/bsdtalk154-matthew-dillo(...)
*:http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&(...)
[^] # Re: Hammer et zfs
Posté par benja . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 2.
*: à ne pas essayer ! xfs ne fonctionne pas sur arm.
[^] # Re: Revisionnisme?
Posté par benja . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 7.
Ça c'est pour l'annonce officielle. Ensuite (ou p-ê avant de manière plus confidentielle) il a quand même très vite fait part de ses préoccupation de "clustering" dans ses mails sur la ML. Aussi sur la page de garde du projet (http://web.archive.org/web/20030801133333/www.dragonflybsd.o(...) ) on peut lire:
It is our belief that the correct choice of features and algorithms can yield the potential for excellent scaleability, robustness, and debuggability in a number of broad system categories. Not just for SMP or NUMA, but for everything from a single-node UP system to a massively clustered system. It is the our belief that a fairly simple but wide-ranging set of goals will lay the groundwork for future growth. The existing BSD cores, including FreeBSD-5, are still primarily based on models which could at best be called 'strained' as they are applied to modern systems. The true innovation has given way to basically just laying on hacks to add features such as encrypted disks and security layering that in a better environment could be developed at far less cost and with far greater flexibility.
Donc venir dire qu'il a retourné sa veste ou qu'il a réorienté son projet vers le clustering parce qu'il n'avait pas aboutis dans son projet de smp-isation est totalement faut et fait preuve d'un parti prit évident (fanboy-isme) !
[^] # Re: Revisionnisme?
Posté par benja . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 7.
Ceci dit, l'argument de base de M. Dillon n'était pas tant d'avoir un smp performant, mais aussi d'avoir une implémentation "saine", c.-à-d. éviter la sur-complication des sous-systèmes du noyaux due à des mécanismes de verroux fins (fine-grained locks), en se basant sur d'autres sémantiques de verrouillages (cf. lwt ). Une fois qu'il a estimmé son travail sur les lwt suffisants, il a délaissé le travail d'élimination du GKL à d'autres contributeurs pour se re-concentrer sur l'aspect clustering en travaillant sur HAMMER.
Rétrospectivement, en comparant l'évolution des deux OS tout en tennant compte du nombre de contributeurs, je pense que Dragonfly a beaucoup progressé.
Certes, Matt n'a que deux bras et un seul cerveaux, et le GKL est toujours là mais du côté de FreeBSD on a eu des releases aux réputations douteuses (la branche 5 en a déçu plus d'un), on a eu un nouveaux scheduleurs tué dans l'oeuf, remplacé, puis réçussité pour de nouveau être remplacé (où était-ce dans l'autre sens ?); bref un peu de gachis quand même.
[^] # Re: Le son sous linux
Posté par benja . En réponse au journal env TROLL=yes FRIDAY=yes echo Linux is defective by design. Évalué à 3.
[^] # Re: Le son sous linux
Posté par benja . En réponse au journal env TROLL=yes FRIDAY=yes echo Linux is defective by design. Évalué à 7.
-linux est critiqués pour être monolithique, avec les pilotes en espace noyau
vs.
-l'avantage d'ossv4 c'est d'être uniquement dans le noyau.
On pourra remarquer que tout le post du developpeur d'oss pue la mauvaise fois, comme le souligne justement ce commentaire: http://4front-tech.com/hannublog/?p=5,#comment-422 .
[^] # Re: Le son sous linux
Posté par benja . En réponse au journal env TROLL=yes FRIDAY=yes echo Linux is defective by design. Évalué à 6.
Disons que la sortie pulseaudio d'alsa aide pour beaucoup.
[^] # Re: Partage de fichier "portable"
Posté par benja . En réponse à la dépêche Publication de Samba 3.2. Évalué à 3.
[^] # Re: Et OpenBSD ?
Posté par benja . En réponse au journal Mon expérience Linux sur PowerPC. Évalué à 1.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par benja . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 2.
Ah c'est sympa ça ! merci pour l'info, cela m'apprendra à raconter n'importe quoi.
Sinon je trouvais cela aberrant dans le cadre d'une utilisation "temps-réel" (jeux) où la latence du réseau doit quand même se faire sentir. Plus les problèmes de chargement de textures évoqués par Thomas D.
Concercant cairo, celui-ci utilise l'extension Xrender mais rien ne l'empêcherait d'utiliser opengl (evas et qt possèdent ce genre de backend).
[^] # Re: PPC _not_ pwned
Posté par benja . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 5.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par benja . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 1.
-le client pourrait utiliser sa carte graphique pour accelerer un rendu sans l'afficher, recopier l'image en mémoire principale (raisonnable depuis PCI Express pour des rendus complexes) puis l'envoyer au serveur
-si le client envoyait des vecteurs ou des commandes OpenGL au serveur, le rendu serait fait par le serveur: j'ai bien compris que ce n'est pas le cas a l'heure actuelle, mais 'aucun moyen' n'est pas correcte.
Merci de me lire correctement, tout est toujours possible mais cela vaut -il réellement la peine ? ;)
Je te ferais remarquer aussi que la BP des cartes graphiques ne fait qu'augmenter. On ne fait pas qu'envoyer des "commandes vectorielles" à un CG, on y copie aussi des structures et des textures. Si tu parcours les liens donnés dans cet articles, tu te rendras compte que le problème de copier des données dans la cg de manière efficace est primordial. Ajoute y l'over-overheard d'un réseau et c'est à peine si tu peux encore jouer à pong.
Dans ton idée (rappel, opengl permet de faire du rendu temps-réel, ie affichier le plus d'images possibles par secondes), ce qu'il te faut c'est pas le protocole X mais un protocole de streaming vidéo + un mesa qui permet au client d'utilise une carte graphique.
Note: le fait d'utiliser un client déporté n'empêche pas le serveur X de faire du composing accéléré (cf. compiz).
Certes mais si la composition decale l'image d'une quantité non-entiere, le mapping des pixels n'est plus valable non?
gni !? Comment fais-tu pour décaller une image d'un demi-pixel ? (hint: dépose un brevet, ça a l'air intéressant... (o: )
mais ça veut dire que cairo ne peut pas utiliser l'acceleration materielle alors???
Il peut faire comme tout le monde et utiliser OpenGL (comme QT le peut, je pense).
Bof, le serveur pourrait cacher le rendu je ne vois pas ou est le probleme.
Oui mais pour des raisons qui me sont inconnues, il ne le fait pas; Compiz le fait. Par contre, X peut cacher des pixmaps à la demande de l'application.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par benja . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 2.
Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !
Maintenant, lorsqu'une application (ou un toolkit graphique) veut utiliser l'accélération matérielle, elle utilise l'api OpenGL en court-circuitant le serveur X. Donc il est impossible d'utiliser openGL en affichage déporté (sauf bidouille, mais cela n'aurait aucun intéret de tt façon).
et ensuite passe une reference vers l'image au serveur X qui idéalement utiliserait aussi l'acceleration materielle pour composer ces image dans le rendu final
C'est à peu de choses près ce qu'il se passe actuellement. Lorsque le serveur X est en mode RenderAccel (EXA, XAA,...), il utilse des optimisations implémentées par le pilotes de la CG. On peut aussi utiliser un composeur (?) style compiz qui utilise le contexte OpenGL de la cg.
1) tous les clients et le serveur partageant la carte graphique: ça ne pose pas un probleme? Au départ, les cartes graphique avaient 'un seul maitre' pour l'acceleration 3D il me semble.
C'est toujours le cas et ce n'est pas près de changer. C'est la même chose que faire du multi-tâche alors qu'on a qu'un seul CPU: il faut le partager entre les applications en sauvegardant/restaurant leur contexte respectif.
j'ai l'impression que si le serveur X compose des 'images' fourni par le client, au niveau rendu des fontes ça risque d'être l'horreur: pas de possibilité de faire de l'anti-aliasing propre tant que tu ne connais pas ton positionement par rapport aux pixels (tant que le DPI des écrans reste assez faible :-( ).
Étant donné que l'on n'a pas encore inventé les pixels quantiques, l'image envoyée par le client sera toujours alignée sur un pixel (logique, non ?). L'AA est fait par le client, s'il veut que sont image puisse être composée, il n'a qu'à y avoir des pixels (semi-)transparents...
Je ne comprends pas bien pourquoi on parle d'image fourni par le client: si le client fournissait des vecteur et du texte a la place d'image
Le protocol X permet cela mais ces instructions restent basiques.
(ce que fait Cairo il me semble non?),
Non, justement c'est à cairo que l'on demande de dessiner des formes vectorielles dans un pixmap, que l'on envoit ensuite au serveur X. Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire. Ce serait aussi la voie vers une explosion de la complexité du protocol X (il faudra une nouvelle version du protocole à chaque fois que tu voudrais utiliser un nouveau type de flou ?!).
le rendu et la composition étant fait par le serveur, ces problemes la disparaitraient non?
À quels problèmes fait tu références ?
L'avantage de cette architecture c'est que le rendu et la composition sont effectués par ceux qui sont le mieux disposés à le faire. Et avec un compositeur style compiz, on arrive même à masquer la latence engendrée lorque le serveur X demande à une fenêtre de se redessiner.
[^] # Re: Pourquoi pas linux pour tous?
Posté par benja . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 4.
Et la couleur de ta voiture ? Et le parfum de ta lessive ? C'est justement un critère de marketing qui permet de différencier les vendeurs. Dans la pratique, les quelques distributions mainstream suffiront pour madame michu.
Un choix entre nu ou préinstallé : le bordel en magasin…
C'est exactement les arguments que les revendeurs utilisent pour justifier le status quo actuel.
son coût marginal est nul
La préinstallation est un service donc le coût marginal tend à diminuer, quelque soit l'OS proposé. Le compter comme nul entre en contradiction avec ton désir d'éliminer la confusion entre le prix d'une license et la préinstallation. Bref, le coût de proposer un os par défaut est finalement répercuté sur l'acheteur (sauf magouille/dédommagement du fournisseur de l'os qui paye le constructeur pour que son produit soit préinstallé, on en revient à la situation actuelle).
[^] # Re: Pourquoi pas linux pour tous?
Posté par benja . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 2.
- Priviligier la préinstallation d'un os particulier (qui plus est, un logiciel privateur) au nom de la simplicité ne me semble pas être une avancée.
- Je maintiens qu'il faudrait que le client puisse choisir l'os préinstallé ou pas d'os. Le constructeur doit pouvoir lui offrir(ou vendre) ce service. C'est un argument qui peut le départager de l'offre concurrente. Dans tous les cas, le coût de cette préinstallation et, éventuellement, le coût de la license doit être bien spécifié.
*: pour être réllement transparent dans ton système, il faudrait 3 prix: nu, préinstallé, préinstallé+le code ce qui est ridicule et complique inutilement les choses.
[^] # Re: RE : La libération de L. Bettancourt , du gros pipo ?
Posté par benja . En réponse au journal La libération de L. Bettancourt , du gros pipo ?. Évalué à 2.
[^] # Re: Pourquoi pas linux pour tous?
Posté par benja . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 1.
J'aurais tendance à penser que c'est à microsoft de faire des promotions "oem" __au client__ pour vendre sa ***** à l'achat d'un nouvel ordi (et payer le distributeur pour qu'il réalise l'installation).
[^] # Re: Luc Chatel
Posté par benja . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 2.
À bas la comm' politique sur DLFP !!!
[^] # Re: Enfin une sortie des casses tetes de comptabilite
Posté par benja . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 0.
(je suppose que tu nous fais part des conditions de vente aux particuliers).
[^] # Re: Sans c'est plus cher
Posté par benja . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 3.
[^] # Re: Pourquoi pas linux pour tous?
Posté par benja . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 1.
[^] # Re: Cool
Posté par benja . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 1.