Bien sûr, certains utilisateurs sont trompés par des offres qui semblent légitimes. Vous trouverez ci-dessous quelques signes qui indiquent que le programme que l'on vous propose est illégal ou contrefait :
* un prix "trop beau pour être vrai",
* juste un CD-ROM dans son boîtier,
* pas de certificat d'authenticité,
* pas de contrat de licence utilisateur final,
* pas de carte d'enregistrement du produit, * des produits Microsoft marqués "commercialisé uniquement avec un nouveau PC" et vendus indépendamment d'un ordinateur
* pas de disquettes ou CD-ROM, de manuel, ou tout autre élément, pour des programmes livrés pré-installés sur un disque dur,
* des disquettes de sauvegarde dont les étiquettes sont écrites à la main, qui ne sont pas emballées, ou dont la qualité semble très basse
* des manuels sous la forme de photocopies, qui ne sont pas emballés, ou dont la qualité semble très basse.
Eh ben voila ! Je me disais bien aussi que la suite logicielle vendue de force avec mes machines me semblait de basse qualité ... :-)
Non, il vont en profiter pour réduire la « fracture numérique ». Ils vont faire un appel d'offre public, MS va se présenter en première position. Bill ou Steve eux-mêmes vont se pointer avec un sourire jusqu'aux oreilles et être reçus comme des chefs d'états par le nôtre, comme cela s'est déjà produit. Et au bout du compte, Microsoft serait bien capable de rafler l'argent d'OpenOffice, sans même en tirer une certaine jouissance puisque je suis persuadé qu'il y a longtemps que c'est normal pour un certain nombre de personne travaillant pour Redmond.
Non, finalement, il vaut vraiment mieux que l'on gère cela nous-même :-)
Non, non, même pas. 400 c'est 2600 francs. Cela ne doit pas être beaucoup plus élevé que le prix au détail de Word, qui lui est en général vendu de force avec les solutions complètes des grands fabricants ou des supermarchés (et que l'on ne vienne pas arguer que Word OEM est beaucoup moins cher: ce n'est certainement pas une excuse). Même moi j'ai une licence pour Word ... avec celle de XP collée au cul de mon portable qui ne fonctionne pourtant que sous Linux.
Quand au prix moyen de Office, son chiffre est déjà optimiste puisque l'on trouve Office XP Pro en bundle à la FNAC pour 800 (Plus de 5000 francs, prix déjà constaté par le passé, d'ailleurs).
J'espère que ta missive servira t'exemple à beaucoup d'autre parce que si un nombre suffisant de revendications leur parviennent, ils commenceront peut-être à proposer de solutions un peu plus honnetes, ne serait-ce qu'en affichant en clair le contrat de licence sur la boite, par exemple.
Mais le meilleur coté de ta lettre, à mon avis, est de ne pas avoir associé "Linux" à l'affaire. Cela va faire du bien à notre image, et il est vrai que l'on essaie pas de casser un monopole pour installer le nôtre à la place (même si ce serait très cool ! :-) ).
Tu l'as dit toi même:
Un pong qui fait des ping ... astucieux, non ?
Bon, sinon il me semble qu'il essaient de faire un programme pour décrypter échelon, non ? J'étais en train de me faire à bouffer à ce moment-là ...
Finalement, cela ne m'étonne pas que Marshall bosse sous KDE et qu'il y ait eu rendez-vous à Nice: C'est sur DLFP qu'on en a le plus parlé, d'Echelon :-)
Moi je le fais souvent et je n'ai aucun problème. C'est une question de goût.
Ensuite "application moderne" me paraît légèrement ambigü ! Par exemple, même s'il existe certains packages pour le faire, je ne vais pas utiliser un toolkit particulier pour créer une DockApp !
Evidement, je ne vais pas me cantonner à la X-lib pour faire une interface utilisateur complète pour un logiciel, mais ce sera sutout pour:
- Eviter de réinventer la roue à chaque nouvelle application
- Utiliser l'environnement standard déjà employé par les autres applications.
Mais sûrement pas parce que c'est difficile de faire sans.
Au contraire: J'ai vu certaines personnes intégrer un toolkit dans leur application X simplement pour ouvrir une fenêtre, pour la seule raison qu'elles connaissaient mieux le prototype de la fonction de création de fenêtre du toolkit que celle de la X-lib (pourtant très proches). C'est du gâchis.
Le fait de passer 5 minutes à écrire proprement leur fonction en utilisant la X-lib permet de:
- s'affranchir d'un package
- s'affranchir de sa dépendence (et de son installation).
- s'affranchir de l'initialisation du toolkit
- libérer les ressources consommées par le toolkit, tant en
mémoire qu'en temps machine.
- s'assurer une compatibilité avec pratiquement tous les Unix.
Quand à ton P200 MMX, j'ai pour ma part fait tourner X sur un 486DX33 relié en réseau BNC 10Mbits à mon poste principal car j'avais besoin de faire de la saisie depuis une autre pièce. C'est une machine 8 fois moins rapide que ton P200MMX, mais il faut garder à l'esprit que c'est *énorme* pour un terminal.
Et je peux te garantir qu'il était très fluide. Du coup, j'ai justement tendance à penser que ta moindre fluidité par rapport à Windows était justement due à tout ce qui tournait au dessus, et pas à X-Window lui même. Sur mon PII/350Mhz la dernière Mandrake m'a fait passer à la nouvelle version de KDE, et il faut à présent plusieurs 10 de secondes pour ouvrir KMail, par exemple. Et effectivement, toutes les applis KDE ouvertes récentes sont « molles » sur ma machine. Par contre, les dockapps et WindowMaker en général sont en super forme ...
Rholala, les boulets ! Tous ceux qui ont vu « Il était une fois dans l'Ouest » auront compris qu'il s'agissait d'un règlement de compte ! Les amis des chacals qu'il a descendu auront voulu venger leur frère ... :-)
En fait un accélérateur matériel sert à effectuer une même opération bien plus rapidement dans la mesure où l'on sait que le périphérique utilisé est spécialement doué pour effectuer cette tâche en particulier. Mais l'opération elle-même n'est pas optimisée, la manière de procéder reste la même.
Ici, on constatait tout d'abord que le principal problème était qu'aussi puissant soit le toolkit utilisé au dessus de X, et même au dessus d'autres couches encore, il faudrait de toutes façons au final résoudre ses ordres en une quirielle de fondamentales X-window avant de transmettre cette dernière au serveur.
L'idée était donc d'optimiser la couche de base, et donc d'ajouter des fonctionnalités au serveur X pour qu'il soit nativement capable de faire les opérations les plus courantes en matière d'interface graphique (ici, dessin d'un bouton), et si cela implique des précisions explicites de la part du client, d'étendre le protocole pour tenir compte de ces nouvelles capacités. Attention, cela ne veut pas dire « implémenter un toolkit coté serveur » mais plutôt permettre de définir une seule fois un modèle particulier et ensuite le réappeler plutôt que le retransmettre.
L'objet du commentaire était de mettre en évidence le fait que l'API de X-Window semble suffisament bien conçue à la base pour permettre de telles extensions sans compromettre le système entier, et donc sans avoir à en réécrire un totalement nouveau.
et "dessiner un bouton", c est pour tout système , l'appel de plusieurs primitives, et de manière ultime, pour la carte vidéo c'est une foule de pixels. on ne fait que déplacer le problème
Justement, l'une des « bonnes idées » que l'on pourrait reprendre est la création de « macros » coté serveur. On enverrait les primitives une fois, et on les rappellerait ensuite avec une seule séquence. Cela existe notament sur les serveurs de bases de données où l'overhead engendré par le parsing et le traitement d'une requête est beaucoup plus palpable.
Hors de la simple répétition, on pourrait envisager la construction d'une requête beaucoup plus sophistiquée comme par exemple le dessin d'un bouton (coin, bords, fond, légende, ...) et ne renvoyer que les coordonnées des coins pour que le serveur réadapte le même « contrat de phase » aux nouvelles dimensions ...
Tout cela implique, si ce n'est pas déjà disponible, une extension officielle du protocole. Par contre, on n'a probablement pas besoin de réécrire X pour cela.
# Re: Est-ce que KDE-look est mort?
Posté par Obsidian . En réponse au journal Est-ce que KDE-look est mort?. Évalué à 1.
# Re: Super sans plomb - 10 centimes d'euro le litre
Posté par Obsidian . En réponse au journal Super sans plomb - 10 centimes d'euro le litre. Évalué à 1.
* un prix "trop beau pour être vrai",
* juste un CD-ROM dans son boîtier,
* pas de certificat d'authenticité,
* pas de contrat de licence utilisateur final,
* pas de carte d'enregistrement du produit,
* des produits Microsoft marqués "commercialisé uniquement avec un nouveau PC" et vendus indépendamment d'un ordinateur
* pas de disquettes ou CD-ROM, de manuel, ou tout autre élément, pour des programmes livrés pré-installés sur un disque dur,
* des disquettes de sauvegarde dont les étiquettes sont écrites à la main, qui ne sont pas emballées, ou dont la qualité semble très basse
* des manuels sous la forme de photocopies, qui ne sont pas emballés, ou dont la qualité semble très basse.
Eh ben voila ! Je me disais bien aussi que la suite logicielle vendue de force avec mes machines me semblait de basse qualité ... :-)
[^] # Re: La BSA organise sa semaine du "Logiciel professionnel"
Posté par Obsidian . En réponse à la dépêche La BSA organise sa semaine du "Logiciel professionnel". Évalué à 2.
La canicule est bien loin, à présent :-(
[^] # Re: Non,
Posté par Obsidian . En réponse au journal Open-Office en France c'est 4 000 000 000 d'euros. Évalué à 3.
Non, finalement, il vaut vraiment mieux que l'on gère cela nous-même :-)
[^] # Re: Open-Office en France c'est 4 000 000 000 d'euros
Posté par Obsidian . En réponse au journal Open-Office en France c'est 4 000 000 000 d'euros. Évalué à 1.
Quand au prix moyen de Office, son chiffre est déjà optimiste puisque l'on trouve Office XP Pro en bundle à la FNAC pour 800 (Plus de 5000 francs, prix déjà constaté par le passé, d'ailleurs).
# Re: Remboursement de Windows par Dell
Posté par Obsidian . En réponse au journal Remboursement de Windows par Dell. Évalué à 5.
J'espère que ta missive servira t'exemple à beaucoup d'autre parce que si un nombre suffisant de revendications leur parviennent, ils commenceront peut-être à proposer de solutions un peu plus honnetes, ne serait-ce qu'en affichant en clair le contrat de licence sur la boite, par exemple.
Mais le meilleur coté de ta lettre, à mon avis, est de ne pas avoir associé "Linux" à l'affaire. Cela va faire du bien à notre image, et il est vrai que l'on essaie pas de casser un monopole pour installer le nôtre à la place (même si ce serait très cool ! :-) ).
[^] # Re: O tempore, O mores !
Posté par Obsidian . En réponse à la dépêche L'administration du Massachusetts passe sous Linux.. Évalué à 5.
« Flam centurio, non e galaxia nostra »
Issu de:
http://www.cledut.net/xylo.htm(...)
[^] # Re: C'était déjà dans les journaux linuxfr le 27/9
Posté par Obsidian . En réponse à la dépêche Faille de sécurité exploitable à distance dans mplayer. Évalué à 1.
[^] # Re: Un cerveau sous Linux
Posté par Obsidian . En réponse à la dépêche Un cerveau sous Linux. Évalué à 2.
# Re: Un cerveau sous Linux
Posté par Obsidian . En réponse à la dépêche Un cerveau sous Linux. Évalué à 1.
- Ah non pas du tout ! Efface ...
[^] # Re: écrans kde dans alias :-)
Posté par Obsidian . En réponse au journal écrans kde dans alias :-). Évalué à 2.
ou un flux MP3 ?
En fait, il ne voulait pas l'avouer, mais Marshall écoutait Bide et Musique pendant qu'il codait :-)
[^] # Re: écrans kde dans alias :-)
Posté par Obsidian . En réponse au journal écrans kde dans alias :-). Évalué à 1.
Un pong qui fait des ping ... astucieux, non ?
Bon, sinon il me semble qu'il essaient de faire un programme pour décrypter échelon, non ? J'étais en train de me faire à bouffer à ce moment-là ...
Finalement, cela ne m'étonne pas que Marshall bosse sous KDE et qu'il y ait eu rendez-vous à Nice: C'est sur DLFP qu'on en a le plus parlé, d'Echelon :-)
Autrement, il doit rester le chat:
http://www.m6.fr/M6_statique/html/series/alias/index.shtml(...)
[^] # Re: Après X, voici Y...
Posté par Obsidian . En réponse à la dépêche Après X, voici Y.... Évalué à 1.
Ensuite "application moderne" me paraît légèrement ambigü ! Par exemple, même s'il existe certains packages pour le faire, je ne vais pas utiliser un toolkit particulier pour créer une DockApp !
Evidement, je ne vais pas me cantonner à la X-lib pour faire une interface utilisateur complète pour un logiciel, mais ce sera sutout pour:
- Eviter de réinventer la roue à chaque nouvelle application
- Utiliser l'environnement standard déjà employé par les autres applications.
Mais sûrement pas parce que c'est difficile de faire sans.
Au contraire: J'ai vu certaines personnes intégrer un toolkit dans leur application X simplement pour ouvrir une fenêtre, pour la seule raison qu'elles connaissaient mieux le prototype de la fonction de création de fenêtre du toolkit que celle de la X-lib (pourtant très proches). C'est du gâchis.
Le fait de passer 5 minutes à écrire proprement leur fonction en utilisant la X-lib permet de:
- s'affranchir d'un package
- s'affranchir de sa dépendence (et de son installation).
- s'affranchir de l'initialisation du toolkit
- libérer les ressources consommées par le toolkit, tant en
mémoire qu'en temps machine.
- s'assurer une compatibilité avec pratiquement tous les Unix.
Quand à ton P200 MMX, j'ai pour ma part fait tourner X sur un 486DX33 relié en réseau BNC 10Mbits à mon poste principal car j'avais besoin de faire de la saisie depuis une autre pièce. C'est une machine 8 fois moins rapide que ton P200MMX, mais il faut garder à l'esprit que c'est *énorme* pour un terminal.
Et je peux te garantir qu'il était très fluide. Du coup, j'ai justement tendance à penser que ta moindre fluidité par rapport à Windows était justement due à tout ce qui tournait au dessus, et pas à X-Window lui même. Sur mon PII/350Mhz la dernière Mandrake m'a fait passer à la nouvelle version de KDE, et il faut à présent plusieurs 10 de secondes pour ouvrir KMail, par exemple. Et effectivement, toutes les applis KDE ouvertes récentes sont « molles » sur ma machine. Par contre, les dockapps et WindowMaker en général sont en super forme ...
[^] # Re: Anniversaire de la mort de Charles Bronson
Posté par Obsidian . En réponse au journal Anniversaire de la mort de Charles Bronson. Évalué à 1.
[^] # Re: Anniversaire de la mort de Charles Bronson
Posté par Obsidian . En réponse au journal Anniversaire de la mort de Charles Bronson. Évalué à 2.
[^] # Re: Carte 3C509 et changement de port.
Posté par Obsidian . En réponse au journal Carte 3C509 et changement de port.. Évalué à 1.
# Re: La vie trépidante des moules... (TOME I)
Posté par Obsidian . En réponse au journal La vie trépidante des moules... (TOME I). Évalué à 1.
[^] # Re: Init
Posté par Obsidian . En réponse au journal Init. Évalué à 1.
Même 12 secondes pour le noyau c'est énorme. T'es sûr que ton 1800+ n'est pas un 180+ ? :-)
# Re: Init
Posté par Obsidian . En réponse au journal Init. Évalué à 1.
[^] # Re: Init
Posté par Obsidian . En réponse au journal Init. Évalué à 1.
[^] # Re: Après X, voici Y...
Posté par Obsidian . En réponse à la dépêche Après X, voici Y.... Évalué à 1.
Ici, on constatait tout d'abord que le principal problème était qu'aussi puissant soit le toolkit utilisé au dessus de X, et même au dessus d'autres couches encore, il faudrait de toutes façons au final résoudre ses ordres en une quirielle de fondamentales X-window avant de transmettre cette dernière au serveur.
L'idée était donc d'optimiser la couche de base, et donc d'ajouter des fonctionnalités au serveur X pour qu'il soit nativement capable de faire les opérations les plus courantes en matière d'interface graphique (ici, dessin d'un bouton), et si cela implique des précisions explicites de la part du client, d'étendre le protocole pour tenir compte de ces nouvelles capacités. Attention, cela ne veut pas dire « implémenter un toolkit coté serveur » mais plutôt permettre de définir une seule fois un modèle particulier et ensuite le réappeler plutôt que le retransmettre.
L'objet du commentaire était de mettre en évidence le fait que l'API de X-Window semble suffisament bien conçue à la base pour permettre de telles extensions sans compromettre le système entier, et donc sans avoir à en réécrire un totalement nouveau.
[^] # Re: action
Posté par Obsidian . En réponse à la dépêche Les pro-brevets préparent la riposte. Évalué à 2.
Mais bon, il s'agit d'abord de savoir si ces deux-là sont en bon ou mauvais termes, avant de jouer sur ce tableau.
[^] # Re: Renommer un fichier en bash...
Posté par Obsidian . En réponse au journal Renommer un fichier en bash.... Évalué à 3.
https://linuxfr.org/tips/52.html(...)
# Re: Renommer un fichier en bash...
Posté par Obsidian . En réponse au journal Renommer un fichier en bash.... Évalué à 3.
Sinon il faut utiliser les motifs shell
${i##.png}.jpg
Regarde dans les astuces, elle est passée.
Sinon man bash marche bien aussi.
[^] # Re: Après X, voici Y...
Posté par Obsidian . En réponse à la dépêche Après X, voici Y.... Évalué à 6.
Justement, l'une des « bonnes idées » que l'on pourrait reprendre est la création de « macros » coté serveur. On enverrait les primitives une fois, et on les rappellerait ensuite avec une seule séquence. Cela existe notament sur les serveurs de bases de données où l'overhead engendré par le parsing et le traitement d'une requête est beaucoup plus palpable.
Hors de la simple répétition, on pourrait envisager la construction d'une requête beaucoup plus sophistiquée comme par exemple le dessin d'un bouton (coin, bords, fond, légende, ...) et ne renvoyer que les coordonnées des coins pour que le serveur réadapte le même « contrat de phase » aux nouvelles dimensions ...
Tout cela implique, si ce n'est pas déjà disponible, une extension officielle du protocole. Par contre, on n'a probablement pas besoin de réécrire X pour cela.