lancer le service au démarrage, au moment où il y a pleins d'I/O
attendre que la pression mémoire pousse a récupérer de la mémoire du service
virer les pages de texte (le binaire) de la mémoire puisqu'il est déjà sur disque
swapper sur disque les pages de données
a la première sollicitation remonter les pages de texte depuis le fichier
remonter les pages de données du swap
Au final dans la seconde solution, on a chargé une fois de plus le binaire depuis le disque, on a lu et écrit une fois toutes les données, et on a fait le lancement à un moment ou le disque est très sollicité.
Le seul avantage qu'on a, c'est que le service réponds plus rapidement, puisqu'il a déjà été initialisé. Mais en général le temps d'initialisation est ridicule devant le temps de lecture.
Je n'ai pas vraiment plus d'informations que ce qui a été cité dans l'article et dans le thread que tu pointes. C'est une déduction de:
systemd est déjà dans testing.
un certain nombre de paquets dans testing sont déjà compatibles systemd
Il y a actuellement un problème qui touche également upstart: sysvinit est taggé comme "Essential".
Enfin je n'ai pas parlé d'avoir systemd comme système par défaut; pour la principale raison qu'il n'est pas compatible avec Debian GNU/Hurd ni avec Debian GNU/*BSD
Le terme double-fork dans son sens littéral est effectivement trompeur. Je n'ai pas voulu expliquer en détail le mécanisme qu'on entends par là pour éviter d'allonger un article déjà très long. Merci de l'avoir fait dans les commentaires.
Ligne 167 dans la fonction alloc_pidmap(struct pid_namespace *pid_ns)
pid=last+1;if(pid>=pid_max)pid=RESERVED_PIDS;
La suite de la fonction détermine si pid est utilisé dans ce namespace pour chercher une autre valeur.
La fonction alloc_pid un peu plus bas, fait une boucle dans la pile des namespaces pour affecter un pid dans chaque namespace défini en utilisant alloc_pidmap
Donc le kernel à la vanille incrémente bien de 1 le PID pour chaque nouveau processus, en tout cas tant qu'on n'a pas dépassé pid_max qui vaut de mémoire 0x8000 en mode normal.
Ton test ne fait que le fork; il manque pas mal de travail. Il faudrait tester avec un exec qui va parcourir PATH pour trouver le bon fichier, qui va modifier le mappage mémoire, qui va faire la résolution dynamique des librairies, charger les locales, lire sur stdin, écrire sur stdout, sortir, enfin coté fils il faut encore lire le résultat.
Le test d'une série me semble pas mal, genre partir de n=0 et lancer 2048 fois "bc" en lui passant "n+2".
En shell ça donne ça:
$ time bash -eu -c 'N=0; for I in $(seq 2048); do N=$(echo "$N + 2" | bc); done; echo $N'
4096
real 0m3.352s
user 0m0.940s
sys 0m2.390s
J'ai l'impression que c'est un jouet et que dans 2 ans on nous dira "ah bien non, en fait on va utiliser le system42 qui est mieux". Il y a de plus en plus de nouveautés poussées dans les distributions sans but réel.
A la vue des gains que cela apporte, ce n'est pas un jouet pour moi, et je ne pense pas être le seul. Je ne conteste pas qu'il y ait un effet de mode, je me fiche pas mal du temps de démarrage sur mes serveurs; mais j'attends certaines choses avec impatience.
En particulier:
la récupération de stdout et stderr est un problème récurrent, ainsi que le code de retour lorsque quelque chose ne démarre pas. J'y suis confronté plusieurs fois par an et je me suis retrouvé plus d'une fois à trafiquer les scripts de démarrage.
modifier les paramètres d'un service; sous debian on peut ajouter un paramètre au lancement dans certains paquets via un fichier dans /etc/defaults; comme ce n'est pas le cas pour tous, je dois modifier un script de 300 lignes pour ajouter cette variable; qui est perdu à chaque mise à jour.
Pour l'avenir, j'ignore si une version 42 encore mieux sortira dans dix ans ou dans un an; mais je ne pense pas que ce soit une raison de se priver de ce que systemd apporte. systemd nous montrera peut-être qu'il faut aller dans une autre direction, ou que l'on peut encore améliorer certaines choses; mais cela ne se verra pas en restant dans l'état actuel.
Meilleure intégration avec PAM et SELinux -> je n'utilise pas
Je suis curieux de savoir quelle distribution tu utilises pour te passer de PAM ?
Je confirme. Lorsque la réinstallation n'est pas forcément possible, l'utilisation d'un kernel 64bits est une solution.
Par rapport à un kernel PAE, je vois deux avantages:
Le kernel peut adresser directement toute la mémoire de la machine sans jongler avec la MMU, opération pas très satisfaisante et couteuse en cache TLB.
En mode kernel, le système dispose de plus de registres, gain toutefois un peu contrebalancé par les adresses mémoires plus grosses qui diminuent l'efficacité du cache mémoire.
Il ne me semble pas que ce soit rédhibitoire: l'effacement d'un bloc ne nécessite pas de transmettre des données:
On lit et on écrit des blocs de taille fixe, par exemple 4Ko, les systèmes de fichier aiment bien ça (Un rapide parcours de la norme SATA 1 semble dire que l'on pourrait échanger des paquets jusqu'à 8Ko). Pour l'écriture, les CRCs des SSD ne sont probablement pas fait sur de plus gros blocs vu qu'ils travaillent déjà comme cela.
On envoi une commande d'effacement de macro-bloc lorsqu'on veut faire du ménage. Un peu comme la commande TRIM mais avec une grosse granularité.
Si on veut faire le wear leveling au niveau de l'OS, on peut aussi définir des commandes qui vont remonter le nombre d'usage de chaque cellule. Certains SSD le font déjà.
La question à laquelle je répondais portait sur le multiplexage des requêtes; en particulier pouvoir lancer un ordre d'effacement ou une écriture, opérations un peu lente, tout en continuant à faire des lectures. Et le NCQ permet déjà de lancer plusieurs requêtes en parallèle. (Au passage la norme 3.1 permet maintenant de faire un TRIM sans vider la queue).
Les firmwares de SSD sont compliqués parce qu'ils font beaucoup de chose.
Le SSD n'a pas grand chose à voir avec le disque dur; or afin de pouvoir l'utiliser en lieu et place d'un disque, il est muni d'une couche de compatibilité plutôt considérable destinée à le faire passer et dialoguer comme un disque dur ordinaire. Cette couche est destinée à faire croire que les secteurs font 512 octets, qu'on peut ré-écrire le même tant que l'on veut (surtout ceux situé là ou la FAT se trouve habituellement), que l'écriture peut se faire sur n'importe quel secteur sans surcoût, qu'il n'est pas nécessaire de recycler les secteurs inutilisés...
Les développeurs du kernel souhaitent avoir un accès plus réaliste au SSD et court-circuiter cette couche d'émulation qui fait son travail moins bien que l'OS ne pourrait le faire; mais ils n'ont pas obtenu gain de cause auprès des fabricants. Ceux-ci veulent vendre du matériel prêt à brancher sur les OS d'aujourd'hui, et pas un truc qui ne fonctionnera que dans 2 ans.
Je ne sais pas ce que tu veux faire avec la commande PHP. Mais ce message est un simple avertissement disant que tu as un terminal de type "xterm" qui n'est pas reconnu et que PHP va plutôt utiliser le type "dumb".
Je te laisse imaginer des capacité d'un terminal "dumb" en ce qui concerne la gestion des couleurs, le positionnement du curseur, les styles de caractères...
En lisant http://lwn.net/Articles/449448/ ce matin, j'ai repensé à cette histoire de Tankey, je pense que c'est la même histoire. Et la conclusion est à nouveau: BIOS buggé.
Le fait qu'on ajoute de l'eau déminéralisée lorsque le niveau baisse ne veut pas dire que la batterie ne fonctionne pas par réaction d'oxydo-réduction plomb/acide.
C'est a ma connaissance la seule technologie abordable capable d'encaisser les courants de démarrages nécessaire pour démarrer un moteur.
Essaye la mise en forme du texte, ça sera plus digeste pour tout le monde
1 Avant d'acheter une carte graphique pour un Dell, vérifie que tu puisses bien en brancher une. Pour réduire les coûts, beaucoup de machines de série, particulièrement chez Dell, viennent avec un chip graphique soudé sur la carte mère, et sans connecteur PCIexpress/AGP.
Tu es sur des consommations qui sont déjà extrêmement faibles et tu donnes très peu d'infos (en particulier de besoins en espace disque ou en puissance).
En quoi le Sheevaplug ne réponds pas à tes besoins ?
Tu sembles considérer que les artistes se remplissent les poches, en particulier que les musiciens se sont beaucoup enrichis. Il y a certes quelques artistes très visibles; mais je pense que pour la majorité des gens, cela ne permet pas de vivre; une majorité ont un emploi à coté ou galère pour boucler les mois. L'investissement qu'ils font dans leur activité créatrice qui demande du temps, de l'argent, des sacrifices mérite une rémunération décente. Tu ne parles pas de toute l'activité de production, commercialisation, distribution, qui pour la majorité, n'est pas une activité artistique.
Si j'extrapole un peu la fin de ton texte, il est vaguement question de limiter l'application du droit d'auteur aux sociétés commerciales, et non pas au particulier. Mais quelle part de consommation représente ces débouchés. Pour une série télé, on comprends bien que la chaine payent une partie (je ne suis pas certain que les ventes de DVD soient négligeables), mais pour les petits musiciens...
Tu rappelles la situation des artistes au moyen-age; il y avait également le mécénat, qui existe encore aujourd'hui, mais surtout aux USA. En France on compte plutôt sur l'état.
Enfin mon avis un peu global et pas forcément très bien formulé: Je ne souhaite pas vivre dans un monde qui pousse encore plus les gens à vivre pour la rentabilité et la production sans faire en partie ce qu'ils souhaitent. Le fait de pouvoir consacrer une part importante de nos ressources à l'art est une façon de rendre le monde dans lequel nous vivons plus agréable pour chacun.
J'utilise LTSP (Linux Terminal Server Project) qui consiste à gérer un ou quelques serveurs et à faire booter tous les postes de travail sur le réseau (pas d'installation locale).
Ça fonctionne bien; ça supporte le son et les clefs/disques USB. En 100mbps, les vidéos flash passent (par contre flash consomme beaucoup de CPU).
Je ne connais pas cette clef, mais a mon avis, tu confonds plusieurs choses:
Le périphérique réseau, qui ne se déclare pas dans la fstab (ce n'est pas un système de fichiers), et qui n'est pas un périphérique de type block (SUBSYSTEM="block"), mais de type net (SUBSYSTEM=="net") si elle se comporte comme une carte réseau, ou de type character si elle se comporte comme un modem.
Le ou les systèmes de fichiers qui sont également embarqués par la clef et qui permettent de stocker les drivers windows et peut-être d'autres choses comme le paramétrage, le firmware de la clef ou le manuel. Ils sont bien de type block, et se déclarent dans le fichier fstab, mais il est possible qu'ils soient inutiles dans le cas de Linux.
S'il s'agit d'une clef USB, la commande lsusb et ses multiples options te permettrons de voir la topologie du bus, d'identifier la clef et les différents périphériques logiques qu'elle contient. La commande dmesg donne souvent des informations (identifier les lignes ajoutées à l'insertion de la clef).
[^] # Re: Merci
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 9.
Si j'essaye de résumer les deux solutions
Solution à la demande
Solution pré-chargement
Au final dans la seconde solution, on a chargé une fois de plus le binaire depuis le disque, on a lu et écrit une fois toutes les données, et on a fait le lancement à un moment ou le disque est très sollicité.
Le seul avantage qu'on a, c'est que le service réponds plus rapidement, puisqu'il a déjà été initialisé. Mais en général le temps d'initialisation est ridicule devant le temps de lecture.
[^] # Re: systemd / Debian
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 4.
Je n'ai pas vraiment plus d'informations que ce qui a été cité dans l'article et dans le thread que tu pointes. C'est une déduction de:
Il y a actuellement un problème qui touche également upstart: sysvinit est taggé comme "Essential".
Enfin je n'ai pas parlé d'avoir systemd comme système par défaut; pour la principale raison qu'il n'est pas compatible avec Debian GNU/Hurd ni avec Debian GNU/*BSD
[^] # Re: double fork
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 3.
Le terme double-fork dans son sens littéral est effectivement trompeur. Je n'ai pas voulu expliquer en détail le mécanisme qu'on entends par là pour éviter d'allonger un article déjà très long. Merci de l'avoir fait dans les commentaires.
[^] # Re: Petits PIDs
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 4.
Suite à une remarque d'un relecteur, j'ai vérifié en écrivant l'article.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.39.y.git;a=blob;f=kernel/pid.c;h=57a8346a270e07702e21d7bab15303427bf2fce0;hb=HEAD
Ligne 167 dans la fonction
alloc_pidmap(struct pid_namespace *pid_ns)La suite de la fonction détermine si
pidest utilisé dans ce namespace pour chercher une autre valeur.La fonction
alloc_pidun peu plus bas, fait une boucle dans la pile des namespaces pour affecter un pid dans chaque namespace défini en utilisantalloc_pidmapDonc le kernel à la vanille incrémente bien de 1 le PID pour chaque nouveau processus, en tout cas tant qu'on n'a pas dépassé pid_max qui vaut de mémoire 0x8000 en mode normal.
[^] # Re: Quoi ? Il faut créer plein de processus ?
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 10.
Ton test ne fait que le fork; il manque pas mal de travail. Il faudrait tester avec un exec qui va parcourir PATH pour trouver le bon fichier, qui va modifier le mappage mémoire, qui va faire la résolution dynamique des librairies, charger les locales, lire sur stdin, écrire sur stdout, sortir, enfin coté fils il faut encore lire le résultat.
Le test d'une série me semble pas mal, genre partir de n=0 et lancer 2048 fois "bc" en lui passant "n+2".
En shell ça donne ça:
Ce qui fait 3.3 secondes chez moi.
[^] # Re: Lapin compris
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 10.
A la vue des gains que cela apporte, ce n'est pas un jouet pour moi, et je ne pense pas être le seul. Je ne conteste pas qu'il y ait un effet de mode, je me fiche pas mal du temps de démarrage sur mes serveurs; mais j'attends certaines choses avec impatience.
En particulier:
la récupération de stdout et stderr est un problème récurrent, ainsi que le code de retour lorsque quelque chose ne démarre pas. J'y suis confronté plusieurs fois par an et je me suis retrouvé plus d'une fois à trafiquer les scripts de démarrage.
modifier les paramètres d'un service; sous debian on peut ajouter un paramètre au lancement dans certains paquets via un fichier dans /etc/defaults; comme ce n'est pas le cas pour tous, je dois modifier un script de 300 lignes pour ajouter cette variable; qui est perdu à chaque mise à jour.
Pour l'avenir, j'ignore si une version 42 encore mieux sortira dans dix ans ou dans un an; mais je ne pense pas que ce soit une raison de se priver de ce que systemd apporte. systemd nous montrera peut-être qu'il faut aller dans une autre direction, ou que l'on peut encore améliorer certaines choses; mais cela ne se verra pas en restant dans l'état actuel.
Je suis curieux de savoir quelle distribution tu utilises pour te passer de PAM ?
[^] # Re: 4 GB
Posté par Sébastien Koechlin . En réponse au message Migre de Lenny 32bits à Squeeze 64bits. Évalué à 2.
Je confirme. Lorsque la réinstallation n'est pas forcément possible, l'utilisation d'un kernel 64bits est une solution.
Par rapport à un kernel PAE, je vois deux avantages:
Le kernel peut adresser directement toute la mémoire de la machine sans jongler avec la MMU, opération pas très satisfaisante et couteuse en cache TLB.
En mode kernel, le système dispose de plus de registres, gain toutefois un peu contrebalancé par les adresses mémoires plus grosses qui diminuent l'efficacité du cache mémoire.
[^] # Re: Bureau ok
Posté par Sébastien Koechlin . En réponse au journal Les SSD. Évalué à 4.
Il ne me semble pas que ce soit rédhibitoire: l'effacement d'un bloc ne nécessite pas de transmettre des données:
Si on veut faire le wear leveling au niveau de l'OS, on peut aussi définir des commandes qui vont remonter le nombre d'usage de chaque cellule. Certains SSD le font déjà.
La question à laquelle je répondais portait sur le multiplexage des requêtes; en particulier pouvoir lancer un ordre d'effacement ou une écriture, opérations un peu lente, tout en continuant à faire des lectures. Et le NCQ permet déjà de lancer plusieurs requêtes en parallèle. (Au passage la norme 3.1 permet maintenant de faire un TRIM sans vider la queue).
[^] # Re: Bureau ok
Posté par Sébastien Koechlin . En réponse au journal Les SSD. Évalué à 2.
Pas certain, il y a déjà le Native Command Queuing. Par contre, je ne sais pas quelle est la taille maximale d'un bloc.
[^] # Re: Bureau ok
Posté par Sébastien Koechlin . En réponse au journal Les SSD. Évalué à 10.
Les firmwares de SSD sont compliqués parce qu'ils font beaucoup de chose.
Le SSD n'a pas grand chose à voir avec le disque dur; or afin de pouvoir l'utiliser en lieu et place d'un disque, il est muni d'une couche de compatibilité plutôt considérable destinée à le faire passer et dialoguer comme un disque dur ordinaire. Cette couche est destinée à faire croire que les secteurs font 512 octets, qu'on peut ré-écrire le même tant que l'on veut (surtout ceux situé là ou la FAT se trouve habituellement), que l'écriture peut se faire sur n'importe quel secteur sans surcoût, qu'il n'est pas nécessaire de recycler les secteurs inutilisés...
Les développeurs du kernel souhaitent avoir un accès plus réaliste au SSD et court-circuiter cette couche d'émulation qui fait son travail moins bien que l'OS ne pourrait le faire; mais ils n'ont pas obtenu gain de cause auprès des fabricants. Ceux-ci veulent vendre du matériel prêt à brancher sur les OS d'aujourd'hui, et pas un truc qui ne fonctionnera que dans 2 ans.
# Warning
Posté par Sébastien Koechlin . En réponse au message command php en environnement chrooté. Évalué à 0.
Je ne sais pas ce que tu veux faire avec la commande PHP. Mais ce message est un simple avertissement disant que tu as un terminal de type "xterm" qui n'est pas reconnu et que PHP va plutôt utiliser le type "dumb".
Je te laisse imaginer des capacité d'un terminal "dumb" en ce qui concerne la gestion des couleurs, le positionnement du curseur, les styles de caractères...
# Encore une histoire de BIOS buggé
Posté par Sébastien Koechlin . En réponse au journal 2.6.38 / 2.6.39 & autonomie. Évalué à 1.
En lisant http://lwn.net/Articles/449448/ ce matin, j'ai repensé à cette histoire de Tankey, je pense que c'est la même histoire. Et la conclusion est à nouveau: BIOS buggé.
[^] # Re: Connais pas
Posté par Sébastien Koechlin . En réponse au journal J'ai dix ans.... Évalué à 7.
Quelqu'un dont la fréquence d’apparition est inversement proportionnelle à son usage correct. Enfin je crois.
[^] # Re: Quel journal ? C'est une question de forum !
Posté par Sébastien Koechlin . En réponse au message Disparition. Évalué à 1.
Par contre, les commentaires ont l'air d'avoir disparu dans une faille spatio-temporelle en bas à droite du 4ème disque dur.
[^] # Re: Attention au n'importe quoi
Posté par Sébastien Koechlin . En réponse au journal De l'électronique portable et de le durée de vie des batteries. Évalué à 2.
Le fait qu'on ajoute de l'eau déminéralisée lorsque le niveau baisse ne veut pas dire que la batterie ne fonctionne pas par réaction d'oxydo-réduction plomb/acide.
C'est a ma connaissance la seule technologie abordable capable d'encaisser les courants de démarrages nécessaire pour démarrer un moteur.
[^] # Re: types de batteries
Posté par Sébastien Koechlin . En réponse au journal De l'électronique portable et de le durée de vie des batteries. Évalué à 7.
Cela n'a pas de sens.
Que la coupure soit courte ou longue; si l'onduleur ou l'électronique du portable ne réagit pas suffisamment vite; la machine va rebooter.
D'après tes explications les UPS qui ne sont pas à double conversion ne pourraient jamais fonctionner.
Je n'ai jamais vu un portable (équipé de sa batterie) rebooter lorsqu'on débranchait le cable électrique. C'est un défaut de ton portable.
# 3615 Père-Noël
Posté par Sébastien Koechlin . En réponse au message Achat de matos. Évalué à 4.
Hello
Essaye la mise en forme du texte, ça sera plus digeste pour tout le monde
1 Avant d'acheter une carte graphique pour un Dell, vérifie que tu puisses bien en brancher une. Pour réduire les coûts, beaucoup de machines de série, particulièrement chez Dell, viennent avec un chip graphique soudé sur la carte mère, et sans connecteur PCIexpress/AGP.
2 Si tu allais faire un tour chez Darty plutôt ?
# capex et opex
Posté par Sébastien Koechlin . En réponse au message Mini serveur basse consommation (<5 watt). Évalué à 5.
Tu es sur des consommations qui sont déjà extrêmement faibles et tu donnes très peu d'infos (en particulier de besoins en espace disque ou en puissance).
En quoi le Sheevaplug ne réponds pas à tes besoins ?
# Petite correction
Posté par Sébastien Koechlin . En réponse au message Chargement d'un module au démarrage du système. Évalué à 2.
De mémoire dans /etc/modules il faut mettre le nom du module et non le nom du fichier.
Donc "cm15a" et non "cm15a.ko"
[^] # Re: Il ne marche pas ce lien
Posté par Sébastien Koechlin . En réponse au journal Les journaux bookmark. Évalué à 3.
Mais... mais c'est le code que n'importe quel abruti utilise pour ses bagages !
[^] # Re: Avatar
Posté par Sébastien Koechlin . En réponse au journal Confession(s) d'un pirate. Évalué à 2.
Pas besoin d'investir dans un scénario; ils avaient déjà celui de Pocahontas et Disney a fait 1000% de bénef dessus.
# Vivre de son activité
Posté par Sébastien Koechlin . En réponse au journal Confession(s) d'un pirate. Évalué à 9.
J'ai quelques remarques:
Tu sembles considérer que les artistes se remplissent les poches, en particulier que les musiciens se sont beaucoup enrichis. Il y a certes quelques artistes très visibles; mais je pense que pour la majorité des gens, cela ne permet pas de vivre; une majorité ont un emploi à coté ou galère pour boucler les mois. L'investissement qu'ils font dans leur activité créatrice qui demande du temps, de l'argent, des sacrifices mérite une rémunération décente. Tu ne parles pas de toute l'activité de production, commercialisation, distribution, qui pour la majorité, n'est pas une activité artistique.
Si j'extrapole un peu la fin de ton texte, il est vaguement question de limiter l'application du droit d'auteur aux sociétés commerciales, et non pas au particulier. Mais quelle part de consommation représente ces débouchés. Pour une série télé, on comprends bien que la chaine payent une partie (je ne suis pas certain que les ventes de DVD soient négligeables), mais pour les petits musiciens...
Tu rappelles la situation des artistes au moyen-age; il y avait également le mécénat, qui existe encore aujourd'hui, mais surtout aux USA. En France on compte plutôt sur l'état.
Enfin mon avis un peu global et pas forcément très bien formulé: Je ne souhaite pas vivre dans un monde qui pousse encore plus les gens à vivre pour la rentabilité et la production sans faire en partie ce qu'ils souhaitent. Le fait de pouvoir consacrer une part importante de nos ressources à l'art est une façon de rendre le monde dans lequel nous vivons plus agréable pour chacun.
[^] # Re: Hum...
Posté par Sébastien Koechlin . En réponse à l’entrée du suivi Feed Atom pour le tableau de bord. Évalué à 1 (+0/-0).
L'intérêt à mon avis est d'avoir un feed qui indique qu'il y a des nouvelles réponses à des commentaires que l'on a fait.
Cela m'intéresse, voir mon autre commentaire ci-dessous.
# LTSP
Posté par Sébastien Koechlin . En réponse au message Virtualisation de postes de travail. Évalué à 2.
J'utilise LTSP (Linux Terminal Server Project) qui consiste à gérer un ou quelques serveurs et à faire booter tous les postes de travail sur le réseau (pas d'installation locale).
Ça fonctionne bien; ça supporte le son et les clefs/disques USB. En 100mbps, les vidéos flash passent (par contre flash consomme beaucoup de CPU).
# Fonctionnement confus
Posté par Sébastien Koechlin . En réponse au message clé 3g et LMDE. Évalué à 1.
Je ne connais pas cette clef, mais a mon avis, tu confonds plusieurs choses:
Le périphérique réseau, qui ne se déclare pas dans la fstab (ce n'est pas un système de fichiers), et qui n'est pas un périphérique de type block (SUBSYSTEM="block"), mais de type net (SUBSYSTEM=="net") si elle se comporte comme une carte réseau, ou de type character si elle se comporte comme un modem.
Le ou les systèmes de fichiers qui sont également embarqués par la clef et qui permettent de stocker les drivers windows et peut-être d'autres choses comme le paramétrage, le firmware de la clef ou le manuel. Ils sont bien de type block, et se déclarent dans le fichier fstab, mais il est possible qu'ils soient inutiles dans le cas de Linux.
S'il s'agit d'une clef USB, la commande lsusb et ses multiples options te permettrons de voir la topologie du bus, d'identifier la clef et les différents périphériques logiques qu'elle contient. La commande dmesg donne souvent des informations (identifier les lignes ajoutées à l'insertion de la clef).