wismerhill a écrit 2608 commentaires

Si, il y a des choses assez fondamentales qui ont évolué, pour reprendre l'exemple de word que j'ai tout de même utilisé jusqu'en 1999 (avant de découvrir LeTeX :) ) c'est vrai que le texte est toujours du texte, mais par contre les possibilité de dessin intégrées a word ont évolué de même que les possibilité de faire des tableaux (compare entre word 6 et word 8 (connait pas les suivants)) et ces choses-là doivent aussi être enregistrées.

En fait à force d'y ajouter des fonctions à tout va, word n'est plus simplement un traitement de texte et tend à devenir un logiciel de PAO (et un mauvais car il n'avait pas été pensé pour ça).

Je n'aurait peut-être pas du reprendre ton exemple de la généalogie auquel je ne connait à peu près rien, mais il me semble qu'il n'y a pas de raison que l'on fasse des choses fondamentalement différentes aujourd'hui qu'il y a dix ans, alors que pouvoir faire du dessin directement dans le traitement de texte (indépendament de savoir si c'est une bonne ou une mauvaise chose) est un changement amha fondamental par rapport à de la simple gestion de texte ou l'on réserve un emplacement pour une image.

Ce sont des opportunistes, si Linux s'impose vraiment sur le marché ils chercheront (espéront qu'ils ne trouveront pas) un moyen de le récupérer.

Quand je redige un cv avec word ou avec kword c'est toujours le même cv, alors pourquoi ne serait-il pas stocké dans un même format de donnée ?

Si tu l'a fait de la même façon avec les deux alors oui ils pourraient être stocké de la même façon. Mais si justement tu as utilisé des fonctions propres à l'un et l'autre, même si le résultat sur papier est le même, alors il ne peut pas être stocké de la même façon.

Je m'interesse aux logiciels de généalogie, et ben tous les logiciels de généalogie supporte un format de donnée standard qui est le format GEDCOM.

C'est justement un bon exemple ou un format commun est facilement envisageable, faire de la généalogie ajourd'hui c'est pareil qu'il y a dix ans et si le format est bien pensé au départ il n'y a pas de raison qu'il faille y ajouter des choses fondamentalements différentes.

Un bon contre-exemple serait le dessin vectoriel ou le fait d'imposer un format commun empêcherait les logiciels d'évoluer, et on ne peut jamais dire dans ce cas que le format prévoit tout ce que l'on peut vouloir car l'évolution de la puissance des machines va rendre possible de nouvelles choses non prévues par le format.

Bref pourquoi pas un format de donnée général respecté par tous les traitements de texte en plus du format du soft lui-même

C'est en fait ce que je proposait, un format dont la base est commune avec des possibilités d'extensions spécifiques à différents programmes qui peuvent tout simplement être ignorées par les autres.

j'ai pas envie que mon cv crée avec KWord soit illisible dans 5 ou 10 ans.

Fait-le en TeX, il n'a pas bougé depuis 10 ans et fonctionnera toujours pareil dans 10 ans ;-)

Finalement, un format de données commun est une nécessité.

Je le pense aussi mais il faut que ce format soit bien réalisé et que sa pérénité soit assurée.

En fait aucun des formats actuellement utilisés en bureautique n'ont été prévu pour être des standards (au sens ou ils pourraient être utilisés par tous et non pas au sens ou plus personne ne pourrait en utiliser d'autres comme c'est le cas actuellement des formats ms).

Le xml à été fait pour ça, il commence à s'imposer et c'est une bonne chose, je crois que les choses vont dans le bon sens.

Je suis sous Windows et j'en suis très content à l'usage.

Tant mieux pour toi.

Jamais retrouvé ce confort sous Linux.

Là j'ai l'expérience contraire, je me sens moins à l'aise qund je dois réutiliser windows (ne parlons pas de MacOS), c'est d'abord la ligne de commande qui me manque (ne me parlez pas de cet erzats qu'est command.com) et ensuite KDE (que des gens essayent de porter sous windows).

En fait il y a trois ans (c'est à dire avant de découvrir Linux) je pensait comme toi que windows convenait à mes besoin, ou en tout cas qu'il n'y avait pas mieux, je ne savait vraiment pas à l'époque qu'il existait ne fusse autre chose que le dos et la série des windows pour faire fonctionner un PC.

J'ai découvert Linux beaucoup par hasard, j'arrivait pas à réinstaller windows à ce moment-là et j'avait ce truc sur un CD de magazine (je crois que c'était une mandrake 5.?) et ça avait fonctionné (à quoi ça tient la vie ;) ), après j'ai fini par réinstaller windows mais j'ai voulu continuer à voir Linux, par curiosité et parce que j'aime bien découvrir des truc nouveaux, et au fur et à mesure j'ai vu que je pouvait faire des trucs bien dessus et même des trucs que je savait pas faire sous windows.

