bobert a écrit 604 commentaires

ce qui me gene le plus avec les languages de scripts, c'est que c'est pas compile...
[...]
Bon, je sais c'est un coup a prendre tout ca, mais quand meme la phase de compilation permet quand meme de detecter un tres grand nombre d'erreurs de facon automatique..


Il y a des prémisses à ton raisonnement qui sont discutables...

1) Le premier est que dans ton esprit tu limites l'usage des langages dynamiques [1] aux seuls scripts alors qu'ils sont de facto des langages permettant de réaliser des applications des pieds à la tête

2) Le second est qu'un code écrit dans un langage statique contient autant ou moins de bugs qu'un code écrit dans un langage dynamique.

- D'une part, mon impression est que, les langages dynamiques étant plus expressifs que les langages statiques, ils permettent de décrire le même besoin avec moins de code, de façon plus lisible ; j'y vois plutôt (toutes choses égales par ailleurs) un gage de plus grande fiabilité.

- D'autre part, certains bugs (dans quelle proportion ? non négligeable je dirais) détectés à la compilation découlent directement du fait que le langage... requiert une compilation ! Exemple typique: dans un langage statique tu écris souvent qu'une classe C hérite d'une classe S ou implémente une interface I. Si tu as mal écrit l'identifiant de S ou I, ou que celui-ci a changé au cours du développement, tu auras une erreur à la compilation. Or, aussi gênant que ça puisse paraître quand on n'y est pas habitué, l'implémentation la plus naturelle dans un langage dynamique de cet exemple ne nécessite *pas* d'écrire S ou I... on adopte plutôt l'approche de "duck typing" (pas le temps d'expliciter mais d'un coup de google ca se trouve) --> avec un langage dynamique, de telles erreurs *n'existent pas*

3) Dernier point: l'idée, ou l'espoir, que corriger des bugs à la compilation fasse gagner du temps

=> De toutes manières, on ne peut pas se contenter de débugger lors de l'écriture du code, les tests unitaires + la phase de "recettage", de tests fonctionnels, sont indispensables. Ceci considéré, chasser 2 ou 3 bugs supplémentaires lors de la compilation ne change pas grand-chose

[1] J'y vais à la louche dans ce commentaire et ne considère que des langages "dynamiques" (python, ruby,...) contre des langages "statiques" (c++, c#, java,...).

Si on en croit [1] la charge utile est limitée à 1,9 tonne... à comparer aux 150000 tpl (tonnes de poids lourd) d'un super-pétrolier actuel ou d'un transporteur de frêt actuel (post-panamax) [2]... il ne faut pas s'attendre à trouver une solution de remplacement de ce côté, c'est illusoire.

[1] http://www.zeppelin-nt.com/pages/E/luftsch_u_faq.htm(...)
[2] http://www.unctad.org/fr/docs/rmt2001ch4_fr.PDF(...)

Donc, après avoir vu un nombre non-négligable de disque dur (d'une marque a trois lettres) lacher

... à tel point que ladite marque a trois lettre a lâché les disques durs, d'ailleurs...

Qu'est-ce qui t'a séduit avec apt par rapport à urpmi ?

1) La distribution la plus adaptée est celle que tu connais le mieux, tout simplement.

2) Tu n'auras pas seulement à assurer de l'administration système à distance mais également des interventions pour modifier l'apparence du bureau, ajouter/déplacer des icones, etc. Pour tout ça, nx est extrêmement utile. (paquetages nxserver côté serveur et nxclient ou knx côté client)

3) Je pense que ça demande un peu de bouteille, parce qu'il y a une probabitité élevée pour qu'un souci ou un problème qui t'est encore inconnu survienne, et là il va falloir faire face sous peine de décrédibiliser toute l'opération... et l'opérateur ! Donc honnêtement je te conseillerais d'attendre d'être (encore plus) à l'aise sous linux pour commencer à l'installer chez les autres.

4) est-ce que cela ne demande pas trop de boulot/temps ?

Selon le côté où on se place, on peut voire ça comme un sacerdoce ou une aventure partagée... mais dans les deux cas, il faut reconnaître que ça bouffe un maximum de temps...

Est-ce que les gens sont contents en général ?

Ceux pour qui je concentre mes efforts, oui. Je veux parler de ceux qui ont bien conscience que changer leurs habitudes va leur demander un réel investissement personnel de leur part. J'ai laissé tomber définitivement les gens qui veulent simplement essayer, pour diverses raisons, mais sans vouloir y mettre du leur.

Quel niveau d'expertise sur linux est-il recommandé d'avoir ?

