Sygne a écrit 628 commentaires

Merci pour SystemImager, que je ne connaissais pas.

NFS paraît bien si le wifi est rapide.

Tu veux dire pour partager '/'? ou seulement pour '/home'? Quoi qu'il en soit, je crois que le seul moyen de savoir si mon wifi est rapide, c'est d'essayer…

Faut être ouvert, et ne pas rester bloquer dans une distribution en particulier.

Oui mais bon…

Car si je comprends bien ton idée, pour avoir LibreOffice par exemple sur un client tu vas l'installer sur le serveur ? Bizarre…

Pourquoi bizarre? En quoi la présence de cet exécutable dans la hiérarchie du serveur l'empêche d'être un bon serveur? Il ne le lance pas, c'est tout. Il en va de même pour X. Non?

Le boot PXE est nécessaire dans le cadre de LTSP et non dans ton idée.

C'est ce que je voulais dire, effectivement.

Si tout fois tu utilises LTSP, utilise NFS et non NBD pour de meilleures performances.

merci du conseil.

Tu as gPXE ou iPXE

Encore merci!

Manifestement, la question de l'arborescence de la racine est un problème soulevé par plusieurs commentaires. Je vais donc préciser un peu:

• J'ai fini par abandonner l'idée des clients diskless, du boot pxe, et de '/' monté sur le réseau parce que je ne suis pas certain que ce soit confortable via le wifi. Cela permet aussi de sortir un ordinateur du réseau si besoin (un portable par exemple).
• Pour la synchronisation, il est possible d'utiliser Rsync. Il y a d'autres possibilités qui semblent amusantes: Csync2 et Btrfs send/receive. Je pensais lancer la synchronisation durant l'extinction du client.
• J'aimerais vraiment éviter d'avoir à mettre à jour et le serveur et une arborescence dans un chroot. Àmha, le serveur peut contenir toute l'arborescence dont ont besoin les clients (avec X, OpenOffice, etc.), il a juste besoin de sa propre configuration pour ne lancer que les services dont il a besoin. Non?

Ceci étant dit, si vraiment le diskless shared root cluster est la solution pertinente, je vais m'orienter vers ça…

Mon hésitation est donc levée, j'opte pour le lecteur dvd usb.

Merci!

