karteum59 a écrit 885 commentaires

Effectivement, c'est un point de vue qui se défend.

Mais je verrai ça d'un moins mauvais oeil lorsque j'aurai la conviction que leur vie privée (= la confidentialité de leurs données perso, pq à priori c'est sensé en contenir non ?) sera respectée, par exemple avec un EncFS ou un TrueCrypt dont _seul_ l'utilisateur aura la clé !

Et même là, on ne peut être sûr de rien : qui prouve qu'il n'y aura pas un keylogger transmettant aux instances dirigeantes tout ce que tapent ces chères têtes blondes (ou brunes) ? OK, c'est basé sur du libre donc à priori on peut davantage avoir confiance dans le soft de base (mais pas forcément dans la config que les admins "autorisés" auront mise en place)

Je suis parano ? Peut-être, mais j'ai eu la chance d'avoir été sensibilisé depuis longtemps à faire attention à ma vie privée. Et eux, seront-ils sensibilisés ? Beaucoup de PVD sont des dictatures, ne l'oublions pas !

Hmmm, en ce qui me concerne je suis également un peu sceptique.

Autant je pense que le bénéfice peut être important pour des lycéens / étudiants (même si très peu de personnes ont la chance de faire des études poussées dans les PVD), autant pour des enfants j'ai un peu peur que le "PC à 100$" soit un "gadget à 100$", alors que dans bcp de pays il y a effectivement des besoins plus criants.

Le problème des DRM est aussi un peu préoccupant AMHA : un ordinateur est une machine à créer et manipuler de l'information, mais dès le début on leur montre bien que les clés ne leur appartiennent pas et que qqun d'accrédité peut visiter leur PC et pénétrer leur intimité : bonjour l'initiation à la défense de la vie privée ! (dans des pays qui ne sont pas forcément des références en la matière...). Les gosses pourront installer Truecrypt ?

Il me semble aussi que "jouer" avec les machines (au sens bidouiller, découvrir comment ça marche, créer / installer des programmes...) fait partie de l'apprentissage. Si l'on bride cette partie, il me semble qu'une part importante de l'intérêt de la machine (et des logiciels libres) disparaît.

Enfin, je trouve qu'en terme de performances / caractéristiques, ça ressemble davantage à un gros PDA qu'à un portable. Je ne dis pas que c'est mal en soi, mais appelons un chat un chat et comparons ce qui est comparable ! (par ex. tout ce qui touche à la vidéo est relavivement hors de portée de ces machines (sauf à encoder spécialement dans une résolution timbre-poste avec des codecs peu gourmands))

Dernière chose : vu les quantités en jeu, et le fait qu'un laptop a toujours une durée de vie somme-toute réduite à l'échelle des temps géologique, quid de l'impact environnemental de l'opération OLPC ?

C'est clair !!! Cette solution est géniale !

Cependant, le principal inconvénient que je lui trouve est que la carte graphique émulée est une cirrus logic (= pas de 3D). Idem pour tous les autres composants qui sont vus par l'OS guest comme des composants virtuels QEmu et pas comme les vrais composants de la machine (ce qui signifie un overhead pour émuler le comportement de ces composants, alors que l'idéal serait d'exploiter le vrai matériel au plus près). En clair, j'aimerais bien jouer à Sim City 4 dans le windows émulé sous mon Linux !

Dans la doc technique QEmu, il est dit

"The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo [11]) are faster than QEMU, but they all need specific, proprietary and potentially unsafe host drivers"

Justement, je me demandais (pour avoir le meilleur des 2 mondes) s'il ne serait pas possible d'écrire le pilote (libre) pour windows d'une carte graphique 3D virtuelle qui se contenterait de relayer les appels GDI/OpenGL à QEmu... Je n'ai pas les connaissances requises pour écrire ça mais ça devrait bien être faisable, non ? Idem pour tous les autres composants (l'idée étant de paravirtualiser au maximum les drivers, comme Xen le fait pour Linux, BSD... mais pas windows).

Oui mais dans ce cas pourquoi mettent-ils les bouchées doubles pour développer du Linux et pas du BSD ?

Dériver un BSD leur permettrait de changer la licence pour la mettre à leur sauce, alors que la GPL protège au moins qq libertés minimales...

Mhouais, encore un programme qui n'a ni queue ni tête... ;)

Le +. c'est vrai que c'est pas terrible, mais on s'y fait vite, une fois le typage compris.

OK, pour les entiers et les flottants je peux concevoir qu'on en accomode vite en pratique.

Mais pour tout le reste : (par exemple si je veux faire une classe matrix) je suis obligé de faire des fonctions ad'hoc (matrix_add, matrix_mul, etc.) et on ne peut pas dire que ça aide la lisibilité... OK, c'est pareil en C, mais pas en C++ ni dans tous les langages un tant soi peu modernes !

Maintenant, je peux concevoir que cette contrainte (absence de surcharge des opérateurs / fonctions) provienne du typage automatique et qu'il faille choisir entre les deux fonctionnalités. Mais... est-ce vraiment le cas ? Je veux dire : le compilateur n'est-il vraiment pas capable de regarder le type des arguments d'entrée pour déterminer s'il doit effectuer l'opération '+' pour les entiers, les flottants, les matrices... ?

Une excellente introduction aux ERPs :
-> http://cps.erp5.org/sections/erp/mourlon-neyer.pdf/downloadF(...)

Heu, bof...
Dillo n'a pas exactement le même niveau de fonctionnalités que Firefox ou Konqueror. Si tu recherches un navigateur léger ET fonctionnel (+ client mail + torrent +...), je t'orienterais plutôt vers Opera (même si c'est pas libre et si c'est plus lourd que Dillo, notamment avec l'utilisation de QT).

Abiword est très bien, mais n'est pas vraiment non plus comparable à Ooo (n'oublions pas qu'il s'agit souvent de communiquer avec d'autres personnes, i.e. de savoir lire leurs documents). A la limite, KOffice me semble bcp plus abouti/utilisable tout en étant sensiblement plus léger que Ooo (mais pas autant que Abi, évidemment). Autrefois il y avait aussi Corel Wordperfect et Applixware mais je ne sais pas ce que ça donne aujourd'hui (et c'est pas libre, OK...).

Mais c'est vrai qu'il y a un peu un double discours : d'un côté dire "ouah linux c'est super optimisé" et de l'autre avoir des applis "grand public" plus gourmandes encore que sous win$. C'est moins gênant aujourd'hui car on peut récupérer des PCs 600MHz/256Mo pour pas cher et c'est suffisant pour OOo/KDE/Firefox mais pendant longtemps (et encore un peu aujourd'hui) récupérer un vieux PC en pensant le mettre sous Linux pour le donner à Mme Michu n'était pas une solution viable, car à ressources consommées équivalentes Mme Michu préfère Win98+Word6/97, à moins de lui offrir le même niveau de fonctionnalités (ce que Dillo/Abiword n'offrent pas...). Néanmoins pour ça, merci à XFCE de faire avancer les choses sur le plan desktop !

L'avantage de Terminal, c'est qu'il embarque toutes ses instances dans un seul processus. Je ne sais pas si gnome-terminal a pris cette direction, mais pour moi c'est un net avantage.

Le noyau Linux partage les pages de code entre les différentes instances d'un même processus, ce qui devrait rendre les deux types de solutions (processus distincts ou non) assez similaires du point de vue consommation mémoire.

S'il y a une différence d'emprunte mémoire, ça devrait donc venir d'ailleurs...

Moi j'aime bien SciTE (sauf cas particulier de dev)
OK c'est assez dépouillé mais ça a quand même la +part des features nécessaires et surtout ça démarre très vite (pas comme Kate ou Emacs... :)
-> http://www.scintilla.org/SciTE.html

Oui oui bien sûr
Mais je pense que ce n'est pas un problème inhérent à FUSE, juste un problème d'intégration avec KDE/Gnome (qui mettent prioritairement en avant leurs propres outils).

Au contraire, je trouve FUSE plus simple car
- pour le développeur, ça évite d'avoir une API "surcouche", spécifique à l'environnement
- et surtout, pour l'utilisateur, ça s'intègre dans le système de fichiers donc ça marche depuis partout, et pas seulement depuis une appli KDE/Gnome !

Fuse (inclus dans le noyau linux depuis le 2.6.14) permet de monter un point d'accès SSH/FTP directement dans l'arborescence, et sans surcouche KIO/Gnome-VFS (i.e. c'est utilisable depuis n'importe quelle appli et pas seulement les applis Gnome/KDE). AMHA c'est plus clean...

Excuse moi mais tes problème, c'est de la nom documentation et de la méconnaissance des système

Ouioui pastaper SVP, je n'ai dit aucun mal des *BSD (au contraire, j'en pense beaucoup de bien), j'ai juste souligné qu'un néophyte pouvait être un peu dérouté sur la gestion des packages par rapport à du rpm (et je suis d'accord que le pb se pose pour tout changement de système). Je n'ai absolument pas dit que c'était insoluble ou mal conçu / mal documenté !

D'ailleurs je connais toutes ces docs, seulement comme je viens juste de sauter le pas vers FreeBSD je n'ai pas encore tout ingurgité... (Pas le temps. Mais je n'ai pas (encore) trouvé de réponse claire aux problèmes que j'ai posé (upgrade de l'ensemble du système, possibilité de {rm -rf /usr/ports; tar xvf ports.tar.gz} sans tout casser, etc...) j'espérais avoir une réponse plus précise que RTFM...).

Ensuite les forums et mailing lists devrait te permettre de répondre à tes dernières questions

Ben on est sur un forum non ?

En quoi considères-tu que le système de paquetages soit difficile d'accès? (pkg_add programme, rien de vraiment compliqué, en une commande...)

Venant tout récemment de me mettre à FreeBSD (dont le système est apparemment similaire à NetBSD), le système semble élégant mais il y a plusieurs choses qui déroutent
- des mécanismes / commandes différentes pour les packages binaires et sources (make d'un côté, pkg_add de l'autre). Est-ce que la gestion des binaires a autant de fonctionnalités (dépendances, etc) que pour les sources ?
- quand qqch foire, comment on fait ? J'avais essayé des outils sensés simplifier la gestion des ports, mais ça a planté au milieu et j'ignore si des merdes sont restées dans mon /usr/ports ou ailleurs. J'ai aussi essayé de faire make clean mais ça prend tellement longtemps que j'ai dû l'interrompre au milieu. Au final, j'aimerais faire rm -fr /usr/ports et remettre un truc propre mais sans réinstaller tout FreBSD pour autant => est-ce qu'il me suffit de décompresser un truc comme ports.tar.gz ou y-a t-il autre choses à faire en plus ?
- comment on fait pour upgrader ? (pas un package isolé mais l'ensemble du système). j'avais sous la main l'install de FreeBSD 6.0 mais la 6.1 est sortie depuis un bout de temps (et bientôt la 6.2) => j'aimerais mettre l'ensemble de mon système à jour avant d'installer d'autres trucs déjà obsolètes... Est-ce que je peux je peux prendre directement le ports.tar.gz du FreeBSD 6.1 ou est-ce que ça va causer des problèmes avec mon noyau/libc encore en 6.0 ?
- rpm semble _vraiment_ puissant à côté de ce que je vois (mais que je ne maîtrise pas encore) sous BSD. à quel package appartient ce fichier ? -> rpm -qf fichier. Quelles sont les dépendances de ce packages ? -> rpm -qR package. quels sont les packages qui me bouffent le plus de place ? -> rpm -qa --queryformat "%{SIZE} : %{NAME}\n"|sort -n... Y-a t-il des équivalents sous BSD ?
- au passage, l'arborescence /usr/ports prend vraiment de la place (> 400 Mo pour moi). Je ne sais pas si le système BSD écrit dedans (fichiers temporaires lors d'une compilation par exemple) ou si c'est purement statique, mais dans ce dernier cas il devrait être possible de monter ports.tar.gz avec FUSE plutôt que de tout décompresser...

NetBSD est la tortue aux cotés du lièvre Linux et meme FreeBSD

Dans http://bulk.fefe.de/scalability/ l'auteur concluait "Congratulations, NetBSD! NetBSD now has better scalability than FreeBSD !" après les ajustements de l'équipe NetBSD suite à ses premiers tests. Maintenant il est vrai que ça date...

Dites-moi si c'est stupide ou pas, mais je trouve qu'un compromis intéressant est la LGPL, même pour les applis : dans ce cas précis
- mon code (et ses modifications directes) reste protégé
- mais qqun qui voudrait se servir de cette base de code et en même temps faire un travail propriétaire au dessus peut copier-coller des bouts de mon code, en faire une lib (dont les ajustements nécessaires resteront LGPL) et faire son boulot derrière sous la licence qu'il désire.

Autre exemple (corrigez-moi si je dis une connerie) : on peut très bien imaginer un OS dans lequel une plus large partie du boulot serait faite dans des bibliothèques (et pas seulement dans des processus serveurs distincts comme c'est souvent le cas avec les micro-noyaux) afin d'éviter les commutations de contexte, etc. Seulement du coup, je ne peux plus copier-coller de code du noyau Linux dans mon truc, parce que ça deviendrait GPL et ainsi seules les applis GPL pourraient tourner sous mon OS. Si Linux était LGPL le problème ne se poserait pas...

A mon corps défendant, je sais que je risque de lancer un troll velu, mais je ne peux pas m'empêcher de demander :
D'après les tests de http://bulk.fefe.de/scalability/ , il semblait que OpenBSD avaid de sérieux problèmes de performances / scalabilité (ça se dit ?), notamment face aux noyaux Linux2.6/FreeBSD/NetBSD.

Mais depuis, de l'eau a dû couler sous les ponts => qqun sait-il ce qu'il en est maintenant ?

En revanche, je suis déçu que le Conseil n'ait pas jugé toutes les procédures anti-démocratiques qui ont lieu lors de l'élaboration de la loi

Je suis plus inquiet que déçu. Ce n'est peut-être pas complètement un hasard, mais le signe que notre CC n'est pas si indépendant que ça...

Une question (probablement stupide mais bon) : apparemment tout logiciel permettant un échange de fichiers potentiellement illégaux devient illégal. Soit. Mais comment serait considéré (judiriquement parlant) un client eMule modifié pour ne télécharger / partager que la 1e moitié des fichiers ? Rigoureusement parlant, il ne permettrait pas l'échange d'oeuvres protégées (puisque les fichiers échangés seraient incomplets). Et il suffirait d'avoir un deuxième logiciel eMule dérivé (pour télécharger la 2ème moitié des fichiers) - qui elle non plus ne serait pas attaquable isolément - pour ensuite pouvoir reconstituer nos fichiers...

Maintenant, peut-être que ça ne tient pas (juridiquement) car la présence simultanée des deux logiciels sur le disque dur pourrait être assimilée à un unique dispositif tombant sous le coup de la loi...

Qqun peut confirmer l'un ou l'autre ?

Le but est une chose, le dommage collatéral en est une autre.

Et un juge applique la loi, point barre. Ce qui compte c'est ce que le législateur a écrit et non ce qu'il a potentiellement voulu dire...

Oui, mais la perception du libre par ces messieurs tout en haut influe sur les lois qui nous touchent tout en bas (brevets, DADVSI...)

Par exemple, aujourd'hui si tu en as l'envie (et les compétences) tu as le droit de concevoir dans ton garage un super système de fichiers distribué P2P avec pour idée de rendre inutile le stockage centralisé très onéreux (SANs, RAID...). Demain tu n'auras peut-être plus le droit de faire ça...

Ben, c'est déjà le cas non ?
Quel que soit le logiciel, tu dois en accepter la licence avant de l'utiliser. Si tu utilise du GPL, c'est implicitement que tu acceptes la GPL !

Donc si on te suit bien tout ce qui n'est pas l'ENS c'est de la m... ? Tous les étudiants n'ayant pas eu des profs "internationalement connus" sont des gros nuls ?

Si sciences-po était tant de la m... que ça, on n'en parlerait même pas, ses étudiants (qu'elle aurait du mal à recruter) auraient du mal à se caser, etc.

Et même si t'avais raison dans ta généralisation abusive, c'est comme partout, l'investissement personnel de l'étudiant compte au moins autant que la qualité de sa formation.

si les dvp linux étaient pas trop con ils switcherait en gplv3 :-d

La gplv3 change quoi à ce sujet ?

Sinon, si le noyau était en LGPL, on pourrait avoir des modules noyau sous d'autres licences et ça résoudrait aussi le pb non ?

Donc si je comprends bien ça veut dire que là où avant le noyau programmait une fois pour toutes le timer pour fixer des rendez-vous périodiques, maintenant ce dernier est constamment reprogrammé pour chaque rendez-vous suivant ?

OK, mais je me demande un truc : est-ce que la reprogrammation du timer est coûteuse en nombre de cycles CPU ? Si oui, ça veut dire qu'on risque de perdre un peu en performances non ?

Donc en résumé il suffirait de recompiler son noyau en modifiant la valeur de HZ pour atténuer le problème ? (à 100 ça doit être moins audible qu'à 1000 j'imagine)

Corollaire : y'a moyen de faire de la musique avec un module noyau ad'hoc ? (OK je sors... :)