En effet celà m'a pris du temps (je n'ai commencé à vraiment l'utiliser pour autre chose que le fun q'un an après) mais j'aimais bien découvrir, je ne l'ai donc pas considéré comme un investissement.

Je peut très bien comprendre que des gens n'aillant pas la même curiosité que moi n'aient pas envie de passer beaucoup de temps juste pour savoir si celà peut leur être bénéfique.

C'est pour celà (entre autre) que je fais partie d'un lug, pour pouvoir justement aider les gens qui auraient p'têt bien envie d'essayer à trouver leurs marques (ceux qui sont vraiment motivés s'y retrouveront bien d'eux-même, ce qui ne les discalifie pas pour une petite aide de personnes plus expérimentées ;) ).

Difficile d'utiliser un format commun si les programmes différents, bien que remplissant la même fonction, n'ont pas les mêmes fonctionnalités.



Je prend l'exemple de kword par rapport à d'autres traitements de textes, kword est un traitement de texte basé sur des frames (cf framemaker), il faut donc que son format de fichier soit compatible avec ce design alors que les autres traitements de texte non frame oriented (ex: abiword) auront un format de fichier qui reflètera leur mode de fonctionnement.

Comme le format est ouvert il est possible de créer des filtres d'import/export qui pourront plus ou moins bien convertir les données. Ça ne peut pas être parfait car les fonctionnalités ne sont pas les mêmes, dans mon exemple un filtre kword pour abiword devrait trouver un moyen de simuler les frames de kword pour conserver la mise en page et celà ne donnera probablement pas un résultat qui serait le meilleur choix possible avec les possibilités mise à disposition par abiword.

C'est pour ça que l'import de documents word dans starwriter ne pourrait être parfait que si starwriter était un clone de word, c'est à dire que toutes les fonctionnalités de word se retrouveraient dans starwriter à l'identique (bien sur des fonctions supplémentaires pourraient être présentes) pour qu'il y ait une correspondances stricte entre les fonctions word et les fonctions starwriter.

Ce n'est bien sur pas le cas et le boulot du filtre est de déchifrer les données du format word et trouver quelle est la meilleure façon d'obtenir le même résultat avec les fonctions de starwriter.

Ce que je veut dire c'est qu'un format vraiment unique obligerait les programmes qui l'utiliseraient à ne proposer que les mêmes fonctionnalités, les amélirations de certains devenant des incompatibilités avec le standard et on retombe directement dans le problème de départ.

C'est le cas du html, le format est défini puis les browser et les éditeurs html doivent se conformer à ce format, et puis certains ajoutent leurs propres fonctionnalités (comme MS ou Netscape) et celles-ci ne peuvent être correctement comprises que par leur navigateur, les autres devront essayer d'émuler le fonctionnement de ce dernier s'ils veulent pouvoir arriver au même résultat.



L'idée d'un format commun n'est pas mauvaise en elle-même, mais elle ne s'applique pas à tous les cas. elle est intéressante pour le html (du moins si elle était respectée), pour des applications bureautique j'ai des doutes.



Ou alors il faut un format mixte dont la base est commune mais pouvant contenir des extensions propres à des programmes différents (et donc étant bien définies comme telles).

Ainsi pour l'exemple des traitements de textes le format définirait comment décrire des choses comme la taille du texte, la police de caractère ou les marges, ainsi ces informations sont directement récupérables, puis des fonctionnalités plus complexes seraient spécifiques à certains programmes (et ces parties devraient être filtrées si un filtre est disponible ou ignorées sinon).

Un petit exemple du genre est le format de fichiers .desktop utilisé par KDE (depuis la version 2) et gnome, certains champs comme exec sont standard puis d'autres, préficés kde ou gnome, sont spécifiques à un environnement et simplement ignorés par les autres.

Ben moi, depuis que j'utilise Linux j'ai justement découvert tout l'intérêt des programmes en ligne de commande pour écrire des scripts, même sur une machine de bureau.

Allez, un example tout simple, renommer des fichiers, pas besoin de programme spécial, ça se fait en une ligne de commande (avec un petit for).

Un autre, je fais des études scientifiques et j'ai déjà eu à créer des séries graphiques représentant tous le même type de données, j'ai écrit un petit script qui appellait automatiquement gnuplot pour les générer, j'ai peur d'imaginer ce que ça aurait donné avec un tableur quelconque.

Encore un autre, j'ai un petit script qui a pour but de m'aider à archiver mes mails (j'en ai beaucoup mais j'aime pas supprimer).

Je veut juste dire que les possibilités de scriptage sont intéressantes aussi pour une machine desktop.

J'ai lu les trois articles et ça semble écrit par quelqu'un qui n'a pas grand intérêt dans la chose (pas militant) mais qui s'est documenté.