Oui, je connais ltsp de loin (j'ai visité son site), mais ne l'utiliserai vraisemblablement pas:

• il n'est pas disponible dans ma distribution (arch),
• je ne veux pas lancer les programmes sur le serveur, mais sur les clients (pas de ssh-x donc),
• j'aimerais éviter le «mini chroot environment» qu'utilise ltsp, et synchroniser la racine des clients directement avec celle du serveur.
• à la limite, je n'ai pas besoin du boot pxe: les clients ont leur disque dur et leur racine, synchronisée avec celle du serveur à la demande.
• ltsp me semble donc être une surcouche peu utile—du moins, j'ai été plus convaincu par les tutoriels sur les briques qu'utilise ltsp que par la documentation de ltsp.

As tu un lien vers une documentation concernant le boot PXE via le wifi? J'imagine que ça utilise une mini distribution pour le boot, pour finir par faire un chroot vers la racine du système complet servie par NFS, non?

Bonjour,

Avec le routeur TP-Link, il faut acheter une carte sim et une recharge n'est-ce pas?
- Est-ce que les cartes sim des offres Orange Domino et SFR web trotter fonctionneront?
- Puis-je utiliser la carte sim d'un forfait téléphonique normal?

D'après ta carte, la couverture 3G est bonne. Je vais donc essayer cette solution.

Encore merci !

Si j'ai bien compris, vous conseillez:
- l'achat d'un smartphone permettant le partage de connexion,
- l'utilisation d'un forfait téléphonique avec internet 3G.

ça me semble cohérent. J'ai actuellement un forfait avec 50Mo de données, mais il est peut-être possible de le transférer pour un mois vers un forfait plus adapté.

Quand au choix du téléphone, puis-je parier qu'un téléphone android moderne permet le partage de connexion? Quid d'un samsung trend par exemple ?

Merci !

Merci,

Comme indiqué ci-dessus, je n'ai pas de smartphone. Quel genre d'appareil peut être utilisé comme point d'accès wifi ?

ah, je n'ai pas de smartphone… Quel genre d'appareil permet ce "partage de connexion" ?

Julia Reda a publié son discours aux sénateurs sur son blog. C'est un beau discours.

Mais quelque chose m'inquiète: Il y a quelques années, j'avais l'impression que certains de nos élus, quoique très minoritaires et dispersés à travers les partis, en appelaient à un dépoussiérage du droit d'auteur. Or là, j'ai l'impression qu'il n'y a pas grand monde pour animer le débat en France. Où sont passés les progressistes en matière de droit d'auteur ? N'y a-t-il aucun politicien pour soutenir son rapport ?

Je te prie de m'excuser. Je minimise effectivement le fait qu'il existe des logiciels libres non empaquetés parce que j'ai l'impression que les cas où il y a un besoin pour ces logiciels sont tout de même rares, et surtout que les personnes qui en ont besoin sont à même de les installer depuis les sources.

Si ça te semble être un problème significatif, alors, je ne peux que constater ne pas être de ton avis pour l'instant – mais je peux me laisser convaincre.

La n-ième distribution n'est pas totalement incompatible, puisqu'elle propose elle aussi firefox, kde, etc. En vérité, elle n'est incompatible qu'avec certains logiciels: ceux dont les sources sont fermées.

Il est vrai qu'un standard comme LSB aurait simplifié la vie des fabricants de logiciels à sources fermés qui veulent distribuer ceux-ci sur linux. Cela aurait amélioré l'utilisabilité de linux. Mais je dois avouer ne pas être certain que cela aurait été un bien pour les systèmes d'exploitations libres.

J'avoue avoir du mal à comprendre l'argument: il est certain qu'un logiciel empaqueté pour telle distribution ne fonctionnera pas sur une autre distribution mais, àmha, peu importe:

• s'il est empaqueté dans une distribution, il y a de forte chances qu'il le soit aussi dans la distribution choisie,
• s'il ne l'est pas il existe certainement une alternative d'ores et déjà empaquetée,
• s'il n'y a pas d'alternatives, c'est qu'il s'agit probablement d'un logiciel à usage professionnel (et vraisemblablement propriétaire) auquel cas, il est assez évident qu'il faudra choisir son système d'exploitation en fonction de cette contrainte.

Ou alors, il y a quelque chose qui m'échappe…

Mais qu'il est triste votre avis sur les nouvelles distributions !

Une nouvelle distribution c'est l'occasion de participer à un projet collaboratif, d'y avoir un peu d'influence, de tester des idées d'implémentation logicielle, d'administration ou d'interface utilisateur.

Pour les utilisateurs, c'est peut-être simplement l'occasion de connaître ses auteurs, de discuter avec eux dans la langue de molière, ou de leur offrir un café parce qu'ils habitent à côté.

J'ai côtoyé dans ma vie deux « nouvelles distributions ». Je ne me souviens plus du nom de la première, et je ne l'ai jamais installée. Elle était créée par des francophones de la communauté léa-linux. J'ai par contre passé des heures à lire leurs discussions, les problèmes qu'ils rencontraient et la façon dont ils espéraient les résoudre. Ils m'ont tout appris.

Quant à la deuxième, il s'agit de Slitaz, à laquelle j'ai très modestement contribué: première forge, premières responsabilités, etc. C'était une expérience incroyable dans ma petite vie d'amateur.

Contribuez aux nouvelles distributions, vous verrez qu'elles sont indispensables à la bonne santé de nos communautés.

Merci, mais si « C Kernighan et Ritchie » n'est pas une expression connue, il faudrait mieux écrire « en C K&R » ou « en C à la façon de Kernighan et Ritchie ». Mais certainement pas « réécrit en C par », comme l'explique mon commentaire ci-dessous.

Encore merci.

Il n'y a pas de mot manquant, c'est une traduction littérale de l'expression « K&R C ».

En fait, avant que ne soit publiée en 1989 la norme ANSI du C, le livre de Kernighan et Ritchie (The C Programming Language, de 1978) a servi de spécification informelle, ou de plus petit dénominateur commun, des diverses implémentations du langage.

Je ne pas mal pris ton commentaire, je ne l'ai même pas moinssé. Connaissant ta prose, j'ai perçu la taquinerie. Du reste tu as raison, honte à moi.

Quant à la qualité de la dépêche, j'ai un avis mitigé sur la question: J'ai retrouvé des notes que j'avais prises il y a un an ou deux pour écrire une dépêche finalement abandonnée. Considérant qu'il valait tout de même mieux publier ce travail inabouti que ne rien en faire, je l'ai rapidement mis en forme.

Ah, tiens, effectivement, il y a un « p » à Thompson. Merci, je ferai attention dorénavant.

Pardon aux familles, etc…

Est-ce qu'un modérateur peut corriger cette erreur ?

D'accord, on peut rajouter plusieurs contraintes, mais enfin, tu changes les règles du jeu là. :)

Il y a nécessairement des cas où le shell n'est pas adapté, et il y a peut-être même des choses qu'il est incapable de faire. Mais àmha, rien qui justifie les critiques à l'emporte pièce que l'on lit parfois ici.

Supposons que tu veuilles passer tous les arguments à une commande, en les remplaçant d’une certaine façon (par exemple en remplaçant les chemins relatifs par des chemins absolus), comment tu fais ?

Quelque chose comme suit ne fait-il pas l'affaire ?

while [ $# -gt 0 ]
do
    echo /mon/chemin/$1
    shift
done | xargs echo

Je réponds à la suite plus tard…

Je ne vois pas en quoi la syntaxe du shell serait si terrible…

D'une part accolades, points virgules, mots clés n'ont rien d'exotique, et d'autre part sa syntaxe a, à mon avis, certains avantages indéniables:

mail $(getmail tonton) < monmail
troff * | dpost | ps2pdf - > tousmesdocs.pdf

Tubes, redirections, substitutions de commandes, expressions régulières, ont été inventées pour le shell et les raccourcis symboliques définissent la spécificité de sa syntaxe. Je ne connais pas plus simple.

De même, l'utilisation d'un symbole pour représenter les variables est une invention de Bourne. L'enjeu est le suivant: en ligne de commande, on ne s'ennuie pas à mettre des guillemets pour représenter chaque chaîne de caractères, parce que celles-ci forment la majorité de ce que l'on tape (noms de fichiers, exécutables). On utilise donc un petit $ pour représenter les variables.

On peut certainement perfectionner la syntaxe, mais franchement, pour manipuler une hiérarchie de fichiers au moyen d'un ensemble d'exécutables, je ne vois pas de syntaxe plus adaptée.

Au premier coup d'œil jeté sur les copies d'écran, je suis plus attiré par ccGenie moi aussi. Cela relève de la mise en page à mon avis. Je vais essayer d'exprimer cette impression:

• ccGenie structure fortement sa page par un contraste de couleurs, et la pense comme une image qu'il n'est pas nécessaire de lire pour y trouver des repères. La page de Tracim est peu contrastée, et elle est construite comme un page de texte, qui doit être lue plutôt que vue.
• Tracim semble fourmiller d'information, le regard cherche parmi elles celles qui sont pertinentes, ccGenie minimise la quantité d'information textuelles.
• Tracim utilise des phrases (« Allow to reset password to […] Créé(e) le… »), ccGenie utilise de simples mots.
• Tracim hiérarchise peu les éléments textuels, ccGenie utilise un double contraste (taille et couleur), de sorte que l'information secondaire apparaît effacée.
• Outre le texte, Tracim incorpore dans la page tout un ensemble d'éléments qui viennent parasiter la lecture: la petite icône bleue à droite du titre, les flèches vers le bas ou la droite des menus déroulants, les slash dans le menu « espace de travail, développement, bugs », etc.
• Icônes et textes sont redondants sur la page de Tracim. Mieux vaudrait peut-être se contenter de l'un ou de l'autre, selon les cas. Par exemple, espace de travail n'a pas nécessairement besoin d'une icône de bureau.
• Les lignes grises, horizontales et verticales, sur la page de Tracim sont probablement symptomatiques: elles sont censées hiérarchiser la page, mais la complexifient finalement en ajoutant encore un élément visuel et sémantique.

Je penche donc pour une forme d'épuration de la page, en utilisant des contrastes forts pour hiérarchiser les blocs, des contrastes forts pour hiérarchiser les éléments textuels, de simples mots pour les menus, des formats simples pour l'information textuelle (en particulier les dates), et en supprimant toutes les icônes. Sur cette base, il sera plus facile de replacer des icônes pertinentes sémantiquement et visuellement.

La page wikipedia consacrée au framebuffer est éclairante:

Libraries such as GGI, SDL, GTK+ and Qt Extended can use the framebuffer directly. […] There is now a library DirectFB which provides a framework for hardware acceleration of the Linux framebuffer. There was also an in-kernel windowing system called FramebufferUI (fbui) that provides a basic 2D windowing experience with very little memory use.

Ces bibliothèques sont peut-être de trop bas niveau, ou trop généralistes, mais elles peuvent servir de mots-clés pour trouver une bibliothèque qui fait exactement ce que tu cherches… Si celle-ci existe…

Je ne nie pas l'aspect difficilement réalisable de la chose. Je m'amuse, ou peut-être regrette, que le système de fichier par le réseau était, il n'y a pas si longtemps, à la mode.

L'arrivée de l'ordinateur personnel remettait en cause l'architecture unité centrale / terminal qui prévalait alors, et l'informatique cherchait à mettre en réseau les données et la puissance de calcul de toutes ces nouvelles machines:

• Un des buts de Plan9 était de permettre la création de réseaux de machines de bureau.
• DragonFly BSD adaptait le noyau BSD pour créer à terme un « single system image », cluster ou l'ensemble des nœuds forme un tout unifié.
• Mosix, OpenMosix, Kerrighed, avaient le même but sur linux, et répartissait une charge de calcul sur plusieurs postes.
• Des systèmes de fichiers en réseau, mais avec persistance des données en cas de panne de faille d'un nœud étaient étudiés.
• Les plus réalistes se contentaient de mettre la racine du système de fichier sur un serveur, et de la servir à plusieurs postes.

Le web regorge de traces de cette époque: sources, documentations, discussions, etc. Mais les difficultés rencontrées pour la création de Single System Images semblent avoir conduit à l'abandon de la mise en réseau des système de fichiers.

En outre, l'apparition du P2P, mais aussi des résaux non filiaires a relevé les exigences théoriques de tels systèmes: dans l'idéal, il faudrait qu'il n'y ait pas de machine centrale mais que toutes soient égales, et que le réseau résiste aux déconnections, ce qui complique la tâche des développeurs.

Bref, personnellement, je trouvais ces projets bien plus intéressants que le pauvre serveur https de données personnelles d'aujourd'hui. Certains y voient le futur, je n'y vois que le passé.