Et pas ou: on archive les documents à la fois en .doc et en pdf.
Ce que je trouve assez logique: le .doc ne preservant pas toujours la forme d'une version a l'autre de word, archiver les pdf est logique pour garder un document immediatement lisible, par contre pour pouvoir re-editer les documents garder les .doc est necessaire.
De toute manière l'archivage des documents se fait en .doc et en pdf donc je ne pourrais pas utiliser OOo, ou alors il faudrait que je fasse une conversion en .doc a la fin, bof.
Bin, il faut quand meme dire qu'a mon avis aucun traitement de texte n'arrive a la cheville de FrameMaker (ni Word, ni OOo), alors forcement je les comprends qu'ils n'aient pas envie de migrer..
Grr, personellement je joue a IL2 sturmovick sur PC, un jeux capable de mettre a genoux n'importe quelle console de jeux (et même pas mal de PC): le calcul des modèles de vol, c'est tres,tres gourmand en CPU, memoire,etc..
Et encore une des choses qui agace les joueurs est que les IA ont un modele de vol simplifié ce qui leur permet de faire des maneuvre impossible pour nous, mais avoir le modele complexe pour tout le monde serait trop gourmand..
Donc tes "techniquement une console est beaucoup plus interessante pour jouer", tu te les gardes, merci, comme je disais tout depend des jeux..
J'ai aussi OOo, mais on utilise sous Word un template de document relativement sophistiqué (rien de très complexe, mais en-tete, pied de page, styles prédéfinis) qui est mal rendu par OOo.
Donc je ne peux pas utiliser OOo, il faudrait que toutes l'entreprise change, et la, c'est pas gagné: entreprise tres grosse --> inertie énorme.
Tu dis cela comme si les utilisateurs n'étaient que des boeufs trop stupides pour évoluer.
Mais dans certains domaines, les utilisateurs n'ont aucun intéret a passer a Linux:
- les "gamers fou" par exemple (pitié qu'on ne me ressorte pas l'argument des consoles de jeux: ce ne sont pas les mêmes types de jeux!)
- les gens qui doivent interagir avec d'autres en utilisant les .doc, au boulot j'utilise Office2000 sur Wine, ça marche mais cela se plante un peu trop souvent: les gens qui ont le choix entre un PC sous Windows et un sous Linux avec Office2000 sur Wine prennent le PC sous Windows.
Donc avant de critiquer la 'resistance au changement' des utilisateurs, il faut d'abord supprimer les raisons objectives pour lesquelles les utilisateurs restent sous Windows (et le dual boot est une solution assez peu interressante: 2 OS dit 2 fois plus de patches, de 'trucs' à apprendre, etc..). et faire de la pub dans les endroits ou il n'y a pas de raison pour rester sous Windows: les caisses enregistreuses par exemple.
>Donc, tu dois utiliser les puissances de 2 quand tu travail avec des octets.
Cela n'a rien d'evident!! Je bosse dans les telecom et j'ai vu des documents ou 1 kilooctet == 1000 octets.
Le plus logique est d'oublier l'aberation recente ou kilo==1024 et d'utiliser kibi(ki) pour 1024, lier la signification du prefixe a la valeur suivante est absurde..
Posté par reno .
En réponse à la dépêche Palm/Linux.
Évalué à 5.
Mouai, les y avait qu'a.. Be s'est planté, Next s'est planté..
M'est avis que vaincre le cercle vicieux: pas d'utilisateur --> pas d'application et pas d'application --> pas d'utilisateur est loin d'être trivial.
Les free software sont les seuls a avoir réussi recemment a le faire et franchement je suis tres pessimiste sur les chances d'un produit propriétaire qui se fonde sur ses capacités technique pour lutter contre une base installée énorme..
Bah Lout, c'est le language qui prend les options à gauche et à droite des mots clef, non?
Syntaxe plus claire par rapport à Latex, ok mais toujours bof personellement.
Skribe m'a l'air d'avoir une syntaxe vraiment claire, c'est basé sur du Scheme, je ne suis pas un fana des langages fonctionnels mais cela a l'air d'être vraiment clair comme language: http://www-sop.inria.fr/mimosa/fp/Skribe/doc/user.html(...)
Maintenant je ne sais pas si c'est aussi puissant que Tex/Latex..
Bin justement, les utilisateurs sont habitués à faire des trucs alambiqués avec leur traitement de texte..
Mais à part ça, j'ai quand même vu pas mal de publication fait en latex ou les images sont mis à la fin du chapitre: bonjour la lisibilité pour le lecteur qui est obligé de faire des aller-retour..
Donc si "faire des trucs alambiqués", c'est mettre en page son document, alors oui, j'espère que l'auteur va le faire un peu (un minimum suffit pas besoin de faire de la PAO).
Aussi pour avoir assisté à des discussions entre utilisateur de Latex, apparemment choisir le bon package à utiliser n'est pas si simple surtout en cas d'i18n..
> ce n'est pas parce qu'une majorité d'utilisateurs est sous word qu'elle l'a choisi,
Tout à fait: au boulot, je dois utiliser word, je ne pourrais pas utiliser latex et partager les pdf par exemple, car il n'y aurait pas de barre de révision du document.. Et pas mal de gens s'en servent pour lire uniquement les modifications entre deux versions d'un même document.
Ceci dit, je déteste word et préférerais pouvoir utiliser FrameMaker qui est aussi un traitement de texte..
Et si on regarde le nombre d'utilisateur utilisant Word plutot que Latex, je ne suis pas le seul..
Et pourtant je suis un programmeur, mais franchement le Latex comme language, bof..
Pour faire une analogie "trollesque", c'est plus du Perl (que je déteste, remplacez par votre language détesté favori) que Ruby|Python (je trouves les deux interressants, c'est grave la schizophrénie docteur?).
Tttt, si le DOS avait mis ses données au début et non pas a la fin, il n'y aurait pas eu trop de probleme pour étendre la taille mémoire utilisable lorsque les CPU en aurait la possibilité.
Donc c'est aussi un manque de prévoyance sur le long terme..
>Au contraire, l'assembleur est plutot obscur comme langage.
Tu confonds clareté et explicite/implicite: python est très simple à lire, très claire car il fait des tas d'opérations implicite derriere ton dos: conversion int<-> big_int, ramasse-miette, etc.. qui doivent être fait de maniere explicite en C ou en assembleur..
Sinon pour le self explicite, c'est assez répandu effectivement sur tout les languages ou les objets ont été rajoutés apres, en surcouche..
Et je trouve cela tres moche, d'ailleurs je me demande pourquoi ne pas tout simplement avoir 2 mots: def pour définir les methodes (sans le self) et fun pour définir les fonctions..
>Le fait de chercher à ne rien cacher de ce qu'il se passe est au contraire une grande force de python.
Oui, mais ce n'est pas appliqué partout autrement python serait de l'assembleur, un bon contre exemple est l'unification des int et des long int en python.. Pour l'appel de fonction, ce principe la aurait put s'appliquer ou pas, il l'a été mais bof..
Pour ce qui est des décorateurs, j'avoue ne pas comprendre ce que c'est ni à quoi ça sert, quelqu'un aurait-il une URL qui explique cela de façon claire? J'ai déja essayer de lire le PEP, mais sans succes..
J'ai lu les commentaires "Explicit is better than implicit" mais je soupconne que c'est une justification 'a posteriori', cela reflete juste qu'historiquement au debut il n'y avait pas d'objet et cela a été rajouter ensuite..
Le 'Explicit is better than implicit' est un argument creux: si c'était le cas, on programmerait toujours en assembleur: il n'y a pas plus explicite comme language.
Bon, c'est comme tout, cela a des avantages et des inconvénients.
Le seul réel avantage que je connaisse , c'est pour appeler un attribut f sur une liste d'objets, on peut faire facilement un map( f , <liste d'objet>) mais au niveau cout visuel c'est quand même cher payé!
>Ca devie du standard ? Non, il n'y a pas de standard
Ca depend de quel standard tu parles, du standard façon W3C ok il n'y a pas de standard, de l'interprétation standard a laquelle un être humain pourrait s'attendre?
Oui!
C'est en ça que c'est un bug, et par rapport à ton lien, tu "oublie" volontairement la réponse http://linuxfr.org/comments/501397,1.html(...)
qui montre bien que l'interprétation "16lignes par 16lignes" est pourrie!
Pour moi, les deux seules interpretation valables pour un format CSV sont:
- autant de separateur que d'element dans chaque lignes
ou
- autant de separateur que d'element dans la ligne de taille maximum
Avoir le nombre de separateur qui varie par 'paquet de 16 lignes' est un bug, point.
Eh bin, avec un *BUG* pareil (n'en déplaise a pbpg qui sur ce coup là est plutôt de mauvaise foie), ça doit être bien pénible de parser des fichiers csv dans ces cas la, j'ai du bol tout les csv que j'ai eu à parser avec une bete ligne de perl cela marchait..
Quand on n'est pas concerner directement, c'est toujours marrant de voir la vitesse à laquelle Microsoft, Sun, etc corrigent leurs bugs..
Je pense que "comprendre" n'est pas à prendre dans le sens quel est la raison technique derriere, mais plutot: quel est le é"'èçà@ qui a décidé d'utiliser des entiers sur 16bit plutot que sur 32bits?
Certes cela procure un gain de place disque et de mémoire, mais à l'heure actuelle, c'est plutot moyen comme compromis..
Je ne pense pas que le loopback supportera plusieurs centaines de montage..
Il me semble me souvenir que c'etait limité a une dizaine de montage pour une histoire de limite lié a SCSI (étonnant, hein!). J'avais lu ça sur lwn mais en 4eme vitesse, alors..
[^] # Re: kool mais...
Posté par reno . En réponse à la dépêche Migration vers Linux par IBM. Évalué à 2.
Ce que je trouve assez logique: le .doc ne preservant pas toujours la forme d'une version a l'autre de word, archiver les pdf est logique pour garder un document immediatement lisible, par contre pour pouvoir re-editer les documents garder les .doc est necessaire.
[^] # Re: kool mais...
Posté par reno . En réponse à la dépêche Migration vers Linux par IBM. Évalué à 1.
La, j'avoue ne pas être expert en OOo..
De toute manière l'archivage des documents se fait en .doc et en pdf donc je ne pourrais pas utiliser OOo, ou alors il faudrait que je fasse une conversion en .doc a la fin, bof.
[^] # Re: En interne ?
Posté par reno . En réponse à la dépêche Migration vers Linux par IBM. Évalué à 1.
[^] # Re: kool mais...
Posté par reno . En réponse à la dépêche Migration vers Linux par IBM. Évalué à 4.
Et encore une des choses qui agace les joueurs est que les IA ont un modele de vol simplifié ce qui leur permet de faire des maneuvre impossible pour nous, mais avoir le modele complexe pour tout le monde serait trop gourmand..
Donc tes "techniquement une console est beaucoup plus interessante pour jouer", tu te les gardes, merci, comme je disais tout depend des jeux..
[^] # Re: kool mais...
Posté par reno . En réponse à la dépêche Migration vers Linux par IBM. Évalué à 1.
Donc je ne peux pas utiliser OOo, il faudrait que toutes l'entreprise change, et la, c'est pas gagné: entreprise tres grosse --> inertie énorme.
[^] # Re: kool mais...
Posté par reno . En réponse à la dépêche Migration vers Linux par IBM. Évalué à 2.
Mais dans certains domaines, les utilisateurs n'ont aucun intéret a passer a Linux:
- les "gamers fou" par exemple (pitié qu'on ne me ressorte pas l'argument des consoles de jeux: ce ne sont pas les mêmes types de jeux!)
- les gens qui doivent interagir avec d'autres en utilisant les .doc, au boulot j'utilise Office2000 sur Wine, ça marche mais cela se plante un peu trop souvent: les gens qui ont le choix entre un PC sous Windows et un sous Linux avec Office2000 sur Wine prennent le PC sous Windows.
Donc avant de critiquer la 'resistance au changement' des utilisateurs, il faut d'abord supprimer les raisons objectives pour lesquelles les utilisateurs restent sous Windows (et le dual boot est une solution assez peu interressante: 2 OS dit 2 fois plus de patches, de 'trucs' à apprendre, etc..). et faire de la pub dans les endroits ou il n'y a pas de raison pour rester sous Windows: les caisses enregistreuses par exemple.
[^] # Re: Rien d'officiel
Posté par reno . En réponse au message histoires de kbit/s.... Évalué à 3.
Cela n'a rien d'evident!! Je bosse dans les telecom et j'ai vu des documents ou 1 kilooctet == 1000 octets.
Le plus logique est d'oublier l'aberation recente ou kilo==1024 et d'utiliser kibi(ki) pour 1024, lier la signification du prefixe a la valeur suivante est absurde..
[^] # Re: Lire sur un ecran: bof...
Posté par reno . En réponse à la dépêche Un livre électronique sous Linux.. Évalué à 4.
Je suis juste curieux, je n'en ai jamais vu.
[^] # Re: Une réaction du milieu du libre?
Posté par reno . En réponse à la dépêche [Belgique] P2P, la Sabam gagne contre Tiscali !... Évalué à 1.
Bittorrent comme dit au-dessus est juste un FTP plus pratique, évitant les goulots d'étranglement au niveau du serveur..
[^] # Re: Be est out
Posté par reno . En réponse à la dépêche Palm/Linux. Évalué à 5.
M'est avis que vaincre le cercle vicieux: pas d'utilisateur --> pas d'application et pas d'application --> pas d'utilisateur est loin d'être trivial.
Les free software sont les seuls a avoir réussi recemment a le faire et franchement je suis tres pessimiste sur les chances d'un produit propriétaire qui se fonde sur ses capacités technique pour lutter contre une base installée énorme..
[^] # Re: txt2tags est très bien aussi
Posté par reno . En réponse à la dépêche Il n'y a pas que le traitement de texte pour manipuler du texte !. Évalué à 2.
Ca me fait un peu penser a YAML par certain coté, ce n'est pas du tout le même but mais une philosophie similaire.
[^] # Re: Lout et AFT
Posté par reno . En réponse à la dépêche Il n'y a pas que le traitement de texte pour manipuler du texte !. Évalué à 3.
Syntaxe plus claire par rapport à Latex, ok mais toujours bof personellement.
Skribe m'a l'air d'avoir une syntaxe vraiment claire, c'est basé sur du Scheme, je ne suis pas un fana des langages fonctionnels mais cela a l'air d'être vraiment clair comme language:
http://www-sop.inria.fr/mimosa/fp/Skribe/doc/user.html(...)
Maintenant je ne sais pas si c'est aussi puissant que Tex/Latex..
[^] # Re: Bof, pas convaincu par l'article
Posté par reno . En réponse à la dépêche Il n'y a pas que le traitement de texte pour manipuler du texte !. Évalué à 3.
Bin justement, les utilisateurs sont habitués à faire des trucs alambiqués avec leur traitement de texte..
Mais à part ça, j'ai quand même vu pas mal de publication fait en latex ou les images sont mis à la fin du chapitre: bonjour la lisibilité pour le lecteur qui est obligé de faire des aller-retour..
Donc si "faire des trucs alambiqués", c'est mettre en page son document, alors oui, j'espère que l'auteur va le faire un peu (un minimum suffit pas besoin de faire de la PAO).
Aussi pour avoir assisté à des discussions entre utilisateur de Latex, apparemment choisir le bon package à utiliser n'est pas si simple surtout en cas d'i18n..
> ce n'est pas parce qu'une majorité d'utilisateurs est sous word qu'elle l'a choisi,
Tout à fait: au boulot, je dois utiliser word, je ne pourrais pas utiliser latex et partager les pdf par exemple, car il n'y aurait pas de barre de révision du document.. Et pas mal de gens s'en servent pour lire uniquement les modifications entre deux versions d'un même document.
Ceci dit, je déteste word et préférerais pouvoir utiliser FrameMaker qui est aussi un traitement de texte..
# Bof, pas convaincu par l'article
Posté par reno . En réponse à la dépêche Il n'y a pas que le traitement de texte pour manipuler du texte !. Évalué à -6.
Et pourtant je suis un programmeur, mais franchement le Latex comme language, bof..
Pour faire une analogie "trollesque", c'est plus du Perl (que je déteste, remplacez par votre language détesté favori) que Ruby|Python (je trouves les deux interressants, c'est grave la schizophrénie docteur?).
[^] # Re: Limitations
Posté par reno . En réponse à la dépêche SPT : Une alternative au système historique de partitionnement des PC. Évalué à 2.
Donc c'est aussi un manque de prévoyance sur le long terme..
[^] # Re: Est-ce vraiment utile ?
Posté par reno . En réponse à la dépêche SPT : Une alternative au système historique de partitionnement des PC. Évalué à 2.
Pour ce qui est de la simplicité, as-tu essayé les autres schémas avant de dire qu'ils ne sont pas simples?
[^] # Re: Pourquoi tous ces self ?
Posté par reno . En réponse à la dépêche Sortie de Python 2.4. Évalué à 3.
Tu confonds clareté et explicite/implicite: python est très simple à lire, très claire car il fait des tas d'opérations implicite derriere ton dos: conversion int<-> big_int, ramasse-miette, etc.. qui doivent être fait de maniere explicite en C ou en assembleur..
Sinon pour le self explicite, c'est assez répandu effectivement sur tout les languages ou les objets ont été rajoutés apres, en surcouche..
Et je trouve cela tres moche, d'ailleurs je me demande pourquoi ne pas tout simplement avoir 2 mots: def pour définir les methodes (sans le self) et fun pour définir les fonctions..
[^] # Re: Pourquoi tous ces self ?
Posté par reno . En réponse à la dépêche Sortie de Python 2.4. Évalué à 2.
Oui, mais ce n'est pas appliqué partout autrement python serait de l'assembleur, un bon contre exemple est l'unification des int et des long int en python.. Pour l'appel de fonction, ce principe la aurait put s'appliquer ou pas, il l'a été mais bof..
Pour ce qui est des décorateurs, j'avoue ne pas comprendre ce que c'est ni à quoi ça sert, quelqu'un aurait-il une URL qui explique cela de façon claire? J'ai déja essayer de lire le PEP, mais sans succes..
[^] # Re: Pourquoi tous ces self ?
Posté par reno . En réponse à la dépêche Sortie de Python 2.4. Évalué à 0.
Le 'Explicit is better than implicit' est un argument creux: si c'était le cas, on programmerait toujours en assembleur: il n'y a pas plus explicite comme language.
Bon, c'est comme tout, cela a des avantages et des inconvénients.
Le seul réel avantage que je connaisse , c'est pour appeler un attribut f sur une liste d'objets, on peut faire facilement un map( f , <liste d'objet>) mais au niveau cout visuel c'est quand même cher payé!
[^] # Re: formats
Posté par reno . En réponse à la dépêche Gnumeric 1.4, le début du support Windows. Évalué à 3.
Ca depend de quel standard tu parles, du standard façon W3C ok il n'y a pas de standard, de l'interprétation standard a laquelle un être humain pourrait s'attendre?
Oui!
C'est en ça que c'est un bug, et par rapport à ton lien, tu "oublie" volontairement la réponse http://linuxfr.org/comments/501397,1.html(...)
qui montre bien que l'interprétation "16lignes par 16lignes" est pourrie!
Pour moi, les deux seules interpretation valables pour un format CSV sont:
- autant de separateur que d'element dans chaque lignes
ou
- autant de separateur que d'element dans la ligne de taille maximum
Avoir le nombre de separateur qui varie par 'paquet de 16 lignes' est un bug, point.
[^] # Re: formats
Posté par reno . En réponse à la dépêche Gnumeric 1.4, le début du support Windows. Évalué à 3.
Quand on n'est pas concerner directement, c'est toujours marrant de voir la vitesse à laquelle Microsoft, Sun, etc corrigent leurs bugs..
[^] # Re: C'est marrant mais...
Posté par reno . En réponse à la dépêche Gnumeric 1.4, le début du support Windows. Évalué à 3.
Certes cela procure un gain de place disque et de mémoire, mais à l'heure actuelle, c'est plutot moyen comme compromis..
# Je ne comprends pas
Posté par reno . En réponse au message Tableaux dynamiques multidimmensionnels. Évalué à 3.
Ok, new t[10][20] ne marche pas mais faire new t[10*20], ce n'est quand même pas extremement compliqué.. new ou malloc d'ailleur.
[^] # Re: Attribuer un espace maximum a un repertoire
Posté par reno . En réponse au message Attribuer un espace maximum a un repertoire. Évalué à 2.
Il me semble me souvenir que c'etait limité a une dizaine de montage pour une histoire de limite lié a SCSI (étonnant, hein!). J'avais lu ça sur lwn mais en 4eme vitesse, alors..
# LVM?
Posté par reno . En réponse au message Attribuer un espace maximum a un repertoire. Évalué à 2.
Je n'ai jamais essayé donc je dis peut-etre des betises..