Donc c'est du bon, vous m'en remettrez 100g ma bonne dame, merci.

dascritch m'a souflé ce commentaire à 2 min près.

une bourde dans l'introduction ("né au début des années 1980, Linux...").

En fait il ne précise pas Linux ici, il parle de GNU qui à bien cet age (il précise plus loin dans l'article que les ligiciels libres, et non Linux, sont nés en 1980).

En faisant une petite recherche sur google j'ai trouvé un site dont le but est de référencer les patch du noyau
http://linux-patches.rock-projects.com(...)
Apparemment le site est encore assez jeune car il référence très peu de patch (et il considère le 2.4.17 comme un kernel de développement).
Si vous avez des patchs intéressants non inclus dans le noyau allez vous y faire enregistrer.

Et
preempt-kernel-rml-2.4.17-1
c'est pas un patch pour le noyau 2.4.17?

Si je lis bien il s'agit de patchs proposés sur la ML du noyau mais non intégrés, ce qui exclu forcément des patch peut-être intéressants dont les auteurs n'ont pas jugé utile de proposer de les inclure dans le noyau officiel.
Je vai tout de même garder cette page dans mes liens ;)

Il y a belnet
ftp://ftp.belnet.be(...)

Non, ceux-là sont des patch prévus pour être intégrés dans le noyau officiel, je parle d'une liste de patch ajoutant des fonctionnalités qui ne se trouvent pas dans le noyau officiel, du genre justement du patch preempt, de alsa (qui sera parrait-il intégré dans le 2.5) ou encore de patchs pour augmenter la sécurité.
Si une telle liste n'existe pas il pourrait être intéressant de la créer (faudra peut-être que j'y pense).

L'auteur de la news parle du patch preempt que je vai tester de ce pas, mais y a-t-il quelque part un site qui référencerait les différents patch disponibles pour le noyau car c'est un peu (beaucoup) un hasard si j'ai eut connaissance de ce patch.

Ils rigolent un bon coup et affichent la news pour qu'on puisse rire avec eux.

En général oui, mais j'ai eut un cas ou même les SysReq étaient inutilisables, lors de l'utilisation d'une carte TV supportée par le driver bttv, le fait d'afficher la vidéo à l'écran avait tendance à bloquer la machine au point que même alt-Sysrq-b ne fonctionnait plus (je n'avait jamais vu ça). Je soupsonne le driver NVidia d'en être la cause, je n'ai plus essayé avec la dernière version et j'hésite un peu.

Il me semble avoir lu qu'une prochaine version devrait sortir à peu près en même temps que KDE 3.

Dans le changelog, tu dis
- pas d'ouverture des documents inclus par sécurité
Ce sont uniquement les documents inclus ne se trouvant pas sur la machine locale qui ne sont pas chargés (par défaut, on peut bien sur le forcer).
Voyez la version originale :
General: prevent loading embedded documents with remote URLs (e.g., http://) for security reasons;

si j'ai bien compris, avec ce patch, un module mal écrit qui ne rendrait pas la main ne risquerait pas de bloquer la machine, juste consomer du CPU et on pourrait au moins faire un shutdown propre.

51 commentaires à l'heure ou j'écris ces lignes.
Pour une news dans la boîte autres il me semble que c'est un record.
Tiens, idée, pourquoi ne pas avoir une petite référence dans les stat (avec les pages les plus visitées) vers les news les plus commentées.

Dans mon lug on a un projet de réseau sans fil ou n'importe qui peut se connecter sans rien payer (faudrait juste qu'il aie une carte réseau sans fil).
voyez http://www.lilit.be(...) mais soyez indulgents, ce lug est très jeune et le site n'existe que depuis deux semaines ;), voyez avec le responsable du projet réseau si cela vous intéresse il pourra vous fournir des liens.

Domaine public signifie que la chose en question n'appartient à personne en particulier mais est un "patrimoine de l'humanité" que n'importe qui peut utiliser comme bon lui semble sans en référer à personne et que personne ne peut interdire à quelqu'un d'autre de l'utiliser.
Ça ressemble en effet au logiciel libre, sauf que dans le cas de la GPL (et assimilés) le logiciel reste la propriété de son(ses) auteur(s), qui peut(peuvent) d'ailleur en changer la license comme celà s'est déjà vu et en faire un logiciel non libre.

Je n'ai jamais dis que c'était rentable, juste que c'était possible, c'est évident qu'il vaut mieux utiliser la version récente plutôt que de passer don temps à vouloir faire fonctionner ce dont on a besoin sur une vieille version.

Pour des PROGRAMMES oui, pour le NOYAU tu peut rien faire.
Sinon Win2k/XP ont VBS en standard, ce qui aide beaucoup...Les auteurs de virus!