Possibilité 1:
Virus prend liste des emails dans le profile de l'utilisateur. Virus envoie les e-mail directement, c'est pas compliqué de faire des envois smtp.
Pour envoyer des mails avec des virus y a absolument pas besoin que le programme soit lancé en root. Mon argument initial était que sur une machine mono utilisateur, la propagation d'un virus et les dégat qu'il occasionne sont les mêmes que l'utilisateur soit root ou pas.
Je rappelle le contexte que j'ai évoqué précédemment: une machine mono utilisateur desktop.
Effectivement, je n'avais pas songé au cas ou cette machine serait aussi un serveur DNS pour des centaines de domaines, serveur web de multiples entreprises et stockerai des comptes mails et en plus d'un serveur FTP certifié dans lequel on pourrait faker des fichiers importants. On ne doit pas faire partie de la même catégorie d'administrateur. Effectivement dans ce cas l'accès root doit faciliter la propagation d'un virus, tu as raison.
Allez, expliquez moi pourquoi la propagation d'un virus est plus facile en mode root sur une station mono utilisateur...
Cet utilisateur a tous les droits pour modifier tout ce qui est intéressant a virusser sur son système et les systèmes connectés (partoche windows, samba, ...). Il peut ouvrir des connections vers internet librement et le propager sans problèmes.
Bref, CA NE CHANGE RIEN ! Ah oui le root peut modifier les fichiers systèmes, ainsi ses utilisateurs seront contaminés (merde j'oubliais qu'il y avait qu'un user)...
Pour la nième fois, les fichiers importants de kk1 sont sur son compte, si un virus les détruits il a perdu toutes les choses importantes. Les seules raisons qui font qu'il y a moins de virus sous linux sont: bcp moins d'utilisateurs desktop, utilisateurs en général plus formés que ceux sous d'autres systèmes, moins de programmes user friendly qui exécutent les emails sans demander. Tous ces critères peuvent changer.
Mais c'est clair que plutôt que de distribuer des antivirus, on ferait mieux de faire lire une doc aux utilisateur leur apprennant qu'il ne faut pas ouvrir le fichier pamela_anderson.exe qu'ils ont reçus par email.
Je vois que tout le monde parle des noms qui finissent en ix. Mais l'extrème ressemblance entre obélix et mobilix, c'est _OB_LIX, pas que le ix de la fin. Mais effectivement, mobilix ne fait pas penser à obélix du tout... mais plutot à mobile (unix) ! Alors si on peut plus prendre un mot commun comme mobile et en faire un dérivé, où va t'on ?
Il y a eu tellement de discussions sur les forums gentoo à ce sujet que nier ce fait est stupide. Bien sûr il y a des explications, notamment qu'il faut savoir choisir les bon flag de compile, arch=atlhon-xp est rarement celui qui fait la différence et que sous gentoo y avait pas le prelink et d'autres trucs activés par défaut. Alors que généralement sur les distros courrantes les choses sont très bien optimisées. Et l'emmerdant c'est que chaques tests coutent quand même des heures de compil...
Sinon en parlant de vitesse, le même KDE (3.0.5) (et même config) démarre en 20 secondes sous RH 8.0 et en 10 secondes sous FreeBSD 5.0. Tout ça pour vous dire que je vous conseille de tester FreeBSD qui utilise maintenant gcc 3.2.1, j'ai jamais eu de desktop aussi rapide et aussi dynamique (même mes compiles [probalement mal optimisées] sous gentoo ne m'ont donnés des résultats pareils, j'ai été bluffé...)
J'ai lu y a peu de temps que les options de debug avec gcc ne devaient jamais ralentir l'exécution et que l'unique chose qui changeait était la taille des exécutables...
TCPA semble plus dangereux que d'autres tentatives car c'est la première fois qu'il y a une alliance hardware-software si forte. De plus, c'est un projet qui peut engendrer des revenus pour beaucoup de sociétés et pas uniquement MS et Intel.
Si TCPA s'impose, ça ne métonnerait absolument pas qu'on ne puisse plus accéder dans l'ordre au sites: des banques, d'achats online, enchêres, le reste. Les gens qui ont un PC ancien arrivent rarement à gêrer leur compte en banque online, déjà aujourd'hui.
Bien sûr, ce ne sera pas un vrai problème avant 3-4 ans, le temps que 95% du parc informatique soit renouvelé, mais après ça pourrait devenir grave.
Je pense que la principale raison du futur échec du TCPA tient au petit pirate qui sommeil en chacun d'entre nous y compris les utilisateurs lambda. Ces utilisateurs bien que payant généralement une partie des licences de leur machines sont souvent tentés par le chargement d'un mp3, la copie d'un jeu, le visionnage d'un divx... La plupart des gens sont déjà habitués à cette "liberté", il va être très difficile de leur faire comprendre qu'avec leur nouveau PC TCPA/Palladium tout ça est fini. Bien sûr, on pourra toujours leur dire qu'ils pourront rebooter en mode non-certifié et faire ce qu'ils veulent, mais ça devient vite très compliqué.
Si effectivement le but du java était de compiler une seul fois, le but premier était d'avoir un programme tournant sur de multiples platteformes de manière aisée. Qu'en est il à ce jour ? Le jre officiel tourne sous windows, linux, macos, probablement quelques autres architectures. Sur FreeBSD par exemple on attend tjs un JRE récent stable et un petit peu supporté par Sun.
Il faut dire que quand Java a débuté, il n'y avait pas vraiment de compilateurs multi-platteformes et on se disait qu'il serait plus simple de ne compiler qu'une seule fois et de faire des machines virtuelles sur les différentes architectures. Actuellement, les bonnes machines virtuelles ne touchent qu'une partie des platteformes et l'exécution est nettement plus lente qu'en natif. D'un nautre côté on a gcc qui compile pour toutes les architectures et si on l'associe à des libs additionnelles comme qt, il devient possible de compiler pour tout un tas de platteformes, bien plus que celles possédant un jre fonctionnel et avec un gain de vitesse à l'exécution.
Bref à mon avis Java est sur le déclin, peut-être que gcj lui donnera un coup de pouce ?
Effectivement. Et celui qui redige a, ou mal lu l'article, ou cherche a faire un troll, ce qui n'est pas beaucoup mieux.
Ce qui serait intéressant pour moi serait de compiler de grosses applications style OO, moz ou KDE et de comparer leurs vitesses. Il faudrait peut être aussi tester les différences induites par les différentes options de gcc, mais il y en a tellement...
Sauf erreur je crois que le noyau linux avait été compilé avec intel c++ 6.0.
Pour le reste, gcc est quand même excellent quand on voit les performances atteintes et le fait qu'il compile pour une multitude d'architectures.
Entre un hardware sun et un hardware i386, y a quand même une différence importance au niveau de la fiabilité. Les machines sun, même si elles sont lentes par rapport au PC classiques ont des cpus fiables, de la ram fiable, des disques en raid d'excellente qualité... C'est très dur d'arriver au même résultat avec des composants fabriqués par un tas de constructeurs différents comme sur les pcs.
Pis bon, je c'est pas jusqu'à combien de proc peuvent monter certaines sun mais ça doit au moins être 64 et largement plus, ça n'existe pas dans le monde i386.
Bref, il faut vraiment avoir des besoins très spécifiques et y mettre le prix pour acheter du sun.
Permettre l'audi: Les logiciels proprios peuvent très bien le permettre, il suffit de signer des DNA et je suis sûr que moyennant l'achat de suffisamment de licences on peut avoir accès a tout.
De plus, si tu me relis, tu peux voir que je dis que la sécurité entre aussi en jeu et que cela peut determiner le choix. Mais pour certains softs, la sécurité n'est vraiment pas importante, c'est comme si avant d'utiliser photoshop tu voudrais auditer son code.
"la pérénité de l'application doit être assurée, cad si un jour la boite arrête de la dévellopper, on doit pouvoir la reprendre"
Oui mais non :-)
En fait cette phrase, ne contredit pas ce que je disais, car elle ne touche pas aux mêmes soft. Si sans l'application, le format de fichier est a peu près inutilisable (même si totallement documenté), cela indique que c'est un format connu, mais pas pour autant ce que j'appelle un standard. Un standard pour moi est quelque chose d'officel qui peut et qui est lu et modifié pas beaucoup d'applications, comme le HTML version X par exemple. C'est clair que dans le cas ou l'application est très spécifique, qu'on sait pertinemment qu'il n'y en a pas d'autre et qu'il serait très couteux d'en refaire une ayant les caractéristiques de l'application originale, il vaut mieux s'assurrer de la perrenité de son choix en exigeant le sources même si elles ne sont pas divulguables publiquement.
Outre le fait que les 2 derniers arguments tombent plus ou moins complétement lorsqu'il s'agit de standards, que c'est le cas 95% du temps et que le premier argument n'est pas toujours vrai, Il y a une chose dont tu ne parles pas du tout. La productivité entre le soft X et le soft Y. Avec le soft X BSD GPL, un employé fait 5 heures pour faire son boulot et un autre (avec les mêmes compétences) fait 20 minutes avec M$ Y méchant. Ca compte pas ça ? Le gain de productivité est le facteur le plus important dans les choix de programmes. Par exemple, les boîtes utilisant la CAO, sont capable de payer un soft 10 fois plus cher, si sur l'année l'architecte qui l'utilise fait 10% de boulot en plus.
Moi, je préconise l'utilisation de logiciels libres lorsque la productivité est supérieure ou équivalente au logiciels propriétaire, également quand le logiciel propriétaire n'assure pas la sécurité voulue et dans tous les cas que tous les logiciels utilisent des formats standards.
Je crois qu'il n'est pas bon d'imposer le libre comme il n'est pas bon d'imposer n'importe quoi d'autre. Même au niveau de l'administration, les choix locaux doivent rester libres.
"We feel that when we are putting public information out in the open, then it should not be through a proprietary software."
Je ne comprend évidemment pas ce point de vue, on a l'impression qu'un soft propriétaire fait automatiquement des documents de formats propriétaires.
L'important c'est d'utiliser des standards de documents, de partages de fichiers, de réseaux, .... Si MS fait des documents standards et des applications qui ont d'autres avantages sur des applications libres, style une édition ou une visualisation plus simple, pourquoi l'interdire ? Du moment que ce programme exporte un document standard, au moment ou une logiciel libre semblera supérieur à la solution propriétaire, il la remplacera.
Ensuite, le coût, la maintenance, la sécurité entreront aussi en jeu.
Mais n'imposons jamais quelque chose, c'est le contraire même de la liberté.
C'est comme si tu vas sur le site officiel de FreeBSD, tu vois qu'il y a environ 40 failles par an pour le système de base + 20 pour les applications tierces. Le système de base, contient lui aussi des applications qui pourraient être tierces, comme openssl, openssh, ...
Si on enlève les bugs permettant des accès difficilement exploitable à la mémoire ou à certains fichiers, les bugs qui ne sont exploitables qu'avec un compte local, les bugs qui sont exploitables que si certains services sont utilisés, on recompile le noyau environ 4 fois par an (pour fixer tout les trous, y compris ceux difficilement exploitables et utilisable qu'en local !). D'autres trous sont corrigibles en changeant la config, ou en enlevant le suid si on ne souhaite pas recompiler le soft. A part openssh, l'an passé, il n'y a pas eu de vulnérabilité à distance digne de ce nom pour le système de base.
Si de plus on considère que tout les services tiers sont encapsulés dans des machines virtuelles (jails), on peut dire que je suis un admin qui dors bien.
Alors quand on voit ces comparatifs à la con qui disent que les unix en général sont plus vulnérable que windows, ça fait pitié, des incompétants ou des corrompus. Ce qui est triste, c'est que beaucoup de gens gobent ces chiffres et vous les resortent...
Sur les avis incomplets, Xine marche mieux. Sinon j'ai toujours l'impression que mplayer met le fichier complet en mémoire avant la lecture, Xine démarre tout de suite. Mplayer n'arrive pas a afficher en full screen une vidéo sur mon portable avec un serveur X limité, Xine oui. Sinon mplayer est la référence des codecs.
Le prob c'est qu'on a généralement envie de faire tourner quelques apps récentes pas trop lourdes aussi. Et je doute qu'au point de vue noyau, libs dans les système, compilos... ça soit simple de les faire tourner sur une distrib de 97.
Il faut aussi voir s'il y a vraiment un avantage à le faire. Sur le fait que les vieilles distrib n'auront pas des applications très lourdes comme celles d'aujourd'hui, c'est sûr. Mais ne vaut'il pas mieux installer une distribution d'aujourd'hui avec windowmaker, lynx, que d'utiliser ces mêmes programmes mais de 4 ans plus vieux ? De plus aujourd'hui toute une variété d'application sont faites pour être très légères, comme Dillo, qui n'existaient pas à l'époque.
Je conseille personnellement FreeBSD, car l'install est toujours en mode texte et passe sans problème sur du très vieux matériel et parce que le système de base fait environ 100mo avec toutefois des outils parfaitement à jour. Ensuite le système de ports permettra d'ajouter exactement ce dont on a besoin. Ca doit aussi marcher avec Debian, mais je connais moins bien et le système de package me plais un peu moins.
1) Dans les drivers NVidia, il y a des bouts dont ils ne sont pas propriétaires, entre autres.
2) Est-ce que les drivers pourraient avantager les concurrents dans la compréhension de certains mécanismes ? cela paraît peut probable.
Développer des drivers comme ceux d'NVidia qui exploitent à fond leur hardware n'est pas donné à tous le monde, et "se faire chier à développer" des drivers ça veut rien dire. Heureusement que les constructeur se fond chier à les faire car quand tu achéteras du matos sans drivers mais avec les specs je ne suis pas sur que tu ayes ni les capacités ni l'envie de les faire, alors dis pas des conneries.
Je pense qu'à long terme les drivers deviendront open source, car à moins du cas (2), il y a beaucoup d'avantages comme un support plus aisé, plus de reports de bugs, de correctifs, plus de stabilité, plus d'OS sans efforts suplémentaires.
Le problème c'est que la disposition des claviers remonte a une antiquité ou la certaines dispositions statistiques ont été prises en compte, mais ou les connaissances en ergonomie n'existaient pas. Tout les claviers classiques sont "mauvais" actuellement, mais personne n'ose casser le standard du pays.
Le clavier Dvorak est considéré comme supérieur, mais je croyais qu'il n'était adapté qu'à la langue anglaise, un lien plus haut montre qu'il existe aussi des versions françaises.
Il y a aussi des touches (clavier suisse romand) assez inutiles (adaptée à l'allemand) comme üöä qui infectent nos clavier. Il serait tellement plus pratique que les []{} soient accessibles directement (évidemment, tout le monde ne fait pas de programmation, mais tout le monde n'écrit pas d'allemand non plus). Bon sous linux il est facile de remapper les choses, mais le problème c'est de se réhabituer à chaques changement de PC, d'OS, ... C'est d'ailleur pour ça que je n'ai pas un clavier Dvorak, je m'imagine pas le trimballer avec moi...
Sans vouloir te vexer, j'ai de la peine a trouver un avantage en utilisation humaine, a mon avis ces commandes trouvent peut etre leur sens dans des scripts.
Posté par RB .
En réponse à la dépêche Le Googlisme.
Évalué à 1.
la thèse du complot interne a propos des attentas du 11 septembre soutenue par le réseau voltaire. Toutes les recherches devant donner les résultats espérés ne renvoyaient rien. Censurée. Pour moi c'est un abus. Je dis pas que google a eu le choix vu qu'ils sont aux usa, on leur a surement imposé ceci. La liberté d'expression, ils ne connaissent pas aux USa.
J'en profite pour poser une question sur un problème que j'arrive pas à fixer:
je subit un décallage de son variable (varie de 0 à 1 sec environ) sur a peu près toutes les applications. Que j'utilise OSS ou ALSA le prioblème persiste.
sur certaines applications le décallage est constant (winex), su d'autres lbreakout, ça varie pendant le jeux, passant d'un son synchro à plus d'une seconde décart et ça peu se resynchroniser. Sur certaines il n'y a pas de problèmes xine, xawtv, mplayer.
La carte son en question est une turtle beach santa cruz et j'ai aussi une carte son intégrée à la carte mère asus A7V333 (carte son qu'il est impossible de désactiver complétement via le bios car l'option n'existe pas...). Mon problème reste que je détecte les 2 cartes ou suelement la turtle beach, avec OSS et ALSA. Si kk1 à une idée, ça fait 3 semaines que je cherche...
Je voulais juste ajouter qu'il est un peu bete de comparer ce match avec le match contre Deep Blue. Meme si la partie c'est déroulée en 97, l'ordinateur utilisé était un des ordinateurs les plus puissants de la planète, massivement parallèle. Les matchs actuels (Kasparov va jouer contre Deep Junior prochainement) sont des ordinateurs "bon marchés" style (en tout cas pour Deep Junior) des octo processeurs. Donc il faut bien voir que la puissance de calcul brutte a probablement diminué entre ces confrontations au profit de l'évolution des algorythmes.
[^] # Re: Lindows toujours plus proche de Windows.
Posté par RB . En réponse à la dépêche Lindows toujours plus proche de Windows.. Évalué à 0.
Virus prend liste des emails dans le profile de l'utilisateur. Virus envoie les e-mail directement, c'est pas compliqué de faire des envois smtp.
Possibilité 2:
mkdir ~/.bin
cp /usr/bin/le_client_mail ~/.bin
patch ~/.bin/le_client_mail
export PATH="~./bin:$PATH"
voilà
Un utilisateur contaminé, toutes ces actions peuvent être détournée d'une manière ou d'une autre, sans être root.
[^] # Re: Lindows toujours plus proche de Windows.
Posté par RB . En réponse à la dépêche Lindows toujours plus proche de Windows.. Évalué à 1.
[^] # Re: Lindows toujours plus proche de Windows.
Posté par RB . En réponse à la dépêche Lindows toujours plus proche de Windows.. Évalué à -1.
Effectivement, je n'avais pas songé au cas ou cette machine serait aussi un serveur DNS pour des centaines de domaines, serveur web de multiples entreprises et stockerai des comptes mails et en plus d'un serveur FTP certifié dans lequel on pourrait faker des fichiers importants. On ne doit pas faire partie de la même catégorie d'administrateur. Effectivement dans ce cas l'accès root doit faciliter la propagation d'un virus, tu as raison.
[^] # Re: Lindows toujours plus proche de Windows.
Posté par RB . En réponse à la dépêche Lindows toujours plus proche de Windows.. Évalué à -2.
Changer les mots de passe ? Ca change quoi à la propagation sur un système mono utilisateur ?
Allez des exemples !!!!
[^] # Re: Lindows toujours plus proche de Windows.
Posté par RB . En réponse à la dépêche Lindows toujours plus proche de Windows.. Évalué à -7.
Cet utilisateur a tous les droits pour modifier tout ce qui est intéressant a virusser sur son système et les systèmes connectés (partoche windows, samba, ...). Il peut ouvrir des connections vers internet librement et le propager sans problèmes.
Bref, CA NE CHANGE RIEN ! Ah oui le root peut modifier les fichiers systèmes, ainsi ses utilisateurs seront contaminés (merde j'oubliais qu'il y avait qu'un user)...
Pour la nième fois, les fichiers importants de kk1 sont sur son compte, si un virus les détruits il a perdu toutes les choses importantes. Les seules raisons qui font qu'il y a moins de virus sous linux sont: bcp moins d'utilisateurs desktop, utilisateurs en général plus formés que ceux sous d'autres systèmes, moins de programmes user friendly qui exécutent les emails sans demander. Tous ces critères peuvent changer.
Mais c'est clair que plutôt que de distribuer des antivirus, on ferait mieux de faire lire une doc aux utilisateur leur apprennant qu'il ne faut pas ouvrir le fichier pamela_anderson.exe qu'ils ont reçus par email.
# Re: Obelix vs. Mobilix : Obelix vainqueur ?
Posté par RB . En réponse à la dépêche Obelix vs. Mobilix : Obelix vainqueur ?. Évalué à 2.
[^] # Re: comment ca plus lent ?
Posté par RB . En réponse à la dépêche Présentation et test de KDE 3.1. Évalué à 7.
Sinon en parlant de vitesse, le même KDE (3.0.5) (et même config) démarre en 20 secondes sous RH 8.0 et en 10 secondes sous FreeBSD 5.0. Tout ça pour vous dire que je vous conseille de tester FreeBSD qui utilise maintenant gcc 3.2.1, j'ai jamais eu de desktop aussi rapide et aussi dynamique (même mes compiles [probalement mal optimisées] sous gentoo ne m'ont donnés des résultats pareils, j'ai été bluffé...)
[^] # Re: comment ca plus lent ?
Posté par RB . En réponse à la dépêche Présentation et test de KDE 3.1. Évalué à 1.
[^] # Re: TCPA/Palladium va attenter à la GPL
Posté par RB . En réponse à la dépêche TCPA/Palladium va attenter à la GPL. Évalué à 1.
Si TCPA s'impose, ça ne métonnerait absolument pas qu'on ne puisse plus accéder dans l'ordre au sites: des banques, d'achats online, enchêres, le reste. Les gens qui ont un PC ancien arrivent rarement à gêrer leur compte en banque online, déjà aujourd'hui.
Bien sûr, ce ne sera pas un vrai problème avant 3-4 ans, le temps que 95% du parc informatique soit renouvelé, mais après ça pourrait devenir grave.
Je pense que la principale raison du futur échec du TCPA tient au petit pirate qui sommeil en chacun d'entre nous y compris les utilisateurs lambda. Ces utilisateurs bien que payant généralement une partie des licences de leur machines sont souvent tentés par le chargement d'un mp3, la copie d'un jeu, le visionnage d'un divx... La plupart des gens sont déjà habitués à cette "liberté", il va être très difficile de leur faire comprendre qu'avec leur nouveau PC TCPA/Palladium tout ça est fini. Bien sûr, on pourra toujours leur dire qu'ils pourront rebooter en mode non-certifié et faire ce qu'ils veulent, mais ça devient vite très compliqué.
[^] # Re: +15% - quel intérêt ?
Posté par RB . En réponse à la dépêche Comparatif Intel C++ 7.0 / Gcc 3.2.1. Évalué à 1.
Il faut dire que quand Java a débuté, il n'y avait pas vraiment de compilateurs multi-platteformes et on se disait qu'il serait plus simple de ne compiler qu'une seule fois et de faire des machines virtuelles sur les différentes architectures. Actuellement, les bonnes machines virtuelles ne touchent qu'une partie des platteformes et l'exécution est nettement plus lente qu'en natif. D'un nautre côté on a gcc qui compile pour toutes les architectures et si on l'associe à des libs additionnelles comme qt, il devient possible de compiler pour tout un tas de platteformes, bien plus que celles possédant un jre fonctionnel et avec un gain de vitesse à l'exécution.
Bref à mon avis Java est sur le déclin, peut-être que gcj lui donnera un coup de pouce ?
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par RB . En réponse à la dépêche Comparatif Intel C++ 7.0 / Gcc 3.2.1. Évalué à 3.
Ce qui serait intéressant pour moi serait de compiler de grosses applications style OO, moz ou KDE et de comparer leurs vitesses. Il faudrait peut être aussi tester les différences induites par les différentes options de gcc, mais il y en a tellement...
Sauf erreur je crois que le noyau linux avait été compilé avec intel c++ 6.0.
Pour le reste, gcc est quand même excellent quand on voit les performances atteintes et le fait qu'il compile pour une multitude d'architectures.
# Re: La valeur de la licence GPL en France
Posté par RB . En réponse à la dépêche La valeur de la licence GPL en France. Évalué à 2.
=>
les différents risques
c'est pas de l'orthographe ça, c'est de la relecture SVP
# Re: Les ordinateurs d'Oracle passent à Linux
Posté par RB . En réponse à la dépêche Les ordinateurs d'Oracle passent à Linux. Évalué à 6.
Pis bon, je c'est pas jusqu'à combien de proc peuvent monter certaines sun mais ça doit au moins être 64 et largement plus, ça n'existe pas dans le monde i386.
Bref, il faut vraiment avoir des besoins très spécifiques et y mettre le prix pour acheter du sun.
[^] # Re: Un état passe au libre
Posté par RB . En réponse à la dépêche Un état passe au libre. Évalué à 2.
De plus, si tu me relis, tu peux voir que je dis que la sécurité entre aussi en jeu et que cela peut determiner le choix. Mais pour certains softs, la sécurité n'est vraiment pas importante, c'est comme si avant d'utiliser photoshop tu voudrais auditer son code.
"la pérénité de l'application doit être assurée, cad si un jour la boite arrête de la dévellopper, on doit pouvoir la reprendre"
Oui mais non :-)
En fait cette phrase, ne contredit pas ce que je disais, car elle ne touche pas aux mêmes soft. Si sans l'application, le format de fichier est a peu près inutilisable (même si totallement documenté), cela indique que c'est un format connu, mais pas pour autant ce que j'appelle un standard. Un standard pour moi est quelque chose d'officel qui peut et qui est lu et modifié pas beaucoup d'applications, comme le HTML version X par exemple. C'est clair que dans le cas ou l'application est très spécifique, qu'on sait pertinemment qu'il n'y en a pas d'autre et qu'il serait très couteux d'en refaire une ayant les caractéristiques de l'application originale, il vaut mieux s'assurrer de la perrenité de son choix en exigeant le sources même si elles ne sont pas divulguables publiquement.
Outre le fait que les 2 derniers arguments tombent plus ou moins complétement lorsqu'il s'agit de standards, que c'est le cas 95% du temps et que le premier argument n'est pas toujours vrai, Il y a une chose dont tu ne parles pas du tout. La productivité entre le soft X et le soft Y. Avec le soft X BSD GPL, un employé fait 5 heures pour faire son boulot et un autre (avec les mêmes compétences) fait 20 minutes avec M$ Y méchant. Ca compte pas ça ? Le gain de productivité est le facteur le plus important dans les choix de programmes. Par exemple, les boîtes utilisant la CAO, sont capable de payer un soft 10 fois plus cher, si sur l'année l'architecte qui l'utilise fait 10% de boulot en plus.
Moi, je préconise l'utilisation de logiciels libres lorsque la productivité est supérieure ou équivalente au logiciels propriétaire, également quand le logiciel propriétaire n'assure pas la sécurité voulue et dans tous les cas que tous les logiciels utilisent des formats standards.
[^] # Re: Un état passe au libre
Posté par RB . En réponse à la dépêche Un état passe au libre. Évalué à 3.
J'ai parfois l'impression que quand on ne passe pas la brosse a reluire sur Linux, on parle a des murs ici...
# Re: Un état passe au libre
Posté par RB . En réponse à la dépêche Un état passe au libre. Évalué à 2.
"We feel that when we are putting public information out in the open, then it should not be through a proprietary software."
Je ne comprend évidemment pas ce point de vue, on a l'impression qu'un soft propriétaire fait automatiquement des documents de formats propriétaires.
L'important c'est d'utiliser des standards de documents, de partages de fichiers, de réseaux, .... Si MS fait des documents standards et des applications qui ont d'autres avantages sur des applications libres, style une édition ou une visualisation plus simple, pourquoi l'interdire ? Du moment que ce programme exporte un document standard, au moment ou une logiciel libre semblera supérieur à la solution propriétaire, il la remplacera.
Ensuite, le coût, la maintenance, la sécurité entreront aussi en jeu.
Mais n'imposons jamais quelque chose, c'est le contraire même de la liberté.
[^] # Re: Linux moins fiable que Windows ?
Posté par RB . En réponse à la dépêche Linux moins fiable que Windows ?. Évalué à 1.
Si on enlève les bugs permettant des accès difficilement exploitable à la mémoire ou à certains fichiers, les bugs qui ne sont exploitables qu'avec un compte local, les bugs qui sont exploitables que si certains services sont utilisés, on recompile le noyau environ 4 fois par an (pour fixer tout les trous, y compris ceux difficilement exploitables et utilisable qu'en local !). D'autres trous sont corrigibles en changeant la config, ou en enlevant le suid si on ne souhaite pas recompiler le soft. A part openssh, l'an passé, il n'y a pas eu de vulnérabilité à distance digne de ce nom pour le système de base.
Si de plus on considère que tout les services tiers sont encapsulés dans des machines virtuelles (jails), on peut dire que je suis un admin qui dors bien.
Alors quand on voit ces comparatifs à la con qui disent que les unix en général sont plus vulnérable que windows, ça fait pitié, des incompétants ou des corrompus. Ce qui est triste, c'est que beaucoup de gens gobent ces chiffres et vous les resortent...
[^] # Re: Mplayer vs. Xine ?
Posté par RB . En réponse à la dépêche Sortie de Mplayer 0.90-pre10. Évalué à 3.
[^] # Re: A propos de X
Posté par RB . En réponse à la dépêche Linux et les antiquités. Évalué à 2.
Il faut aussi voir s'il y a vraiment un avantage à le faire. Sur le fait que les vieilles distrib n'auront pas des applications très lourdes comme celles d'aujourd'hui, c'est sûr. Mais ne vaut'il pas mieux installer une distribution d'aujourd'hui avec windowmaker, lynx, que d'utiliser ces mêmes programmes mais de 4 ans plus vieux ? De plus aujourd'hui toute une variété d'application sont faites pour être très légères, comme Dillo, qui n'existaient pas à l'époque.
Je conseille personnellement FreeBSD, car l'install est toujours en mode texte et passe sans problème sur du très vieux matériel et parce que le système de base fait environ 100mo avec toutefois des outils parfaitement à jour. Ensuite le système de ports permettra d'ajouter exactement ce dont on a besoin. Ca doit aussi marcher avec Debian, mais je connais moins bien et le système de package me plais un peu moins.
[^] # Re: Rhalala...
Posté par RB . En réponse à la dépêche Drivers NVidia pour FreeBSD. Évalué à 1.
1) Dans les drivers NVidia, il y a des bouts dont ils ne sont pas propriétaires, entre autres.
2) Est-ce que les drivers pourraient avantager les concurrents dans la compréhension de certains mécanismes ? cela paraît peut probable.
Développer des drivers comme ceux d'NVidia qui exploitent à fond leur hardware n'est pas donné à tous le monde, et "se faire chier à développer" des drivers ça veut rien dire. Heureusement que les constructeur se fond chier à les faire car quand tu achéteras du matos sans drivers mais avec les specs je ne suis pas sur que tu ayes ni les capacités ni l'envie de les faire, alors dis pas des conneries.
Je pense qu'à long terme les drivers deviendront open source, car à moins du cas (2), il y a beaucoup d'avantages comme un support plus aisé, plus de reports de bugs, de correctifs, plus de stabilité, plus d'OS sans efforts suplémentaires.
[^] # Re: Clavier moderne
Posté par RB . En réponse à la dépêche Un nouveau Zaurus sur les rails ?. Évalué à 1.
Le clavier Dvorak est considéré comme supérieur, mais je croyais qu'il n'était adapté qu'à la langue anglaise, un lien plus haut montre qu'il existe aussi des versions françaises.
Il y a aussi des touches (clavier suisse romand) assez inutiles (adaptée à l'allemand) comme üöä qui infectent nos clavier. Il serait tellement plus pratique que les []{} soient accessibles directement (évidemment, tout le monde ne fait pas de programmation, mais tout le monde n'écrit pas d'allemand non plus). Bon sous linux il est facile de remapper les choses, mais le problème c'est de se réhabituer à chaques changement de PC, d'OS, ... C'est d'ailleur pour ça que je n'ai pas un clavier Dvorak, je m'imagine pas le trimballer avec moi...
# Re: Enchainer les répertoires
Posté par RB . En réponse au message [Terminal] Enchainer les répertoires. Évalué à 1.
[^] # Re: Le Googlisme
Posté par RB . En réponse à la dépêche Le Googlisme. Évalué à 1.
# Re: Alsa Release Candidate 4
Posté par RB . En réponse à la dépêche Alsa Release Candidate 4. Évalué à 1.
je subit un décallage de son variable (varie de 0 à 1 sec environ) sur a peu près toutes les applications. Que j'utilise OSS ou ALSA le prioblème persiste.
sur certaines applications le décallage est constant (winex), su d'autres lbreakout, ça varie pendant le jeux, passant d'un son synchro à plus d'une seconde décart et ça peu se resynchroniser. Sur certaines il n'y a pas de problèmes xine, xawtv, mplayer.
La carte son en question est une turtle beach santa cruz et j'ai aussi une carte son intégrée à la carte mère asus A7V333 (carte son qu'il est impossible de désactiver complétement via le bios car l'option n'existe pas...). Mon problème reste que je détecte les 2 cartes ou suelement la turtle beach, avec OSS et ALSA. Si kk1 à une idée, ça fait 3 semaines que je cherche...
# Re: Deep Fritz et Vladimir Kramnik ex-aequo
Posté par RB . En réponse à la dépêche Deep Fritz et Vladimir Kramnik ex-aequo. Évalué à 1.