cf plus haut

Il est bien, ce jeu ? Est-ce qu'on en a vite fait le tour, au niveau de la stragétie, ou bien il est très riche ?

Qu'est-ce que vous arrivez à faire tourner avec Qemu+kqemu ?
En terme de performances, qu'est-ce que ça donne ?
Est-ce que ça permet de faire tourner plus d'applications que wine (ou winex ou crossover ou je ne sais quelle autre dérivé) ?
Quelle est l'occupation mémoire du bousin ?
Le copier-coller fonctionne-t-il entre une appli sous Qemu et le reste de sa session X ?

Je recherche un exemple de fichier latex qui permet d'écrire une lettre de motivation.

Une lettre de motivation s'écrit à la main en principe, à moins que tu n'écrives comme un cochon...

Par ailleurs, je m'interroge sur l'utilité de gagner 2 secondes et 42 centième sur le temps de démarrage : est-ce aussi crucial que ça ?

Il ne faut pas oublier que ça concerne beaucoup de monde.

Un bug dans OOo ou Microsoft Office qui ferait perdre 1h de boulot à 100000 personnes, c'est une perte de 48 années-hommes connement, pour rien (calcul basé sur un temps de travail hebdomadaire de 40h).

Inversement, faire gagner 1 minute par jour ouvré à 100000 personnes, c'est (en comptant 250 jours ouvrés par an) 200 années-hommes de gagnées...

Des petits riens, qui profitent à beaucoup de monde... au final, le jeu en vaut la chandelle, assurément.

Ça présente un intérêt, techniquement ? Il y a des équivalents dans d'autres frameworks ?

De mémoire, si tu changes le chemin via le centre de configuration de KDE, comme expliqué + bas par Olivier Serve, on te propose de renommer le répertoire.
En ce qui concerne le répertoire de fichiers temporaires, je n'aimais pas non plus me retrouver avec un ~/tmp sous le nez en permanence et je l'ai renommé en ~/.tmp . Il faut en plus d'en informer KDE le préciser dans ton ~/.bashrc:

export TMP=${HOME}/.tmp
export TMPDIR=${TMP}

La vache, mais tu loues ta signature comme espace publicitaire, c'est pas possible autrement !!

C'est d'autant moins une convention que les utilisateurs qui n'aiment pas se faire suer avec les majuscules en ligne de commande, dont je suis, renomment plutôt ~/Documents en ~/documents, par exemple

Récupère la version la plus récente de Leo ( http://sourceforge.net/projects/leo/(...) ). Ne t'arrête pas à l'aspect austère de son interface, c'est un éditeur qui cache bien son jeu. Il offre de nombreuses possibilités, mais celles qui t'intéresseront dans ton cas sont:

1) c'est un outliner (je ne sais pas traduire ça en français): il gère une arborescence de noeuds ; chaque noeud a un titre, et tu peux lui associer du texte et des couples (paramètre, valeur)

2) tu peux cloner les noeuds, ce qui te permets par exemple de partager des noeuds entre une partie de ton arbre dédiée à ton journal et une autre qui deviendra un rapport. Exemple (chaque o est un noeud):


o Journal
....o 200509
........o Mardi 6
............o Mise en place de trucmuche
............o Réunion téléphonique avec Riri et Fifi

o Rapport
....o Installation et mise en place du bousin
........o Mise en place de trucmuche


Entre la hiérarchie "Journal" et la hiérarchie "Rapport", tu as juste cloné le noeud "Mise en place de trucmuche"

3) Depuis très récemment, Leo permet, avec le plugin rst3, de gérer très efficacement une hiérarchie de noeuds dont le contenu soit écrit en restructuredText. Et là, je dis attention, on est très proche d'une fonctionnalité qui tue.

Plutôt que d'écrire le contenu de chaque noeud en texte libre, tu fais le petit effort supplémentaire de l'écrire au format restructuredtext ( http://docutils.sourceforge.net/rst.html(...) ), qui est à ma connaissance le format de texte structuré le plus abouti. Avec ce plugin, à tout moment, tu peux cliquer sur n'importe quel noeud (par exemple Rapport) pour générer un fichier html ou latex à partir du contenu en restructuredtext de cette partie de ton arbre. Dans l'exemple que je donne, en demandant la génération d'un fichier à partir du noeud "Rapport":

- "Rapport" est exporté comme un titre
- "Installation et mise en place du bousin" devient une section de niveau 1 (h1 en html ou section en LaTeX)
- "Mise en place de trucmuche" devient une section de niveau 2 (h2 en html ou subsection en LaTeX)

Et donc, les doigts dans le nez, tu as généré ton rapport. Restructuredtext répond à pratiquement tous les besoins d'un document complexe comme un rapport ou une thèse, SAUF pour les équations

Ce plugin rst3 est encore très récent donc encore peu utilisé, mais il y a là un sacré potentiel. Ne rate pas l'occasion de l'essayer, ça vaut méchamment le coup.

La doc du plugin rst3 : http://webpages.charter.net/edreamleo/rstplugin3.html(...)

Qu'est-ce que c'est...?

Tout est dans le titre...

... en ce qui me concerne. Mais j'abonde dans le sens du commentaire précédent ;-)

As-tu déja travaillé dans une grande entreprise?

Oui, à moins que 40000 personnes ne soient pas assez pour une grande entreprise.
Je maintiens ce que je dis.

(J'ai encore fait mon café trop fort, purée...)

Pierre,
ça n'est pas une excuse valable : la réactivité d'une entreprise ne *devrait pas* être liée à sa taille.

Une ch'tite copie d'écran pour l'exemple ?

Ensuite j'aimerais savoir (sans ironie aucune) pour quelles raisons un particulier peut être amener à laisser son ordinateur tourner jour et nuit (à part pouvoir frimer avec un uptime de 457 jours ;o))

La difficulté est que la dépense énergétique d'un produit n'est pas la seule à prendre en compte ; il faut estimer aussi l'énergie grise, c'est-à-dire l'énergie qu'il a fallu pour fabriquer, emballer, distribuer puis éliminer un produit.

Considérons seulement un disque dur. J'imagine que son énergie grise, surtout pour sa fabrication, doit être élevée, certainement du même ordre de grandeur que la consommation d'énergie du disque durant toute sa vie.

Or d'une manière générale en électronique, ce sont les régimes transitoires qui ont le plus d'incidence sur la durée de vie ; je dirais qu'arrêter un disque dur une fois par jour diminue beaucoup plus sa durée de vie que de le laisser allumé en permanence.

Maintenant, d'un strict point de vue du bilan énergétique (parce qu'il faut aussi penser au stockage des données quand même...), la question se résume à estimer quantitativement laquelle de ces 2 stratégies est la meilleure:

- arrêter/redémarrer souvent son disque dur -> diminuer sa durée de vie -> en changer plus souvent
- laisser allumé son disque dur en permanence -> en changer moins souvent mais consommer de l'énergie en permanence

Le problème est loin d'être évident, et malheureusement les constructeurs ne nous aident pas beaucoup pour trancher... la pression des consommateurs n'est pas très forte non plus, ceci expliquant sans doute cela.

(Perso je laisse tout allumé, le problème de l'économie d'énergie pris en compte... reste à régler celui du bruit, et ça c'est encore une autre affaire)

En tant que root, édite le fichier /etc/inittab et remplace la ligne

id:3:initdefault:

par

id:5:initdefault:

La solution proposée ci-dessus n'est peut-être pas utilisable ailleurs que sur plateforme Microsoft. Sous linux je vois une autre possibilité : manipuler l'API de OOo en python via le module uno. Faut mettre les mains dans le cambouis mais ça ne devrait pas être trop dur.
L'exemple que je connais permet de comparer deux documents .doc ; mais l'auteur est, ou a été, intéressé pour un script de génération de pdf ; il l'a peut-être déjà écrit, je ne sais pas. Url : http://mithrandr.moria.org/blog/447.html(...)

À l'époque où ils avaient cassé du sucre sur les logiciels libres, je m'étais peut-être légèrement emporté ( http://linuxfr.org/comments/465954.html#465954(...) ).

Maintenant, quand j'entends, ça j'ai un avis beaucoup plus nuancé: qu'ils crèvent. La bouche ouverte.

Comme son nom l'indique le rasoir de barbier est à destination... du barbier !

Comme son nom ne l'indique peut-être pas, le coupe-choux ne coupe pas que des choux, poux, cailloux, etc.

Ce que je veux dire par là c'est qu'avant (excusez le caractère très flou de cette préposition) les hommes se faisaient raser par un de leur congénère. Ce qui est quand même beaucoup plus confortable, non ?

Ma foi, faute d'avis éclairé sur linuxfr... je m'en tiens aux infos du blog d'Emmanuel Clément, où on peut y lire que le susdit objet peut se manier très correctement sans faire appel à une tierce personne...

http://emmanuel.clement.free.fr/blog/index.php?2005/05/14/87-rasage(...)